Older blog entries for chalst (starting at number 31)

9 Apr 2002 (updated 9 Apr 2002 at 19:12 UTC) »

Putting the finishing touches on an article that's been accepted by the JCSS. Nice to see the end of it. My contact with the publisher has been good, but it kind of sticks in the throat having to sign away my copyright rights to a giant publisher.

zhaoway: I'm interested to hear about your progress with Clean: I've never used it, but I've heard rather a lot about, and I'm particularly interested in the attempt to give semantics for it using term-graph rewriting. I'm also interested in the idea of using ILL-inspired ideas about control of resources.

pom: Good lead, and good work. I've been looking for something like pigale for a while.

Postscript: Does anyone know of a good way to switch off Ctrl-S/Ctrl-Q SUSPEND/RESUME terminal behaviour. By good I mean a simple way that works at most shells, on weird UNIX systems and almost all tty providing contexts?

Lots of pressure: conference deadline 1st April and I haven't even proven all my results yet. And it's to be coauthored, and my coauthor hasn't any of my new results in over a year. Better get moving...

raph: Very nice post, has got me thinking... Some immediate reactions: not all LISP-like implementations have bad FFIs: in the scheme world guile and scheme->C have good FFIs and scheme48 (my favourite dialect) has a reasonable FFI. I think FFIs in the scheme world are better, on the whole, than in the Common LISP world, but that maybe just my prejudice speaking. Scsh (built on scheme48 and with a forthcoming guile implementation) has excellent IO facilities, maybe the best of any language I know (I know C, Scheme, C++, Java and Python reasonably well).

