Older blog entries for chalst (starting at number 20)

29 Jan 2002 (updated 1 Feb 2002 at 13:31 UTC) »
tk: If there's anyone to blame for the current open-source mess (both in the ideological sense and in the practical sense), it's RMS. He's turned the whole purpose of hacking upside down. Now sharing code, instead of being a by-product of creating a good program, has become an end in itself.

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.

bjf: Wow, this is one offensive post! Do you think `beggars' ie. people escaping the ruination of their homes, *should* not be able to make choices about where they try to start their lives again from nothing? Do you actually blame the economic migrants for making use of human smugglers, knowing that they are going to be treated worse than cattle, and may be killed by these people, for the `fault' of finding the alternative worse?

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.

Good news. Who knows, perhaps Bush might find it convenient to rethink his rejection of the Kyoto agreement?
gman: Me too.

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
or E AdvogatoDiaryEntriesSuck?

slef: I call myself a pragmatist, though I'm not sure what you would call it. I think the freeness of free software is to be valued for itself, but I think it is just one of many goods that exist. Case in point: the companies that have done most to push forward adoption of desktop productivity software, Apple and Microsoft, have both frightful anti-free software credentials, but the usability revolution has helped many knowledge workers who are not computer gurus to get their work done. I think the good done here probably outweighs the harm.

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.

5 Nov 2001 (updated 5 Nov 2001 at 15:21 UTC) »
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.

1 Nov 2001 (updated 6 Feb 2002 at 13:10 UTC) »

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.

11 older entries...

New Advogato Features

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!