----- Original Message ---- From: Uriel <[EMAIL PROTECTED]> To: wmii community <[email protected]> Sent: Thursday, 20 July, 2006 5:31:23 PM Subject: [wmii] Re: 10kloc project, wmii maintainer change
On 7/20/06, Tianran Chen <[EMAIL PROTECTED]> wrote: > Geoffrey Alan Washburn writes: > > > Why don't I try educating "him"? Because I don't have time to teach > > people things they really should have learned elsewhere? Because I don't > > really have time for a debate I'll never win? Because people have an > > unfortunate tendency to stick to their chosen ideology regardless of the > > quality of the argument? Until people go out and start learning and using > > other languages and tools, I doubt there is much I can do to convince them > > of anything because there is no shared context. Furthermore, until > > someone has actually tried doing something different and found it lacking, > > they have no argument. So making uneducated claims about the utility of > > C, without knowing anything else, means you've already lost the argument. > > I was a professional Haskell & ML programmer for 2 years, and also did one > project in Erlang. Am I qualified to be educated by you? Can you tell me at > least one thing you cannot be done in C but can be in these (or similar) > languages? Except for tail-recursion, please. | Funny thing is, most, if not all, implementations of those languages | are written in... guess what? C. Talk about hypocrisy. I know I'm going to regret this but... just for the sake of accuracy: You've got to distinguish types of implementation: interpreters and compilers. If you're talking about compilers, GHC the main Haskell compiler is written in Haskell. (Excecpt for the hyper-abundant x86 architecture, it compiles to C as `portable assembler'.) The O'Caml ML-dialect complier is written in ML. Dunno about Erlang: looking at the source tree I can't easily distinguish between runtime, compiler & libraries. To bring in a language not explicitly mentioned, the mixed paradigm language Mercury compiler is written in Mercury. So, for the languages stated above the `most widely used' compilers aren't in C. If you're talking interpreters, there's much more of a tendency to do write things in C because the `modify and re-run' cycle means you just can't do the complicated optimisations you normally do when compiling, so you may as well merge the "language analysis" with the runtime. Since it _does_ make sense to write the runtime in C, the whole thing ends up in C. (To be fair, when you said "those languages" you may have been referring not to those quoted by Geoff, but to more modern languages in general which brings in python/perl/ruby/..., all of which have their primary system currently written in C.) FWIW, I thought about writing Medea (which I haven't updated on sourceforge recently due to insane work pressure on my proper job) in a higher level language. However, I wanted to modify the behaviour of an existing widget toolkit rather than write my own, and the pain of trying to intercept C++ callbacks in anything other than C++ seemed too nasty. I think that, more than anything else, is the biggest reason why new stuff gets written in C (or perhaps C++): no matter how good the language wrappers are, if you want to make intimate use of an existing C code-base it's easier to debug things if it's all C than if you've gone mixed language. Incidentally, that's what I consider to be the one absolutely huge advantage of the unix pipes/acme subprocess way of doing things over the emacs `embed a language' approach. If an application embeds a sub-language, you've pretty much _got_ to write extensions in that language, whereas a subprocess communicating by pipes can be written in a language that the author of the original application would shoot you if he actually knew you were using it just as easily as in the language of the original project. One useful thing that might come out of the 10k project -- I'm a believer in `design for long-term maintainability' rather than `minimise line count' -- is a highly subprocess-divided system, so that it is easier to either enhance or replace a component than it is with more monolithic applications. Anyway, I better put on my asbestos underwear :-) cheers, dave _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
