Why C for operating systems
in [General Programming]
|
From: Pascal J. Bourguignon on 8 Dec 2009 06:55 "BGB / cr88192" <cr88192(a)hotmail.com> writes: > "James" <no(a)spam.invalid> wrote in message news:hfkm7c$h05$1(a)aioe.org... >> "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message >> news:87bpiaclkb.fsf(a)galatea.local... >>> "Bill Cunningham" <nospam(a)nspam.invalid> writes: >>> >>>> "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message >>>> news:87aaxuegia.fsf(a)galatea.local... >>> Otherwise, indeed, OS can be written in javascript. >>> http://research.sun.com/projects/lively >> >> lively runs on top of a browser, which in turn runs on top of a real >> operating system. Not sure one can claim that lively is a real operating >> system. > > the main mystery then is if anyone can improve the performance of JavaScript > in browsers (any sort of OS-like abstractions existing in JS in the browser > fill me some with fear, that the performance will suck...). Exactly like the relationship between processors and unix-like systems, the processors are optimized to make unix run good, and unix is optimized to run good on the processors. Once systems like Lively exist on javascript, javascript evolves to run them better. Work is in progress to improve the performance of javascript because it its taken to such extremities. > as I see it, not all languages are equal. > the tendency of lots of JavaScript in web pages making FF grind to a halt is > evidence of this... Application programmers are less concerned by performance, as it should be. It doesn't matter, computers get fasters, and the platform is optimized behind their back. The shame is that we don't already have AI systems that automatically optimize algorithms ;-) > actually, any more it is sad: > FF uses craploads of RAM and goes really slow; > yet it is still generally better than IE... > > this is the sad state of things... -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 8 Dec 2009 07:05 "BGB / cr88192" <cr88192(a)hotmail.com> writes: > "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message > news:873a3me9le.fsf(a)galatea.local... >> "BGB / cr88192" <cr88192(a)hotmail.com> writes: >>> my experience has been the reverse: >>> my HLL code has tended to be very brittle and unmaintainable in the long >>> term; >>> my C codebase has been one of the most stable parts of the codebase, with >>> many parts of the codebase being around or >1 decade old and still >>> working... >> >> This warrants a finer analysis. >> >> What would be the causes of the brittleness of your HLL code? >> (And what language exactly is it?) >> > > I had moved between languages and implementations some. > [...long story...] Perhaps the reason why your C code base is the most "stable", is because this is the only standardized languages amongst all your experiments? (scheme too is standardized, but instead of switching to a good implementation, you choosed to implement your own one). -- __Pascal Bourguignon__
From: BGB / cr88192 on 8 Dec 2009 11:49 "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message news:87y6ldbrib.fsf(a)galatea.local... > "BGB / cr88192" <cr88192(a)hotmail.com> writes: > >> "Pascal J. Bourguignon" <pjb(a)informatimago.com> wrote in message >> news:873a3me9le.fsf(a)galatea.local... >>> "BGB / cr88192" <cr88192(a)hotmail.com> writes: >>>> my experience has been the reverse: >>>> my HLL code has tended to be very brittle and unmaintainable in the >>>> long >>>> term; >>>> my C codebase has been one of the most stable parts of the codebase, >>>> with >>>> many parts of the codebase being around or >1 decade old and still >>>> working... >>> >>> This warrants a finer analysis. >>> >>> What would be the causes of the brittleness of your HLL code? >>> (And what language exactly is it?) >>> >> >> I had moved between languages and implementations some. >> [...long story...] > > Perhaps the reason why your C code base is the most "stable", is > because this is the only standardized languages amongst all your > experiments? (scheme too is standardized, but instead of switching to > a good implementation, you choosed to implement your own one). > I generally write nearly all my code, including such trivial things as PNG loaders/savers, JPEG loaders/savers, the FLAC audio codec, ... (I think I may also have a partial Theora implementation around somewhere as well, but I forget...). the main reason I guess is that I like a lot of control over the code (what all it does, and how...). I had on-off considered ressurecting it at a few points, but lacked good reason to do so, since it is not exactly a language most people would be inclined to use (even if I did re-add it, and even if people did actually use any of my stuff...). oh well... > > -- > __Pascal Bourguignon__
From: cbcurl on 8 Dec 2009 14:40 On Dec 7, 8:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > Don't be silly, markup languages are not programming languages. They can be. Curl is a programming language that can also be used as a markup language. - C
From: Bill Cunningham on 8 Dec 2009 15:28
"cbcurl" <cbcurl(a)gmail.com> wrote in message news:679a89c3-8396-4672-95ce-58b37558b8f2(a)g7g2000yqa.googlegroups.com... On Dec 7, 8:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > Don't be silly, markup languages are not programming languages. They can be. Curl is a programming language that can also be used as a markup language. What is Curl? Now I've never heard of that. I thought TCL/TK might be mentioned in writing OSs but maybe not. I have never used tcl/tk so I can't comment on it. It's interpreter driven anyway so neither it nor perl could be used for writing OSs. Bill |