Older blog entries for chalst (starting at number 14)

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:

• One can perform type inference in dynamically typed languages just as well as for statically typed languages; the difference is that user code is not treated as incorrect if it cannot be assigned one correct type. Most code is type correct, but there are situations where one needs dynamic types: supporting dynamic dispatch on method invocation being the most important.
• The core of Haskell's type system: Hindley-Milner polymorphism plus recursive types, is indeed an elegant system in which one can write a lot of nontrivial code. Not enough, though, and so Haskell supports type classes, an extension needed for the way it integrates IO into its lazy execution mechanism, in the presence of which one loses principal types (ie. the existence of context-independent `best' types for program fragments), and so one finds some puzzling peculiairities in the type system. One also loses the ability to perform separate compilation, rather undermining the arguments for the superior compilation performance of Haskell over dynamically typed languages.
• I'm also struck by the stability of the set of types one has in scheme, compared to the constant calls for extensions to the type system faced in statically typed languages. From a theoretical point of view, I am struck by the ease with which one can model dependent types in dynamically typed languages, a useful-to-programmers type abstraction that cannot by statically type checked. I think it is plausible that scheme's type system is `theoretically complete', ie. there is no need to extend the underlying language to support the types that its programmers need.

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.

slef: Thanks for your thoughts. There are obvious omissions in my last diary entry: you mention Guile, which has nice support for generating stub files. Also I didn't mention SLIB, which is widely enough ported that it covers many of the gaps I mention.

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.

Interesting link: In defence of NMH syndrome - the author argues that companies that redevelop everything from scratch rather than reusing other software are doing the right thing, because they are not forced to accept flakey behaviour in their programs arising from problems `upstream' in the library. Open source development offers a workaround for this - you can participate in the developer mailing lists for the library, feed in patches, whine about problems, and generally be more involved than it is normally possible to do between companies.

Java and open source: I read this piece from Bruce Peren's now defunct Technocrat.net, where Bruce Perens talks about the very lively work done on Open Source J2EE development by people involved in JBoss, Xerces and Jakarta, and the interesting work done on truly open source JDK environments. The thrust of the comments are that the open source JDK environments are not competative with the closed source alternatives, and the development effort is not going in the right direction. My immediate reaction is - it's true and it's depressing.

On the other hand it is good to see that at least a few people see there is a problem. I think one reason for the relatively unenthusiatic adoption of GNU CLASSPATH is the unclear licensing around it: instead of the reasonably well-understood LGPL license, it is mostly licensed under a special GPL-with-exception, whic pretty much amounts to LGPL, but the differences appear nowhere to be made perfectly clear. Anyone who remembers the GNU crusade against KDE will justifiably be suspicious.

I posted a question on Slashdot:

