Lambda the Ultimate

[ As an aside, I've often wondered if a Smalltalk clone which looked a bit more like C (using {} for code block instead of [], etc.) wouldn't be more successful. ]

Supercollider, James McCartney's music synthesis language, is exactly that. (BTW, James reads LTU.)

Thanks for the link.

The examples I've seen looks really nice, I wonder how such jewel can stay totally unknown like this: it even has a real-time GC!

Looking at it further, I don't wonder anymore: the website is mmmh not too much informative (in comparison to say D's website) ,it used to be Mac centric (probably the platform where there is the smallest number of programmers), and it seems like the language is seen only as a part of the music synthesis environment, a very specialised topic.

The examples I've seen looks really nice, I wonder how such jewel can stay totally unknown like this: it even has a real-time GC!

Actually, I believe Supercollider is very well known, at least among those interested in music synthesis. A quick google search returns two-thirds as many results for "supercollider synthesis" as for "max/msp synthesis", which of course is a highly scientific way to verify my intuition...

I meant unknown in the developers community: the language looks interesting in itself as it has features that 'fashionable' language don't even dream to have (a realtime GC in Ruby or D? Hah!).

But the more I have looked at the (messy) website, the more disappointed I am about the documentation :-(

OK, I've finally found some documentation.

The language is interesting, but they should have removed Smalltalk-like restriction to have the variable declared at the beginning of the function.
Between the declaration and the assignment, the variable is in 'nil-space' which will create a runtime error if you do something with it: it's much better to declare it when you want to use it, so any 'premature usage' of the variable wouldn't compile.

Also, by default list are ',' separated and function calls are by position not by keyword. This looks more C-ish but I'm not sure that it's the best choice.

they should have removed Smalltalk-like restriction to have the variable declared at the beginning of the function.

I agree now that 'let' would have been better, but at least SC is better than scripting languages that allow assignment without declaration leading to ambiguous scoping.

function calls are by position not by keyword

Any function argument may be passed by position OR keyword at the option of the caller. Keyword arguments may appear in any order.

Thanks for your answer, note that IMHO the language is ok but the big problem is the documentation: the website is a mess, and it has broken links, so I nearly gave up searching about the documentation (took me three frustrating trials).
All the documentation talks about the music synthesiser and nearly none about the language itself..

Yes I am here, but I missed this thread. There is an effort afoot on the sc mailing list to come up with a better website.

As far as using := for assignment: Once when I was proposing a few syntax changes, one of the more prominent users said "are we going to have to start using little penises for assignment too?" I will never look at colon equals the same way again !

no separated section and for example use ':=' to declare a variable instead of '=' for normal assignment or a short keyword such as 'var' not 'variable'.

... or 'let', as in most functional programming languages and JS2.

I would say that Python doesn't even go enough "TOOWTDI": it should accept only whitespace for blocks and reject tabs.

Not related but it should also fully unite type and class and get rid of all these annoying self and it would good.

I recently heard a classmate who needed to learn C for a project lament that the tutorial she was following introduced more than one way to open a file (open, fopen, C++ iostreams), all seemingly equal in her mind. She was put off by this and switched back to Java at the risk of the professor's ire.

Java file I/O is "simple"? I'm sorry, but I have to laugh at this. Remind me, which is the correct combination of FileReader, BufferedReader, Reader, FormattedInputStream, FileInputStream, etc?

To me, this just shows that familiarity is what matters to most people most of the time. Actually, this is an argument against "TOOWTDI", since a language that caters to several other languages' ways to do things can be familiar to users of all of them.

As soon as she had said this I thought back to my Java days and all I could remember was the mess you brought up :) The source of her trouble was not that C was more difficult than Java, but that in Java she already knew the "right way" to read from a file (whatever that may be, I'm not sure myself), whereas in C, she was presented from the start with all the available methods to open a file and was confused by the choice.

Python is widely heralded as an easy-to-learn language, although its power is certainly not limited by this. Why? Because above all, GvR sticks to the motto "there's only one way to do it".

Suppose you to want to do something to each element of an array in Python. You can choose from:

* for loop
* map
* list comprehension

List comprehensions are used where you'd have used map, before, except that you can have an 'if' in there as well.

If you're doing...

for x in y:
out = []
blah = ...
out.append(blah)
return out

...then you should be using a list comprehension. :)

And apparently map() is going away precisely because of the duplication with
[myfunc(x) for x in y] .

functions would be 'multimethods', i.e. all parameters of a function would be taken into account as predicates for the actual function to execute. This not only simplifies object-oriented code, but it makes syntax nicer (no need for many levels of identation) and solves a fundamental problem of OOP (where to put code that does not belong in one single object).

I was following you right up until this section. Could you elaborate a bit?

In "traditional" OOP, the subroutine to execute is chosen by the object type. For example:

class TextBox extends Widget {
    public void setContent(String s) ...
    public void setContent(Int i) ...
}

class Button extends Widget {
    public void setContent(String s) ...
    public void setContent(Int i) ...
}

Widget a = new TextBox();
Widget b = new Button();

a.setContent("hello world");
a.setContent(1);
b.setContent("hello world");
b.setContent(1);

In the above example, the code a.setContent("hello world") invokes the function 'setContext(String)' for a TextBox, because behind the Widget 'a' lies a TextBox. Same goes for Button.

It would be simpler if we could do the following:

class Widget ...

class TextBox extends Widget ...

void setContent(TextBox tb, String s) ...
void setContent(TextBox tb, Int i) ...

class Button extends Widget ...

void setContent(Button btn, String s) ...
void setContent(Button btn, Int i) ...

