Arc and innovation

Some blogs and mailing lists are full of a discussion about the innovations in Arc. One partial consensus seems to be 'to little, to late' at least for an magnum opus. If you want to see an firework of innovation in programming languages, take a look at Wouter van Oortmerssens programming language page. You absolutely must see the visual programming examples and all the other ideas which question the fundamentals of programming language understanding. Pure genius.

Show me functional programming, I have no clue (obviously)

Functional programming is heating up. In several discussions over the blogosphere and on my blog others think I have no clue what functional programming is. After some consideration, I think they are right. I have no clue.

Well I do know what functional programming is. I've used it myself. But I have no clue how to do a business application in FP. Others don't know either. They talk about Bezier curves, square roots, fix points, y-combinators, power functions or remodel FP into OO and think that's still FP. Weird.

Suppose I need to write an application. There are customers who can buy products. Based on the customer and the products he bought he can buy other products. Those products he books do cost him money which he needs to pay to the company. I'm quite sure how to design such an application in OO, discuss it with some domain experts and write the code. I also know how to write such an application in a way that other developers in 5 years from now can read, undestand and extend the code.

But how would I write such an application in Lisp? Or Arc? Teach me.

Paul Graham is priceless

"Character sets are a peripheral matter. The only reason they loom so large in the average programmer's life is that, though trivial, they're an enormous time suck. Trivial + time consuming. Sounds like a good thing to postpone."

He has absolutely no clue about unicode. I and every other Java developer has been using unicode for more than 10 years now, and beside some i18n issues, I/O and String comparisons, they are a non issue if the language supports them.

One is always a bit sheepish about writing quick and dirty programs. And yet some, if not most, of the best programs began that way. And some, if not most, of the most spectacular failures in software have been perpetrated by people trying to do the opposite.


This renders all the discussions lately just mood. PG has no experience with software development, engineering, maintenance, or anything else except writing cute dirty hacks in Lisp. If he does, enlighten me. His release of Arc doesn't help.

Update: Take an advice from someone who has written real world applications.

Remembering Tada-List in 579 lines of code – not impressed

Tada-List was written in 579 lines of Rails code. Jeff of Coding Horror writes "[...], I agree with Joseph: it's an impressive achievement, [...]". I'm not impressed. If you write a framework for a narrow group of applications, it should be easy to write a small target application with a few lines of code. And they don't count HTML.Top this: a game written in ZERO lines of code.

Most code is hidden in the framework. Taking it to the extreme, with XL/R and concept programming I could write TaDa List in one line of code:


The issue remains. It's the same with encryption. There is a message and a key. How much information is in the key and the message? If the key is "Hello World" then the message can just be "1". If the key is "1" then the message needs to be "Hello World". How much code is in the framework and the application?

That aside. My biggest achivement in small code size was a 1024 bytes (the boot sector size of an Amiga) boot selector menu with color bars. Impressive if you consider we had to put all the menu text into those 1024 bytes.