What are the realistic outcomes?
by Chalst on 08-10-01 15:14 (Score:2)
(User #57653 Info) http://achilles.bu.edu/cas
What are the realistic outcomes of the W3C/RAND process? Bruce Perens has
argued that RAND actually discriminates against open source, and argued for RF
(Royalty Free) in its place, but several well-informed people say that the W3C
is unlikely to adopt RF. If RAND is not ND (Non-Discriminatory) and RF is not
acceptable to the W3C, what else could happen?
Dyed-in-the-wool UNIX user, for all its faults.
[ Reply to This | Parent ]

Hope it gets answered, instead of the dumb questions that usually get moderated up.

gstein: Congratulations on getting (i) married and (ii) Subversion self-hosting.

Despite having decided over a week ago that I thought the USA would be justified in an attack on Al Qaeda and the Taliban, my feelings on seeing the cover of today's newspaper ("Tagespiegel", a Berlin daily) were "Oh shit!". My nerves are a bit calmer now. The USA, for just about the first time ever, is going about an intervention in the Middle East in the right way. I don't like calling the operation a "war", but they are being very clear about the difference between the regime and the people (a distinction that was *not* kept in Operation Desert Storm). They've cut off the Taliban diplomatically (getting Saudi Arabia to rescind recognition of the Taliban was important), Bush has obliquely criticised Ariel Sharon by saying he supports the creation of an independent state for Palestinians (about time too!), and budgeted $320 million in humanitarian aid for Afghanistan (it will be needed...). He even made a nice quote: he said of Al Qaeda and similar organisations that they were "barbaric criminals who profane a great religion by committing murder in its name".

I still don't like the operation at an emotional level. I'd be happier if some or all of the following happened:

• The USA apologised for the humanitarian horror they have inflicted on the people of Iraq, and had a humanitarian budget for Iraq too.
• Bush criticised Sharon more directly. He's made conditions in Palestine pretty much as bad as the Warsaw ghetto, and it's not acceptable to turn a blind eye to this, nor to Israel's past violation of the Non Proliferation Treaty. Israeli hawks get away with far too much.
• The USA was honest about the fact that in the past sometimes it has been supportive of terrorism. Until this happens it is too easy to mock its "war on terrorism" as a "war on terrorists the USA doesn't approve of".
• The USA supported the International Criminal Court.

Except for the last, I don't know what the right way is to go about any of these. Doing any of these would make the charge of hypocrisy against the USA harder to sustain, and that has to make bridge building in the Middle East easier.

raph, maelstrom: I've mixed feelings about the Joy implementation project. On the one hand, it isn't just a cleaner version of Forth/Postscript, since making it a `pure' functional language has big effects on the semantics: the language admits *two* interpetations, one as a stack based manipulation language, the other as a combinatory algebra (think of S,K,I combinators).

On the other hand I think the Joy folk don't mention well known antecedent work. The pages on language concepts don't mention Forth or Postscript, and they don't mention work on stack-based implementations of combinator languages (Curien's work on categorical combinators is important here: incidentally the CAM --categorical abstract machine-- was a forerunner of the current implementation of Ocaml, the language maelstrom mentioned). I find this bad scholarship, and I think a desire on the part of the authors to look more original than they are might lie behind it.

W3C and opensource: I find it scary that the larger open source community (OSC) doesn't find out about important consultations like the W3C patent until a few days before the deadline. It is pathetic and embarassing, it makes the OSC look like a bunch of kids and it will hurt. I hope we get better at this. BTW, for UK advogato members, did anyone respond to the government's consultation last year on patenting IP?

mjw: The classpath extensions indeed look very nice, especially JAXP.

Open source Java projects: I'm putting together a project proposal to migrate a Sun JVM system to a separate JNI client using swing and a backend based on the gcj CNI to do heavy duty processing work. It's fun to be able to apply ingenious open source technologies to one's work

I only just saw the Slashdot interview with Miguel de Igaza. Just look at what he says the Mono project must do:

1. A CLI runtime with a JITer for x86 CPUs.
2. A C# compiler.
3. A class library

Let's call the target platform of the GCJ compiler Java/CNI (Java C native interface). The existence of Java/CNI makes doing the equivalent in Java of the first two of these three things very much easier than developing it all from scratch as Mono must do. The CLI run time and Java compiler exist already. Even the third point is well-developed, due the the GNU CLASSPATH and GNU CLASSPATH Extensions projects (now merged with gcc), though there is hard work here: Java/Mono would need an implementation of the Swing classes on Gtk+ (or, heretical thought, Qt).

If Miguel *must* sell his soul to Microsoft, at least he should get something worthwhile for his sacrifice. Since the true-GNU java based alternative is already so developed, I don't see the point.

WTC bombing aftermath: It's been about two weeks since I last posted, and that was a number of entries about the WTO bombing and my fears about gung-ho American reprisals. I'm very happy to say that it looks like my early fears were wrong, and the US is taking a long term view, trying to repair relationships with muslim countries, and making sure it has multi-lateral support for its attack on Bin Laden and his peers. I'm very impressed. My opinion of Bush has gone from pretty much nothing to a very good measure of respect. My hopes now stretch to a resolution of the humanitarian horror in Iraq...

GCJ and Java: I'm thinking about a new project, splitting up a graph transformation engine written in Java to a UI part and a server part, allowing the Swing-less server part to be compiled with the new GCJ compiler (part of gcc 3.0; gcc is a really impressive achievement) to native code. I wonder if anyone has experience of similar projects. I wonder also if GCJ makes Java more interesting to open source developers?

Ironic postscript (06-02-2002): I see that Bush does have ideas about `resolving' the crisis in Iraq...