(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Wednesday, December 20, 2006
  Giles Bowkett turns language elitism upside down

To say that Lisp is a language of the gods, and Java is a language for mortals, that could in fact be getting everything entirely backwards. Scheme is actually easier to use than Java. So the easier language is the language of the gods, and the hard one is the one for regular people? How does that make sense?
—Giles Bowkett, What If There Are No Gods?

Isn’t the idea that languages like Scheme and SmallTalk are easier to use than languages like C# and Java very interesting? Is this true? How could this be? The conventional wisdom is that languages like Scheme are too abstract. How could so-called novices grasp concepts like recursion, mapping, and folding when they have trouble remembering that the main method must be static?

The authors of The Little Schemer and The Little MLer bring deep and important insights to the Java language. Every serious Java programmer should own a copy.
Could it be that more abstract languages are smaller languages? With a more abstract language, there are obviously fewer things you need to use to write even complex functions. That’s the expressiveness people talk about: everyone grasps the idea that some languages let you express an algorithm in fewer bits of information. So with these languages, you need to use fewer bits of information to express each idea.

Could it be that these same languages require you to learn fewer bits of information as well?

I am reminded of one of those silly “Men are from Mars, degrees are from mail-order stores” aphorisms. The idea was that every bit of kindness is worth one point, no more no less. One rose? One point. A dozen roses? The same one point.

We talk about some ideas (like mapping and folding) as if they are intrinsically harder to grasp and learn than other ideas (like iteration). But maybe it doesn’t require more bits to learn? Maybe map is one point and iteration is one point, even though we want to think that map is twelve points and iteration is two points?

If that’s the case, could a language with fewer ideas that can be combined in succinct ways be easier to learn than a language with lots of different weak ideas?



Comments on “Giles Bowkett turns language elitism upside down:
How do you prove that your expressive program is correct?

Expressive programs make it easier to prove by inspection, but that just means our programs will be much bigger when we realize that proof by inspection no longer works.

A lot of (misguided) folks believe that static analysis is the answer here; expressive languages openly flout this idea but languages like VB, Java and C# embrace it fiercely... to the point of trying to make a language that even an idiot can use.
Isn't static typing orthogonal to expressiveness? ML, OCaml, and Haskell are statically typed and have phenomenal support for higher-order programming.

From my learning so far, in fact I would say that ML has a static typing system that actually works.
In the case of this girl I was teaching, she had trouble with main and static because they were just words -- they didn't have any meaning attached to them at all. Meaningless words are harder to remember. And I don't necessarily know if I can totally stand by everything I said. In fact I'm alarmed how many people noticed it.

But in the case of this girl, she thought Scheme was easy because it was consistent, and everything was there for a reason. Since she could make sense of it, she could program in it. To jump from Scheme to Java is a pretty abrupt shift. Java might even be one of the worst languages for teaching novice programmers there is, because it has so many parts that absolutely require OOP experience to even make sense in the first place.

I don't know if my generalizations in that post are entirely defensible, to some point I was just screwing around. Certainly, it's a very good question whether my student would have had the same attitude if they'd started her on Common Lisp instead of Scheme, when Scheme is so compact and Common Lisp is so sprawling. I do think, however, that if Scheme was the mainstream heavyweight and Java was the weird marginal thing, the world would probably have a lot more really good software.
Functional is Just Harder. Period. Look at anyone anywhere learning (as first language, or not, doesn't really matter) functional, compared to someone learning imperative. No contest.

The problem with teaching java is Hello World. Have a look at the java hello world variant. To fully grok the whole Java Hello World, you need to be aware of over half the entire game. We touch on classes, the classpath, methods, static methods, arrays, parameters, return types, strings, calling methods on objects, calling methods on classes, and call chaining.

Holy f(*k!

I suggest you start people on e.g. beanshell before giving them the full java. In beanshell, hello world becomes:

System.out.println("Hello World!");

which is somewhat easier to deal with.

Very insightful comment. I think we're in violent agreement: imperative languages need not be difficult to learn.

FWIW, Scheme is by definition an imperative language. Scheme requires five special forms and builds everything else on top of those five forms.

Although there aren't any looping special forms, one of the five is set! which mutates state. Therefore, the core, Turing Tar Pit version of Scheme is imperative without being iterative.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /