Linked by Thom Holwerda on Wed 11th Apr 2007 16:35 UTC, submitted by ShlomiFish
General Development "What makes programming languages are suitable or unsuitable as introductory languages? Which languages are better learnt first and at which order? And why what the masses think is the most suitable introductory programming language is not in fact that. This paper examines several approaches to which programming language is the best, and afterwards gives several useful relations for which languages should come first. Finally it gives a final verdict, defends it and then gives some other good food for thought."
Thread beginning with comment 229781
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: lisp/scheme
by rayiner on Thu 12th Apr 2007 00:14 UTC in reply to "RE: lisp/scheme"
Member since:

I recommend you read Tim Sweeney's article on "the next mainstream programming language":

He's the guy behind Epic (of Unreal) fame. I'd hardly label him an ivory-tower academic. In the presentation he points out that the 250,000 lines of computational code in the Unreal 3 engine are "essentially functional".

That said, Lisp's in general make far better imperative languages than any other I've encountered. If the Java folks creamed their pants when they got "foreach", they'd probably have heartbeat irregularities if they got Common Lisp's "loop".

This is advanced stuff, beginners don't need to know about closures. Heck, most programmers don't need to know about closures either...

A closure is a fundamental concept. You teach somebody about closures, and you've given them all the knowledge they need to understand C++ function objects, Java inner classes, C# delegates, and Python iterators, oh, and the basic concept of "object" in all of those languages.

The lack of focus on fundamentals is one thing that really pisses me off about software "engineering". A real engineer goes to college for four years, and spends three of them just learning math.* Sure, you can make an airplane without knowing math, but we already have airplanes. It's the math that let's you say if the design is correct, or how good it is, or how to make it better.

Software engineering is completely different. They try to get away with doing things as ad-hoc as humanly possible. If your average software engineer built the columns to hold up a building, he wouldn't do it by working out the math to figure out how thick it should be. Instead, he'd guess. If the building collapsed, he'd try another size, then another, until he got one that worked. It doesn't matter that he could have saved a lot of time, money, and energy by doing things the right way the first time. Because theory isn't for "real programmers", just for the "eggheads" in their "ivory towers"...

*) Oh, they won't call it math after the first year or so. But I spent my math classes solving differential equations, and I spent all my other classes... solving differential equations. Most engineering classes degenerate into "this is the differential equation that's relevant to ___ (first week); here is how to solve, approximate, and model the behavior of this equation (rest of the semester)".

Edited 2007-04-12 00:18

Reply Parent Score: 5