What about leaving Posix compatibility to get better code ?
err, the POSIX compatibility is still there3
but don’t delude yourself that UNIX apps are better coded. They’re usually not.
Better code is up to the coder. They don’t have to use Posix…
KeepSimple wrote:
What about leaving Posix compatibility to get better code ?
I would assume “better” means “more portable” in this case - as already stated, posix doesn’t produce better code, just more portable code.
I have wrotten in a wrong way, i have wrotten leaving as to abbandon posix compatibility to write better (smaller, smarter, wrotten ad hoc, …) and simpler code.
MYOB wrote:
I don't think posix code is better, i love semplicity of BeOS API and dislike very much the older and obsolete functions naming and using convention. I think also the unix style is too in depth and very usefull to very expert people only, i like much more the usability and semplicity of BeOS.
but don't delude yourself that UNIX apps are better coded. They're usually not.
h_ank wrote:
Oh, yes, i think so too, and i intend leave posix as to abandon posix, so the coder could write simpler and better code.
Better code is up to the coder. They don't have to use Posix...
umccullough wrote:
I would like to say that abandoning posix the code will result better, smaller...
I would assume "better" means "more portable" in this case - as already stated, posix doesn't produce better code, just more portable code.
KeepSimple wrote:
I have wrotten in a wrong way, i have wrotten leaving as to abbandon posix compatibility to write better (smaller, smarter, wrotten ad hoc, ...) and simpler code.MYOB wrote:I don't think posix code is better, i love semplicity of BeOS API and dislike very much the older and obsolete functions naming and using convention. I think also the unix style is too in depth and very usefull to very expert people only, i like much more the usability and semplicity of BeOS.but don't delude yourself that UNIX apps are better coded. They're usually not.h_ank wrote:Oh, yes, i think so too, and i intend leave posix as to abandon posix, so the coder could write simpler and better code.Better code is up to the coder. They don't have to use Posix...umccullough wrote:I would like to say that abandoning posix the code will result better, smaller...I would assume "better" means "more portable" in this case - as already stated, posix doesn't produce better code, just more portable code.
Dumping POSIX compliance will leave us up shit creek, to use a profanity
No Mozilla. No VideoLAN. No GCC, no BinUtils, etc. No GCC = no OS. No POSIX = no networking stack. No Bash, no GNU utilities.
No POSIX = no OS
KeepSimple wrote:
I have wrotten in a wrong way, i have wrotten leaving as to abbandon posix compatibility to write better (smaller, smarter, wrotten ad hoc, ...) and simpler code.MYOB wrote:I don't think posix code is better, i love semplicity of BeOS API and dislike very much the older and obsolete functions naming and using convention. I think also the unix style is too in depth and very usefull to very expert people only, i like much more the usability and semplicity of BeOS.but don't delude yourself that UNIX apps are better coded. They're usually not.h_ank wrote:Oh, yes, i think so too, and i intend leave posix as to abandon posix, so the coder could write simpler and better code.Better code is up to the coder. They don't have to use Posix...umccullough wrote:I would like to say that abandoning posix the code will result better, smaller...I would assume "better" means "more portable" in this case - as already stated, posix doesn't produce better code, just more portable code.
Whoops, I (and apparently others) misunderstood your premise - you are suggesting we dump POSIX compliances (I thought you meant “leave it in”, not “leave it out”)
I agree with MYOB here - there is so much out there that relies on POSIX for cross-platform compatibility - even Windows NT/2000/XP have some level of built-in POSIX support, and for everything else in the Windows environment there is Cygwin (large assortment of POSIX compatibility libraries and shell tools to make Windows run/compile many *NIX-based software)
Leaving POSIX support out of an OS is a choice that essentially locks that OS out of the mainstream of existing software. Without it, an OS will lose decades of available software/code - or at the least it all has to be ported over to a new API which is more work that many people are willing to expend.
On the other hand, nobody is forcing a developer to write software that is POSIX compliant - which is what the BeOS API is all about. It is a revolutionary API that encourages much better OO programming methodology. You don’t have to leave POSIX compliance out of the OS to obtain that dream, you simply have to encourage more people to use the newer API instead of POSIX.
If POSIX will give to Haiku a lot of good software, what is the better way to implement it?
I think that a good way to implement it is to not care about POSIX and to write a well done OO APIs and only after this to make a layer of compatibility with POSIX using the OO APIs, is this possible? Also to redo the command line commands, allowing to be POSIX compliant but with an internal structure that refers to OO APIs and not to POSIX functions, example : an ls command that refers to the Storage Kit and being POSIX compliant with its argouments. Also remake the common GNU libraries and utilities using OO APIs, traslating OO APIs to POSIX, making an interface of compatibility from one system to another, the same thinks told in different ways. Trying to refer ever to the OO APIs than to the POSIX one during the programming of the compatibility layer so an application that refers to POSIX finds an interface only that redirect the code to the OO APIs. So an application that search for a library of the GNU or other find a library with header with the original library functions but with the code rewritten to point to the OO APIs.