Lambda the Ultimate

• -- rfn is not necessary (why not "foo = fn (x) (... (foo ...))")
• -- cond make it easy to have errors (the cond and value are not grouped, uneven lists allowed because of the last "default")
  ("with", (eg: "(with (x 0 y 1) (+ x y))") doesn't have the pb since the variable names are better checked)
• -- Functions on Indices: ("hello" 2) -> "l"
  dangerous without type inference for catching typos, function call being the do-it-all function. Hard to read?
  does ("hello" 2 4) works? in that case what does it do?
• --- global variable *fail* on hash lookup error
• --- "if", "while" binds variable "it"
  "if (a x)" is equivalent to "if (it = (a x))", reminds the $_ in perl
• -- "keep" and "sum" to ad'hoc for me. Do not scale. Either use grep/filter & foldl, or use typical imperative programming (push & +=)
• / Parameter Lists: overkill?
• / how is solved the python pb of scoping? (in python variables are function-wide scoped)
• / Strings Work Like Lists. ok but beware of unicode (perl doesn't have indexing on strings and lives quite nicely)

Opinions?

Thinking more about this I realized the importance of scoping, in this scheme. It seemed to me that part of the reason this was so important was the fact that the language constructs I used were Scheme-like (functional). In order to do anything useful I had to be able to nest the pattern-action rules inside let expressions etc. Now try to see how this scales up without proper lexical scoping.

Opinions?

If a language had only, say, 10 users, would it be good ? It probably wouldn't have many of the useful libraries programmers take for granted in popular languages. Depending on who the users are, the language designer might not get feedback he/she could use to refine the language or add new features. Since the user community is small, it would be harder for new users to join; the language probably wouldn't have many books written on it, and there might not be a newsgroup or other forum where novices can ask questions. And it's not likely that the language's compiler or interpreter would be ported to many platforms, restricting the user base even more.

Obviously, every language starts out small. But to be a good language, that language needs to grow and spread. Even if it has compelling features, without a decent-sized user base, the language won't develop. (There is a plant metaphor here; if a tree is planted in a pot which is too small, its roots will be choked and the plant will die. Same for a programming language.)

Of course, a language needs to have some useful features for it to be adopted, before it can get the large user base. So, there is a kind of feedback or resonance required for a language to become popular. (The features attract users who add/change things, which attracts more users...)

That seemed to be the one bit that significantly changes the semantics compared to Lisp, but maybe only because I didn't understand it... It sounds a bit like Aspect Oriented programming (which I don't understand either - maybe that's the connection ;-)

I really enjoyed Paul Graham's article. Most of his points rang true, and even gave a new perspective about my own personal choice of programming languages. I do think he missed a couple of items about what drives the choice of programming language:

1. Accessibility - I'm referring to language accessibility, syntactically if not semantically. We only learn one programming language as the first language, all the rest are learned when we already know at least one prior language, and have some (mis)conceptions about what a programming language should look like. I wonder how popular C++ would have become had it not retained backwards compatibility with C. Java's creators elected to go with a C/C++ look despite that fact that the language is probably closer to Smalltalk in spirit.

   Most programmers (hackers) learn new programming languages by themselves, not in University courses. Languages that introduce new programming paradigms are definitely a challenge in this context. Understanding OOP while learning C++ on my own was hard. C++ eased my pain by allowing we to fall back on C whenever the going got too ruff. Now I'm studying functional programming and again its pretty hard (add to that that I'm doing this as a hobby outside my main work duties). OTOH is a programming language introduces no new paradigm, what's the point?

2. Development Environment - Paul refers to libraries, but I think this concept should be generalized to include development environments and frameworks. VB is a linguistic hack, yet it's immensely popular. The reason: the powerful VB development environment and the numerous third-party controls. Most of these controls were not written is VB BTW, an intrinsic testament to that languages weakness.
3. Perception - Some languages are associated with a specific programming niche. They get a "reputation". As for people, such reputations can be hard to overcome. I think Lisp/Scheme suffers from a reputation of being a highbrow language for academic types. Perl OTOH has a reputation for being the right tool for "getting things done". One of my current favorites, JavaScript, has the unfortunate reputation of being a toy language for creating rollover effects (Sjoerd and I are trying to fix this :)
4. Target - This one is rather obvious, some languages are better suited for some tasks than others. C/C++ for system development, Fortran (now maybe also C/C++) for numerics, VB for database front-ends, Java and C# for the middle-tier (or so Sun and MS hope), and all various little languages for their specific tasks. Since some types of programming tasks are more common (popular?) than others, so are the respective languages. I must say that it's not entirely clear to me what Paul Graham intends Arc's "field of expertise" to be. Probably the same as Perl/Python/Ruby, but that's just a guess.

Actually, Java is close to C++ and far away from Smalltalk, and seems to be moving closer to C++ all the time. This (in my opinion) is why Java has been successful. It allowed people to be buzzword compliant without having to really learn anything new.

Objective-C is more backwards compatible with C, and has been unsuccessful, primarily because it stressed a concept that was foreign: message passing a la Smalltalk.

http://cm.bell-labs.com/cm/cs/who/wadler/armstrong.ps

From a talk called "Erlang: bits of history, words of advice of Ericsson products" by Joe Armstrong.

(Reluctant to post slides by themselves, a filthy habbit, but they're interesting I think). I'd like to have heard the talk :-)

Expert programmers, on the other hand, care only about power, and are going to be annoyed with any language that gets in their way in the name of safety.

I have to disagree that Expert programmers do not care about safety. (Or if they do not care they should.) The average expert programmer probably makes on average one error for every ten lines of code. Fixing a defect found by the compiler takes about two minutes on average. Fixing a defect found in unit test takes about ten minutes on average. Fixing a defect found in system test probably takes an hour or more on average. The more defects found by the compiler the less defects that must be found by the human. Safety features allow the computer to find defects rather than the programmer. I agree that power is useful, but safety features should exist and be disableable rather than not exist at all.

Right!

I wanted to see if anyone thinks the same way, so I didn't point this out earlier. Indeed, perhaps the best way to distinguish between an enthusiastic hacker and an expert programmer, is that the expert acknowledges the possibility of errors, and cares about safety.

I think the fatal flaw of the original article is in equating the hacker and the expert professional.

Notice that this can be a state of mind thing. I can hack, and I can (try to) do professional programming. I often do both by starting out hacking, and trying to clean things up later on.

I think that choosing a safe language (e.g., Ada) for mission critical software (like guided missiles) is part of being an expert.

This is getting off-topic but I can't just let it go :)

Actually, Java is close to C++ and far away from Smalltalk

Obviously Java is very similar to C/C++. As I had pointed out, that was the whole point (or one of the points). The flow controls statements etc. The similarity to Smalltalk is in how Java implements the object oriented programming paradigm. Some examples:

1. Everything must be an object or a part of one. No stand alone functions.
2. All objects derive from a single common base class.
3. Built-in types are also objects (see item 1)
4. All functions are virtual
5. GC
6. Pass by referrence

I'm not a Smalltalk expert, but it's clear that the Java OO model is very different from C++.

The major difference between Java and Smalltalk is that Smalltalk has message passing. Java does not.

Smalltalk is dynamically typed, and has true class methods. Java is statically typed, and does not have real class methods.

In Smalltalk, variables are not accessed directly; variables always have accessors. This is not true in Java, and can lead to coupling problems.

As for points 1 and 3, value types (int, boolean, float, etc.) are not instances of classes (i.e. Objects). If you want to invoke a method on a primitive, you have to "wrap" it in an Object.

Point 6 was covered in an earlier discussion here at LtU on mistakes Java programmers make. Java only supports call-by-value, not call-by-reference.

Java's object model may be "very different from C++," but it sure isn't close to Smalltalk's.

Forgive me if I'm committing some sort of faux pas, but a lot of what is said in "What makes a language popular" has already been done by Rebol. And yet Rebol hasn't exactly swept the world either. (Quick diclaimer: I've only started looking at Rebol in the last few days).

I have heard Rebol dismissed as "a cleaned up Scheme", but isn't that the sort of thing that Arc is looking to do for Lisp?

Many of the suggestions of things that can be used to help make a language popular seem to have already been adopted by Rebol, a few quick examples being:

One of the comments was that hackers don't like to use the shift key if they can help it. Rebol uses square brackets [ ] for its blocks, unlike (shifted) parentheses.

Another comment was about the desirability of prefix operators over infix. Rebol allows +, *, and /, (and probably others for all I know), to be used as either infix or prefix, thereby avoiding the problem altogether.

Libraries were said to be important, they have to be easy to use and fit in well with the language. Rebol has built-in support for TCP, FTP, HTTP, NNTP, POP, SMTP, etc.

It has also been ported to umpteen different platforms as well.

And yet despite all these advantages, all cited by the article as necessary to make a langauge popular, hardly anyone has heard of it.

I think the problem of making a language successful has more to do with its "familiarity" than anything else. Java was successful because it looked like C++. C++ was successful because it looked like C. C was successful because it was basically a high-level assembler. Each was successful by building on what was familiar.

Unfortunately, functional paradigms are not familiar because they are not taught. I have a degree in Computational Science, but only discovered the significance of FP relatively recently, 14 years after I graduated. And if there is no guarantee that even a graduate will be familiar with these concepts, what are the chances of the large number of programmers with only a limited higher education?

Personally, I suspect that ideas like FP will only become popular when it has reached a critical mass of mindshare amongst the programming community, and that that will probably only be achieved by languages like Python in which FP concepts have been "bolted on" rather than being fundamental to the language itself.

no open source version? IMO it doesn't help spreading a language (unless the language is pushed by a big corporation of course)

I think the problem of making a language successful has more to do with its "familiarity" than anything else.

Agreed, syntax familiarity especially must not be under-estimated. Using <tt>":"</tt> for the assignment operator may be a little too much for some :)

Talking about this, I've searched a "syntax across languages" document. Since I couldn't find one, I made one (not as complete as i'd like it to be, contributions welcome)

The main purpose is to help making choices for things you don't care much about. In that case, choosing the most commonly used syntax may be a good solution.