Dynamic languages need not be inefficient: checkout the papers on soft typing at the Rice repository (especially Matthias Felleisen's papers). The basic idea behind soft typing is that when you apply type inference for reasonable type systems to dynamic languages, most functions are typable. So you only need the run-time overhead of dynamic type dispatch where it is really needed.

Biotechnology: Read this recent Economist book review, I think I will buy the book. I am impressed by the potential of DNA computing (essentially it is engineering with life-like processes). This technology sidesteps the ethical difficulties and ecological dangers associated with mainstream bio-technology, and, it seems to me, it pretty much has all the medical and agricultural potential of bio-technology (eg. DNA machines can produce just the same range of proteins as live DNA, so it seems reasonable to suppose that anything that can be done by splicing genes into organisms can be done by DNA `helpers' living symbiotically inside an untampered with organism). Not heard this thought before, so I thought I'd get it off my chest.

jfleck: Got to say, I've never found a Zippy cartoon funny.

18 Mar 2002 (updated 18 Mar 2002 at 21:48 UTC) »

Hi again, advogato. Three week surprise honeymoon in South Africa. Unsurprisingly mixed feelings about being back... Three and a half weeks without any responsibility to read email is something I definitely like the idea of doing from time to time...

zhaoway: I find `which language is best' arguments to be uniformly tiresome. Much better to ask what the strengths and weaknesses are of particular languages, eg. for programming a particular kind of task, for future employability of developers and maintainers, for compiler efficiency, for expressive completeness, for FFI, etc. Python clearly has many strengths that LISP/scheme lack, also vica versa. Python seems better suited to the neophyte computer programmer than scheme/LISP, with fewer pitfalls early on the path to learning and a more widely appeciated syntax. It also has perhaps the most user-responsive developer communities of any programming languages. Schemers invented the RFI process, pythonians made it work.

The advantages of LISP/scheme come later in a programmers development: expressive completeness, program writing programs, concurrency/distributed computing with continuations, control over the compilation process. I think it is a pretty elitist language, despite the TeachScheme! initiative, with correspondingly poor network effects (fewer people working on compilers, fewer chances of replacing key developers, fewer off-the-shelf libraries).

Goodbye dear diary. I'm getting married tomorrow and won't get back from my Hochzeitsreise (honeymoon) until mid-March. Cheerio, Advogato!

zhaoway: Hmm. Closures are a piece of implementation technology, which ensure that recursion can occur without the latest invocation of a function messing up the older invocations local variables. They've been around for a while, but closures can be stack allocated (like C) or heap allocated (like Scheme). To have continuations and tail recursion you need to heap allocate your closures.

Currying is *quite* different, it is a piece of semantics. It is a correspondence between functions with two arguments and functions with one argument that return a function with one argument, eg. currying this:
(lambda (x y) (+ x y))
gives you this:
(lambda (x) (lambda (y) (+ x y)))

Languages like ML and Haskell use currying implicitly in their syntax, it can be quite nice to have. You can use macros to do the same thing in Scheme, not many people do, though.

davidw: scsh has excellent text munging facilities, with a family of string split like functions. It's designed to be used in place of Perl, so the standard library for scsh doesn't omit these kinds of things. These utilities are also covered in SRFI's 13 and 14.

It's not so surprising that regular scheme omits these things: this string manipulation is a characteristic of a kind of programming that scheme wasn't designed to cater for.

What is up with Tom Lord's `arch' project? I trust CVS, Subversion and Bitkeeper not to lose my data. Why should I trust arch?

zhaoway: Nice to feel I made a difference! But my, you want to call C and still feel functional? That's a tough call... Maybe the `little languages' approach to calling the outside world can help?

zhaoway again: Continuation hacking is not unique to scheme/LISP (SML/NJ has call/cc), but scheme is in many ways its natural home: Guy Steele's original rabbit compiler introduced the idea that coninuation-passing-style might be a good way to build a compiler. A lot of water has passed under *that* bridge since then...

welisc: Well, if you're modelling proteins I guess compiler efficiency is a big issue, and I don't think scsh runs on any implementations which stress compiler efficiency. I guess I'd stick with OCaml, but if you are interested in getting deep into scheme48 (scsh's mother) you *can* program the performance critical parts in prescheme. I'm afraid the learning curve for prescheme is pretty steep, I haven't scaled it myself yet.

6 Feb 2002 (updated 6 Feb 2002 at 12:56 UTC) »
zoltron: I thought baseball mattered more to Bostonians than American football? Anyway, I know how you feel: that was a big day for Boston.

hacker: "...get legal advice from a US attorney before making any more statements to any of our customers or potential customers..."
That doesn't sound like bad advice to me, I have to say...

DV: You might do Miguel more of a service by defending his position, rather than performing public flamings on people who email you in private. Regardless of what the Register says, I find Miguel's ideas about Mono in GNOME... odd. I've written about this in a past diary entry.

welisc: What is it you like about OCaml? I've a hunch that most free software types who use OCaml would find scsh a better fit for their needs. OCaml has big strengths in the area of compiled code efficiency, and has nice support for linux threads, but for most programming tasks I think these strengths aren't needed, and OCaml has its weaknesses, too. I suppose scsh doesn't have an O'Reilly book, though,... *sigh*.

braden: C++ templates are cool, but LISP/scheme macros are cooler. I read about a language out there ('C, pronounced `Backquote C') that simply adds LISP-style macros and S-exps to C to get something surprisingly nice...

Postscript: A candidate for Cryptogram's doghouse?

3 Feb 2002 (updated 4 Feb 2002 at 12:43 UTC) »
zhaoway: Most scheme compilers have some kind of FFI that allows you to use C libraries with scheme code. Guile's I hear is particularly easy to use, also scheme->C. Scheme48 also allows you to write in prescheme, a stripped down, closure-free, scheme that compiles to code that is approximately as fast as C code.

Postscript #1: I'm contemplating buying a GPRS capable mobile phone. Any ideas on what is good. I like the Siemen's S45, ME45, what else is on offer?

Postscript #2: I have to say I am disappointed by the response to the article I posted. No-one offered criticism of the argument, rather, the general attitude seems to be `the Bush administration is in hoc to big business so it's all a waste of time'. Very depressing.

Postscript #3: Just heard the news about Boston's success. Well done loyal Bostonians, and good luck with the World Series!

1 Feb 2002 (updated 4 Feb 2002 at 12:33 UTC) »
exa: You can't, the idea is not to post twice. You can always resist the temptation to press the `send' button again *until* you have checked your first press wasn't heard by the advogato server. Think of it as an `ordeal by temptation'. Expect to have `Journeyer' certs downgraded to `Apprentice'.

badvogato: I'm innocent, really! I'd never even heard of `preemptive threading' until I did it! I'm not naughty on purpose.

Postscript: badvogato is indubitably a CMoMM.

Postscript #2: looking for an old USENET correspondent (Paul Marks), I found this old post. What a prize turkey Shawn Wilson was! I hope he still has an academic appointment, and his *response* to my post (no kidding) turns up to haunt him... or even better this (cringes with vicarious embarrassment). Top result for `Charles Stewart Shawn Wilson' on google groups, btw =D

Postscript #3 (3rd Feb) tk: Perhaps you are right...

22 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!