Widget a = new TextBox();
Widget b = new Button();

setContent(a, "hello world");
setContent(a, 1);
setContent(b, "hello world");
setContent(b, 1);

(Excuse the Java-like syntax - only used for illustrative purposes).

In the above example, the code setContent(b, "hello world") would call the Button version of 'setContent', just like in 'tradional' object-oriented code.

Selection of the appropriate routine to call would also be done not only on the 1st argument, but on the 2nd argument as well.

The benefit of this approach is that, if, for example, wanted to code routines that handled collision between shapes, it would be very easy; for example:

void checkCollision(Rectangle a, Rectangle b) ...
void checkCollision(Rectangle a, Circle b) ...
void checkCollision(Circle a, Circle b) ...
void checkCollision(Circle a, Rectangle b) ...
...

I could easily then check collisions of different objects kept in a list:

List<Shape> list1 = new List();
list1.add(new Rectangle());
list1.add(new Circle());
list1.add(new Rectangle());
list1.add(new Ellipse());
for-each(a; list1) {
    for-each(b; list1) {
        checkCollision(a, b);
    }
}

The multi-method approach you're talking about looks semantically identical to the "traditional" approach, where "this" is an implicit parameter for every method call (python even requires the parameter to be explicit in the method declaration, but passes it implicitly in method invocations).

So what am I missing?

With multimethods, dispatch is based on the types of all of the arguments, not just on the type of the receiving object. See Multiple dispatch.

(The example given in the grandparent comment intended to show this happening with the checkCollision method, where dispatch to the appropriate definition of checkCollision occurs based on the second parameter as well as the first.)

In a nutshell, the basic idea of multi-methods is to unify overloading and dynamic dispatch into one concept, essentially by resolving overloading dynamically.

An even more general concept are multi-parameter type classes, as found in implementations of Haskell. They allow you to dispatch not only on arguments, but on any portion of a type signature, including the return type of a function. This is because resolution is decoupled from values/objects and does not require the presence of representatives, as is the case in OO.

In a nutshell, the basic idea of multi-methods is to unify overloading and dynamic dispatch into one concept, essentially by resolving overloading dynamically.

Indeed. See also the generalization of multi-methods into "predicate dispatching":

http://pag.csail.mit.edu/~mernst/pubs/dispatching-ecoop98-abstract.html

Suppose checkCollision (all forms) also took, say, a third argument that is *not* a part of the dispatch (e.g., the color to paint the intersection, if any, of the two shapes involved in the collision). Here's a syntax that might be more suggestive of what multiple dispatch does (i.e., it might be more helpful to the folks who are accustomed only to single-dispatch languages):

for-each(a; list1) {
    for-each(b; list1) {
        (a,b).checkCollision( color );
    }
}

To me, this makes it slightly clearer that the checkCollision call is being dispatched depending on the types of both a and b.

Surely, the consumer of a library object/method should not need to be aware of implementation details such as which arguments are involved in dispatch decisions? Suppose I later came up with an optimized implementation of checkCollision which specialized on the color White. Then all consumers of checkCollision would need to adjust their calls.

Dylan has multiple-dispatch OOP (with single-value specializations); it's worth looking at as an example of how it can work.

Yes, you're right. That syntax was intended to be a simple illustration, aimed for people used to object.method(args) syntax, that might show quickly, what multiple-dispatch OOP is about.

I take it "multi-methods" are very similar to "overloaded unbound static methods", with the critical distinction that the choice of overload is made at runtime, based on the actual types of the arguments, rather than at compile time based on their declared types.

Is that a fair capsule description?

Yes, the only real difference between C++'s operator overloading and Lisp/Dylan/Slate/etc's multimethods are the point at which they are bound. Though, for Common Lisp and Dylan, methods can be early bound by using optional type declarations.

Another language, Nice, uses a form of multimethods to make source code look better. I have to say, I think having multiple method/function declarations is a lot easier to read than a mess of if ... elseif ... else blocks, not to mention, easier to maintain.

I was under the impression that getting macros working really well from a usability+power standpoint was not an entirely solved problem. Are there really super great macro implementations? How does it blur into generalized multi-staged programming?

Do you know how much I appreciate you all of a sudden ?

I'm not sure I agree with points 8. and 10., but I like everything else. I would add the following points

11. Allow constructions to enforce protocols.For instance, instead of having two functions file_open and file_close, introduce a macro file ... in ..., automatically closing the file and cleaning-up at the end of the block.

12. The possibility of switching off the type system Although I'm an advocate of strong, memory-safe, type systems, I believe it may be useful to shut it down for teaching purposes.

13. Runtime errors with causality Add an assert-like mechanism giving the possibility to tag offending values. The debugger should then be able to trace how that value came to be.

14. Simple error messages (By interaction with the IDE) make sure that the compiler reports are easy to read. If necessary, "fold" the error messages so as to make it easy to understand what category of error message this is, then when unfolded, print the details, then when unfolded print comments on the error message, then when unfolded print additional advice, then when unfolded print additional information (e.g. where the offending variable has been declared, why the compiler believes that it has such type, etc.)...

15. Type-time static checking In the IDE, check whatever is possible without having to push a single button. Use word-processor-style "underlined in red" for syntax errors, "underlined in green" for type errors, etc. Print suggestions.

16. Built-in extendable static check system Make the type system scriptable, à la Uno, so as to allow the simple addition of custom static checkers.

8'. Near-transparent distribution Have distant thread creation be a one-line operation. Include Join-calculus-style (i.e. JoCaml, Polyphonic C#...) remote join-function calls.