Hear, hear!
Postscript, 1st Feb: RMS *invented* the license flame industry, which is why Microsoft can get away with the whole `open source doesn't work for business' FUD.
I really hate replying to these posts, but I can't let this nonsense stand unopposed. The worst thing is bjf obviously feels he is being fair and balanced.
Upped my self certification from Apprentice to Journeyer, for reasons I am too hungover to explain here.
Slashdot style poll: Which company's strategy most impacts the Free Software plan for World Domination? Is it:
A Microsoft
B Red Hat
C Sun
D IBM
or E AdvogatoDiaryEntriesSuck?
Dynamic vs. static typing: Unusually long time to respond to a diary entry -- graydon posted an argument for the superiority of statically typed systems over dynamically typed system back in March. He points out that with type inference one of the usual complaints about type declarations vanish, and indeed one must tell the computer less about types than one must with dynamically typed systems.
I'm not convinced though:
I finally posted this entry after reading Kent Pitman's second set of interview responses on slashdot: his comments to question 14 are relevant here.
What irritates me is that the way Guile does scsh-like functionality is quite different to the way scsh does it, and so one can't write portable code there. And each dialect of scheme has it's own, incompatible exception mechanism, and different, incompatible module system, and different incompatible structure generation facility.
There's convergence in terms of functionality, but not in terms of the actually invocations the user makes. I like the kernel of scheme much more than I like these other languages. I guess (i) a SRFI covering the generation of C stub files and (ii) ports of scsh functionality would cover most of what bothered me in my last diary entry.
Thoughts on the state of scheme: Just how practical is Scheme as a programming language? There's a lot right with scheme --I think it is probably the least broken language extant-- but also a lot wrong with it: as per R4RS and R5RS it lacks an exception mechanism, a module system, and what would normally pass for a standard library, which pretty much makes it unusable for the purposes that C/ C++/ perl/ python/ common lisp/ etc. are used.
On the other hand, all of these mechanisms are corrected in a number of good scheme implementations, but... not in the same way in each, so each implementation in effect describes a new dialect of scheme, and each has strengths that I really would want from my main programming language, but lacks others.
- Scsh is 9/10ths of the way to being a total Perl replacement (closer than python, IMO) with one of the truly thought through ways of mapping a higher-typed language onto UNIX, but fails on three crucial points: no easy way of making `wrappers' for C libraries, no shared objects, and a perceptible initialisation time. I use scsh as my other programming language (Java I guess is my main language).
- Scheme->C has great ability to interface to C, and share objects, but lacks both the `scriptability' of scsh, and the good interface to the common things one wants to do with the language.
- And then there's Stalin: one of the truly great compiler implementations, but in a dialect of Scheme that is, of course, incompatible with either of the above for anything that one want's to do in systems programming (like open a file and reading it 8 bits at a time). Nice performance: I was at a talk of Siskind's where he described how for some scheme reimplementations of the BSD utilities he got performance between 4 and 6 times faster than the gcc-generated executables of the C originals.
- Kawa looks great, but of course, doesn't have standard libraries (it uses the Java platform for all its library needs) and doesn't have the option to run off of the JVM platform.
There's the SRFI process, which aims at filling in this gap with an IETF-like procedure, but it doesn't have the backing of the whole scheme community: Siskind was very rude about it, I think out of ignorance of what the RFI process is, but the effect is just as bad. Does anybody else find this situation sad? Does anyone else actually use (R4RS/IEEE1178-compliant) scheme for practical programming?
Postscript (Wed 06/02/2002): Looking back over old USENET posts, I found this classic contribution from Olin Shivers. While the above still stands, it's really remarkable what progress has been made in the scheme world since Olin said that.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!