Re: [wmii] Re: 10kloc project, wmii maintainer change

From: David Tweed <>
Date: Fri, 21 Jul 2006 18:52:54 +0000 (GMT)

----- Original Message ----
From: Uriel <>
To: wmii community <>
Sent: Thursday, 20 July, 2006 5:31:23 PM
Subject: [wmii] Re: 10kloc project, wmii maintainer change

On 7/20/06, Tianran Chen <> 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
_______________________________________________ mailing list
Received on Fri Jul 21 2006 - 20:53:25 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:11:24 UTC