Lambda the Ultimate

I think the world does need more knock-offs of Ruby, Python, Lua, Smalltalk, and Scheme. And Forth. And ML. And on and on.

It's the only way kids learn and it creates a "generative environment" in which new PL ideas can come into being. It's a good practice for programmers to feel at least a little bit empowered and competent at all levels of their software stacks.

I'm a big fan of free (as in libre) software but I sometimes think about righting a utopian science fiction novel about a future time when, by social compact, all of the computing systems engineers over the age of 30 start refusing to give anyone younger any copies of source code once per decade. Each upcoming generation has to rebuild everything solely on the basis of teachings and the freedom to use already built computing systems for bootstrapping purposes. As a result, this society has seen 150 years of steadily increasing quality and efficiency in their software systems. (Then, because there has to be some dramatic action, one generation of elders goes too far and injects a Thompson-style trojan ("On Trusting Trust") into the bootstrapping tools. The world economy collapses for a decade. There is a witch-hunt for the perpetrators who have great adventures while trying to stealthily correct their mistake. Peace and prosperity return thanks to a global-scale populist movement of New Luddites who will use computing but only mistrustfully and at arms length in an otherwise agrarian society. In the end, the young programmer protagonist "gets the girl" and scurries away to help tend a kelp farm and live happily ever after. The end.)

So, in conclusion, yes - more knock-offs of Ruby and Python, please.

-t

The danger being of course that history's painful lessons aren't learned, and have to be repeated in every generation. I hear that some people are currently reinventing FEXPRs.

Hands off my FEXPRs, man! (Personally, I'm rather fond of them....) :-)

If they aren't doing fexprs exactly the same then it could be a world apart compared with previous incarnations of fexprs. http://lambda-the-ultimate.org/node/3640

I'm wondering if you cited that essay for some specific lesson(s) in it, or just generally (though in either case, thanks for giving me an excuse to reread it!). Of the lessons there, the two that catch my eye as particularly relevant to fexprs are  (1) dynamic scope is a bad idea — true in general, but especially important for fexprs because the single easiest way to make fexprs unmanageable is to make your Lisp dynamically scoped — and  (2) people can believe something fundamental for decades that isn't true, as with the belief that fexprs are inherently unmanageable, when the serious unmanageability comes from mixing them with certain other features like dynamic scope or non-local set!; or (of somewhat more recent vintage) the belief that fexprs can't have a nontrivial formal theory, when that depends on how the operational semantics is mapped onto a calculus.

I thought about doing the same thing. Of course my approach was from that of a total beginner in language design & implementation. Since I'm still learning myself, I was keeping notes on areas that I didn't grasp right away, and I ended up with a fairly good multi-chapter outline (and even did a first draft of the intro chapter + one of the chapters towards the end). But due to time constraints the project has been shelved temporarily. Plus I need to do a lot more reading so I don't give out wrong information accidentally (mostly need to find the correct terminology for what I'm trying to describe).

I've been using CoffeeScript for a month or so, and it's pretty freaking awesome. Jeremy Ashkenas said he wrote that compiler (or 'transpiler') based on this unbelievable book. It's amazing what you can do with a good idea and a bit of succinct advice.

Too bad this book was marketed the way it was, as a blatantly overpriced and overhyped e-book rather than a blog series. Even before it came out, I had considered writing my own book(let) on basic parser/compiler implementation, probably as a free HTML/JS-based interactive tutorial (much like the CoffeeScript manual, actually). It's a no-brainer - the amount of money to be made writing about programming pales in comparison to a typical programmer's income.

I don't think this is targeted for diehard language addicts with Ph.D.'s in Comp Sci. For people like you, I agree, Guy Steele is like Patches O'Houlihan sponsoring a dodgeball team in a Dodgeball tournament.