Slashdot Mirror

The site is slashdotted at the moment, so I can't read the article.

A good example of people writing complex but bug-free software under time pressure is the annual ICFP Programming Contest. This contest runs over three days, the tasks are complex enough that you usually need to write 2000 - 3000 lines of code to tackle them, and the very first thing the judges do is to throw corner-cases at the programs in an effort to find bugs. Any incorrect result or crash and you're out of the contest instantly. After that, the winner is generally the highest-performing of the correct programs.

Each year, up to 90% of the entries are eliminated in the first round due to bugs, usually including almost all the programs written in C and C++ and Java. Ocassionally, a C++ program will get through and may do well -- even win, as in 2003 when you didn't actually submit your program but ran it yourself (so it never saw data you didn't have a chance to fix it for). But most of the prize getters year after year seem to use one of three not-yet-mainstream languages:

- Dylan
- Haskell
- OCaml

You can argue about why, and about which of these three is the best, or which of them is more usable by mortals (I pick Dylan), but all of them are very expressive languages with uncluttered code (compared to C++ or Java), completely type-safe, produce fast compiled code, and use garbage collection.

I think new classes of applications will be built for these things. And they'll run a lot faster than my Apple ][ or 386 PC ever ran anything.
I'm just not sure I want to be the first one to order a million units of a new product.
Just becaause it's linux doesn't mean you have to go with XFree86 and GCC. Some of the good work Apple did on the Newton and eMate could be resurrected, especially now that Dylan http://www.gwydiondylan.org/downloading.phtml implementations are open-sourced.
I just need to get 1000 of my friends to sign up 1000 of their friends, and we'll be ready.

Odd, then, that NetBeans and Eclipse are still slower than a sedated elephant on my Athlon 64 3200+ with 512 MB RAM. My computer must be living in a time warp.

Or maybe the truth is that Java is "effectively sluggish, though not technically slow" because its runtime optimization techniques require such huge amounts of RAM.

Although I'm well aware of the limitations of the Great Computer Language Shootout as a tool for measuring a language's overall utility, it does tell the naked truth about performance. When I see an easy-to-use language whose design makes it easier to write reusable code than Java using somewhat less CPU time and typically FOUR TIMES less memory , it makes me suspect that well-intentioned Java apologists like you have never really attempted an objective evaluation of the performance compromises inherent in Java's design.

Odd, then, that NetBeans and Eclipse are still slower than a sedated elephant on my Athlon 64 3200+ with 512 MB RAM. My computer must be living in a time warp.

Or maybe the truth is that Java is "effectively sluggish, though not technically slow" because its runtime optimization techniques require such huge amounts of RAM.

Although I'm well aware of the limitations of the Great Computer Language Shootout as a tool for measuring a language's overall utility, it does tell the naked truth about performance. When I see an easy-to-use language whose design makes it easier to write reusable code than Java using somewhat less CPU time and typically FOUR TIMES less memory , it makes me suspect that well-intentioned Java apologists like you have never really attempted an objective evaluation of the performance compromises inherent in Java's design.

For those interested in exploring Dylan, the Gwydion Dylan group have recently released 'Open Dylan'. This was once a commercial Dylan development environment and has been open sourced. The Gwydion Dylan maintaners have been working on making it available. They also have the Gwydion Dylan open source compiler which makes for two very strong open source Dylan implementations: http://www.gwydiondylan.org/

Dylan

seemed to have many of the benefits of Lisp without the prefix notation - macros, CLOS-based object system, multi-methods, multiple returns, optional type declarations, named parameters (I think), etc...

Dylan was started by Apple Research Cambridge in the late 80s, but was laid to rest (at least for Apple) after Jobs came back and the NeXT infusion.

At least Functional Objects opened up their stack and is now being incorporated by the above URL guys.

Maybe if the Dylan community created a killer IDE with a really high-quality implementation, it might still take off...

Have you seen Functional Developer? It's a commercial windows IDE from Functional Objects, and it's recently been open sourced. From zesiger.com's blurb on FunDev:

Also known as FunDev, this is a popular, commercial Windows IDE for Dylan that has just recently been made free to the public. There is talk that it could be open-sourced soon (18 June 2004). It is still being actively developed by the same people who are working on the Gwydion Dylan compiler.

Looks like the blurb is a bit outdated since it's already been open sourced...but anyways, did you know about FunDev when you made a call for a "really high-quality" IDE from the Dylan community?

Of course, besides FunDev, there's Gwydion Dylan, a nice commandline compiler for unix/linux.

Maybe if the Dylan community created a killer IDE with a really high-quality implementation, it might still take off...

Have you seen Functional Developer? It's a commercial windows IDE from Functional Objects, and it's recently been open sourced. From zesiger.com's blurb on FunDev:

Also known as FunDev, this is a popular, commercial Windows IDE for Dylan that has just recently been made free to the public. There is talk that it could be open-sourced soon (18 June 2004). It is still being actively developed by the same people who are working on the Gwydion Dylan compiler.

Looks like the blurb is a bit outdated since it's already been open sourced...but anyways, did you know about FunDev when you made a call for a "really high-quality" IDE from the Dylan community?

Of course, besides FunDev, there's Gwydion Dylan, a nice commandline compiler for unix/linux.

Dylan seems like a possible alternative to C++. Here's some more Dylan resources for those who want to look into the language a little further.

I think the real problem is with people who can't be bothered to search the web for 5 minutes before opening their mouth to demonstrate their ignorance, because guess what? You know all those people who designed Common Lisp? Well, many of them went on to design a nice, clean infix Lisp, 10 years ago. Anyone who knows about Dylan and still complains about Lisp's syntax is just trolling.

The "dialect of Scheme" was not NewtonScript but the _intended_ language for the Newton, Dylan. The project did not deliver quickly enough, and NewtonScript replaced it.

NewtonScript is based on templates rather than the traditional class-based object protocol derived from Simula (the one model many C++/Java/C# programmers associate with "object orientation").

Practicing those alternative language make you feel very restricted when you come back to more mainstream languages. I really encourage you to look at Dylan. I never had the opportunity to use NewtonScript but I intend to find out someday.

Those too old for this competition or the ACM version should check out the ICFP programming contest. You can work from home, using any language you want, and you have three days to complete the task the give you (24 hours for the lightning division). Typically people work in small teams and use exotic stuff like Dylan, although last year's winning entry was in C++. If you win, you get a cash prize and the judges pronounce your implementation language "the programming tool of choice for discriminating hackers."

Dylan was created in the early 90s. By then other object oriented languages like C++, both Apple, Borland, and maybe even Microsoft at that point had their Object oriented versions of Pascal (Microsoft's was closer to Apple's Object Pascal. Borland made their object model compatible with C++) Also consider that the Gang of Four's book Design Patterns was out around that time. (There is a brief mention of Dylan in the book.)

What made Dylan stand out was an object model that was closer to CLOS, with generics and multiple dispatch. It also was a dynamic language that could compile into something as efficient as C. (between type narrowing that could give hints to the compiler, and implicit typing that could determine how a type was used, it could often optimize out most of the dynamic behavior into a simple subroutine call.) The developers of Dylan were also interested in making the language work well within a Hypercode IDE envionment, where the code was kept in a cross-referenced database.

If you are interested in hints of where Dylan was going, there is a free software project called Gwidion Dylan that has implemented a subset of the language and environment.

Take a look at Dylan.

Eh? Paren-counting only happens with dumb editors. Lisp *requires* a smart editor to use. In return, it gives you a lot of benefit (ease of editing without using mouse, *macros*). However, if you still think Lisp is really wonderful except for its syntax, try Dylan.

Looks like dylan.

You could complain about C all day, the problem is, it's the best thing we have right now.
Hardly.

One of the problem with modern languages is, you can't write an operating system in them.
Sure you can, with little more ASM code than is required for a C-based operating system. Heck, lots of OSs have been written in things like Lisp. Actually, C is a terrible language for writing operating systems. Because its not safe, you have to have an MMU to protect programs from each other. This sucks for performance. Not only do you have the hit of memory protection, but you have to have bounderies between userspace and kernelspace, and between programs. That's why it takes 600(!) clock cycles on my P4 to do something trivially simple like gettimeofday()! If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. See this SF project for an OS written in a safe language.

One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code.
I don't know what's the current fetish with VMs, but most of the really advanced languages (Lisp, ML) compile to well-optimized native code. Look at the recent comp.lang.lisp thread where they ported Almabench to CMUCL, and got within a few percent the performance of C.

Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable.
Common Lisp
Another Common Lisp
Ocaml
Scheme
Dylan
Another Dylan

We have lots of languages that are much more powerful than C (hell, they're much more powerful than Java/C#), safer than C, and very close in performance. It is merely a failure of programmers and the software industry that we have not been able to utilize them.

• Almost as powerful and expressive versatile as lisp
• Libraries are powerful and well documented
• Easy to create bindings to C/C++
• Deployment is easy
• Good cross-platform support
• Syntax is easy for uninitiated to decypher
• Large and growing "mindshare"

Lisp is really the gold standard of "expressive and versatile" but you just can't jump in and be productive in a day or two like you can in Python.

Perl looks pretty ugly to the uninitiated.

Ruby looks better in a lot of ways but it's not enough better to overcome Python's lead.

I wish I really Dylan was ready. It's a real shame that Gwydion Dylan hasn't made it to production quality yet. It's a classic example of the losing end of worse-is-better. The design gets almost everything "right" which of course makes the initial implementation too difficult.

If it is good enough to inspire fanatical loyalty in some, why hasn't it been good enough to win over the rest of the world?

This really doesn't bother me. Just about everything I do or like seems to be a tiny minority thing.

Apple computers have always been far more hackable (in sofware -- I'm a software guy, not a hardware guy) than the alternatives, but most people don't care, or mistakenly think they're "closed" or something. They're simply better for how I want to hack computers than any alternative (especially once you could get A/UX, or now OSX), but clearly 97% of the popupation doens't agree with me. No prob.

I ride motorcycles. I never owned a car until I was about 35 and had family reasons to. By the time I was 24 I gravitated from the Japanese ones to BMW motorcycles and have stuck with them ever since. They're simply *better*, based on what makes a motorcycle useful to me, but clearly 99% of the population doesn't agree with me. No prob.

I fly sailplanes. I can't imagine why everyone doesn't, but it really seems that it doesn't interest most people -- I've taken more than forty of my friends, relatives and workmates for flights, and so far only *two* of them have been interested enough to go solo themselves -- and maybe half a dozen of the others ask for repeat flights. Oh well, no prob, each to their own, and the sport will survive even with only the current 1 person in 4000 (here in NZ, fewer in the USA, more in Germany) doing it.

My favourite programming language is Dylan. I can't imagine why everyone doesn't use it, but they don't, so I'm stuck with using Dylan for fun and programming contests, while using C and C++ at work. No prob, there are enough of us using Dylan to protect our compiler from bitrot, port it to new platforms, and gradually enhance it to be even better.

Every one of the above things is very much a minority thing that attracts fanatically loyalty in some. It would be great if the rest of the world agreed with me, but in fact the world is so big, and communication and trade so easy, that you don't *have* to have everyone using something to allow it to survive and even prosper.

If it is good enough to inspire fanatical loyalty in some, why hasn't it been good enough to win over the rest of the world?

This really doesn't bother me. Just about everything I do or like seems to be a tiny minority thing.

Apple computers have always been far more hackable (in sofware -- I'm a software guy, not a hardware guy) than the alternatives, but most people don't care, or mistakenly think they're "closed" or something. They're simply better for how I want to hack computers than any alternative (especially once you could get A/UX, or now OSX), but clearly 97% of the popupation doens't agree with me. No prob.

I ride motorcycles. I never owned a car until I was about 35 and had family reasons to. By the time I was 24 I gravitated from the Japanese ones to BMW motorcycles and have stuck with them ever since. They're simply *better*, based on what makes a motorcycle useful to me, but clearly 99% of the population doesn't agree with me. No prob.

I fly sailplanes. I can't imagine why everyone doesn't, but it really seems that it doesn't interest most people -- I've taken more than forty of my friends, relatives and workmates for flights, and so far only *two* of them have been interested enough to go solo themselves -- and maybe half a dozen of the others ask for repeat flights. Oh well, no prob, each to their own, and the sport will survive even with only the current 1 person in 4000 (here in NZ, fewer in the USA, more in Germany) doing it.

My favourite programming language is Dylan. I can't imagine why everyone doesn't use it, but they don't, so I'm stuck with using Dylan for fun and programming contests, while using C and C++ at work. No prob, there are enough of us using Dylan to protect our compiler from bitrot, port it to new platforms, and gradually enhance it to be even better.

Every one of the above things is very much a minority thing that attracts fanatically loyalty in some. It would be great if the rest of the world agreed with me, but in fact the world is so big, and communication and trade so easy, that you don't *have* to have everyone using something to allow it to survive and even prosper.

I'm not talking about Python. Python is positioned as a scripting language, and hence doesn't have a powerful compilation infrastructure. Although, Pysco does some very cool dynamic optimizations for Python.

In contrast, there are many high-level languages like Common Lisp, Dylan, Scheme, ML, Ocaml, etc, that have very powerful native compilers. They do optimizations that C/C++ compilers simply cannot do, because of the low-level C memory model. Literally decades of research has gone into making these compilers, and they have optimizations that (while not quite magical) are very impressive.

Variously:

- There are type-inference optimizations that eliminate the overhead of dynamic dispatch.
- There are heap-analysis optimizations that stack-allocate objects whenever possible, to avoid heap allocation.
- There are analysis that avoid heap-allocating closures.
- There are analysis that eliminate type checking and array bounds checking.
- There are analysis that perform large-scale optimization of class heirarchies, to eliminate the over head of OOP.
- There are memory allocation analysis that reduce the overhead of garbage collection (region inference).
- They do method specialization, allowing the C++ template advantage of generic functions optimized for a given type, without actually having to deal with explicit type parameters.

Some useful pointers:

Apple Dylan Wiki
Lisp vs Java vs C/C++ performane
Bigloo Scheme Compiler
Gwydion Dylan compiler
CMU Common Lisp Compiler
UW Vortex Compiler
MLKit ML Compiler
Ocaml Compiler

Its only manual if you don't use something like APT, Yum, urpmi, Portage, etc. Most of the major distributions have these, its just a matter of getting their package repositories up to speed. Debian, for example (or Gentoo to a slightly lesser extent) has a huge package repository. Most everything that can be installed on Debian is either in the repository, or has a 3rd party repository available. Gwydion Dylan's new Debian repository is a great example of this. Just stick a URL into your sources.list (which can be done via the GUI in Synaptic) and instantly you have access to everything in that repository. Best of all, as new versions come out, apt will automatically update them!

I agree with you that installing RPMs manually is a pain. That's why nobody does it anymore!

The thing with new string libraries is that there's a lot of code out there that doesn't use them and which you need to use to get productive in C, and that there's not only strings, but also a lot of other kinds of arrays, vectors and buffers that need to be checked. Even if your own code is fine, a lot of third party code isn't, and will never be. And CPAN shows that it is entirely possible to implement a wide and useful range of libraries for a language different than C.

Its nice to see my two favorite languages take the top spots :) Its also pretty nifty that the Gwydion Dylan team got another prize. They got second place a couple of years ago too. Anyway, more people need to check out Dylan. Its a pretty nifty language. It was made by Apple in the early 1990's, by a committe containing a lot of important Lisp people. As a result, its kind of an object-oriented Lisp with a more traditional syntax. Its a very powerful language, but also very fast. It was designed to achieve 90% the performance of C. In practice, the current Gwydion compiler (designed by the same group at CMU that did CMUCL) achieves 50-90% given similar code.

Dylan is a wonderful, elegant, extensible language that really puts Java to shame. Usually when there's a programming language article on slashdot, people end up describing their dream language... and it usually what they describe matches Dylan quite well. But still it's very hard to attract new programmers to the language.

It's a great compiler, and a team using it earned second place in the 2001 ICFP Programming Contest. The compiler is still being improved, but in all honestly, there's just a few dedicated volunteers working on it.

I don't know how to explain it's lack of "success", except to note that few geeks are really geeky enough to stray away from the mainstream languages.

A mirror of the document is here.

And here is the master thesis of Tom Knight, describing the architecture of the Lisp Machine. If you want to see one in action, visit me on the Chaos Communication Camp.

One online Symbolics Lisp Machine museum is here.

And yes, UNIX royally sucks. It plays in the same suckage leage as Windows, of course, but still it sucks. It's a clone of technologies of the early 70ies, and a bad one.

A mirror of the document is here.

And here is the master thesis of Tom Knight, describing the architecture of the Lisp Machine. If you want to see one in action, visit me on the Chaos Communication Camp.

One online Symbolics Lisp Machine museum is here.

And yes, UNIX royally sucks. It plays in the same suckage leage as Windows, of course, but still it sucks. It's a clone of technologies of the early 70ies, and a bad one.

Both the free and commercial Dylan compilers produce code that reaches C/C++ speeds.

Dylan is OO from the ground up, and supports a variety of programming styles, including fp, inperative and, of course, oo.

Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance.

In other words, it's a small concurrent functional programming language developed by Ericsson after their experiments with Lisp and Prolog.

Although, you will not love it if have already poisoned by OO "snake oil"

If it's a case then try Dylan

Interesting to note the paragraph under the heading 'The Downside of Dylan'.

(Disclaimer: I'm not an expert in prototype-based languages, but I'm fairly confident that the description below is quite accurate. Corrections are, therefore, very welcome.)

Languages such as this are called prototype-based languages, and are generally seen as the successor to object-oriented programming. However, no prototype-based language has, to my knowledge, actually gone anywhere (the one that got closest was NewtonScript, which would have made it if it weren't for the fact that the only place to use it was on the Apple Newton), so it's nice to see that at least one actually made some progress towards general acceptance.

For those unfamiliar with the concept of prototype-based programming languages, Bob (and all prototype-based languages, for that matter) are by their very nature single-inheritence. The general idea is to eliminate the whole idea of classes, and instead treat everything as an already existing object. You them modify those objects as necessary, and, if it's an object which is handy, you just make lots of copies of it. I find it much clearer to use the word "copy" instead of "initiate," as you did for this reason. For example, define anObject = new Foo() makes a new copy of the already existing Foo object, that will have all of the same values, etc. as Foo. You can then modify that copy by adding new values as necessary.

The reason I make this distinction is that one of the powerful things you can do in prototype-based languages is give an instance of a class a new function. For an example of when you'd want to do this, let's say you have a Canvas object in a GUI. Now, you, at some point, are going to need a screen, and the screen is going to need some variables and methods you don't need for a standard Canvas (for example, Screen.refreshRate or Screen.setColorDepth()). The normal way to do this in a regular OO language would probably be to declare a subclass of Canvas that had the extra functionality, and then to make a single instance of it, probably called theScreen. This is awkward, however, because, 99.9% of the time, you really only want one screen object, so making a subclass just for a single instance seems odd. In a prototype-based language, however, you'd simply "copy" a new instance of a Canvas (called theScreen) and add your extra methods and functionality specifically to that object. Ultimately decide that you really do need multiple screens? No problem! Probably you'll want to add a monitorNumber attribute directly to the already existing screen object, and then make a copy of that. Similar functionality is also present in Dylan, and, by extension, probably LISP's CLOS, although I'm honestly just not familiar enough to know.

Actually, I'd argue that the genericity of lisp's syntax is as much a hindrance as it is a help, emacs parenthesis-matching aside.

The above quoted lisp sexp could mean almost anything or nothing, depending on the context in which that sexp occurs. (Is it data? Is it code? In what evaluation context will it be processed?). Java, C, and most other languages at least give you more distinct contextual tokens to guide you in your understanding.

I like Lisp a lot, but I tend to agree with this point of view. I'm simply more comfortable infix-syntax for simple arithmetic. Prefix syntax is great for function calls -- and I don't really care whether the parens go around the whole thing (Lisp), after the function name and aroudn the arguments (most languages), or aren't there at all (ML/Haskell/Logo). Hell, I even cope happily with postfix function calls (Postscript/Forth/GML).

But when it comes to control structures I really, really prefer a keyword-rich syntax and explicit markers saying just what it is that you've just come to the end of. e.g. if/then/elseif/fi or any of a number of equally reasonable alternatives.

This is why I think that Dylan is currently the best language out there. It does pretty much everything that Common Lisp does, but in a more familiar syntax and with a lot of CLs historical cruft cleaned up. Dylan was designed by a bunch of Common Lisp gurus with the intention of designing the replacement for CL. And I think they suceeded technically.

Dylan currently has two implementations, one open source batch compiler for Unixy systems and one commercial IDE for Windows (with a free personal edition). Both systems compile to fast machine code and can compete with C in all but the most hardcore applications -- certainly far far better than Java or Perl or Python.

Functional Developer is a quite mature system with nice IDE and debugger and lots of libraries.

Gwydion Dylan is a bit less polished, but it's still good enough that a team using it managed 2nd place this year in this year's ICFP 72 hour programming contest.

All previous winners at this contest have been written in either C or else one of the Hindley-Milner statically typed languages (SML/OCaml/Haskell), all of which have very fast execution speeds with a good compiler.

You don't necessarily have to have the best possible langauge to win at ICFP, but you must have no major weaknesses -- you have to have a language and compiler that lets you develop and debug complex code in a very short time, and the end result must run fast. Much like in the real work :-)

Common Lisp and Scheme have never yet won a prize here (though I believe Common Lisp could), and it seems that the large number of Java and Perl and Python entries produced every year simply don't run fast enough to do well. On the other hand, the vast majority of C and C++ programs get eliminated because of bugs (occasionally one gets through!).

Having said all that, the one-line summary is this: if you like the idea of Common Lisp but just can't stand all those parens, take a close look at Dylan instead.

It's true that perl is getting more and more of the capabilities of Lisp (as has Python) recently, but while it is becomeing *possible* to do many things, it's rather ugly. Perl doesn't even have a decent syntax for naming the arguments of a function, and Lisp programming is *full* of functions.

Perl datastructures (arrays and hashes) also aren't very well suited to implementing lists, which are likely to turn up in your tasks. Of course you r can *do* it, but it's likely to be more ugly in than in a proper Lisp.

But you before you despair in a maze of twisty little parens, you should realise that there is more than one language in the Lisp family. Common Lisp and Scheme do have lots of parens, but take a look at Dylan. It's a true member of the Lisp family, but looks and feels like a conventional langauge such as C or Pascal.

The link above is to an Open Source command-line compiler for Dylan which workes primarily on Un*x but also has ports to Mac and Windows.

If you happen to be using Windows then also check out Functional Developer, a compiler with a nice IDE and debugger and so forth. It's commercial but the basic edition (whcih is all you'll need) is free.

Dylan is quick to develop in and the programs run fast. A team using Dylan got second place in the recent ICFP Programming Contest.

I'm really happy with my C1VN Picturebook. It runs FreeBSD 5.0-CURRENT, which includes support for LongRun power management.

It's nice being able to "whip out" a 1kg machine and start doing serious software development (mostly on Gwydion Dylan) whenever I have a spare moment.

More about the Dylan Hackers' entry; they use (and maintain) Gwydion Dylan.

Functional Objects, Inc. sells Functional Developer, their Dylan implementation, for Windows and soon for Linux.

I think he meant that you're blaming everything on the programmer, while ignoring potential problems with the tool (in this case, the C++ language).

C++ is complex and cumbersome, and yes, a great deal of time must be invested in order to learn it. I can't help but wonder if that time would be better spent in more productive languages (Lisp, Dylan, Smalltalk, etc).

Sigh...if only Gwydion Dylan were more advanced, we'd have all the benefits of C++ (OO, speed, small executable size), without all the problems (the language itself) on Unix.

~~~~~~~~~
auntfloyd

While there's no denying that C++ is a steaming heap of offal, ST is not the last word in OO languages.

I'd rate Self, Dylan, Cecil, and Common Lisp as OO languages with better designs than Smalltalk.

This is not to say ST is bad; in fact it's wicked cool. It's just not the last word in OO.

It's like Lisp, but with a more Pascal-like syntax! Easy to use, and powerful: that's what I want in a language!

See Gwydion Dylan for an open source version for Linux!

http://www.gwydiondylan.org/

And where are the breakthru languages?

You just aren't looking.

• Cecil

• Dylan

• Haskell

• Objective CAML

• Sather

• Self

Well anyone looking for speed in a dynamic, object-oriented language might want to check out the Dylan programming language. It is considerably more abstract than Java (Dylan programs are significantly shorter), yet Dylan code is probably faster in most cases.

There are two main implementatin of Dylan:

an open-source implementation for Unix-compatible systems: http://www.gwydiondylan.org/


and a free version of Harlequin's commercial implementation for Win32: http://www.harlequin.com/products/ads/ dylan/

Is multiple dispatch (mentioned by a Dylan guy) a sort of SIMD thing?

No. What it does is use the types of all arguments to a function to determine which version of the function to call, and not just one.

To illustrate with an example: In single-dispatch languages such as Java and C++ (to name the two most relevant to this thread), method calls look like this: obj.foo(arg1, arg2, arg3), where obj is an instance of some class. The version of method foo() that gets invoked depends on what class obj belongs to.

In Dylan, method calls can use the above syntax, but they're really treated as if they use the alternate form foo(obj, arg1, arg2, arg3). Here, nothing is special in particular about the first argument, rather, the types of all arguments to foo() are used to determine which version to run.

What this means is that you can specialize a function based on more than a single argument. In single dispatch languages, you can only specialize functions based on a single type tree. That limitation doesn't apply to multiple dispatch, where function calls are specified by the types of all arguments. In fact, Dylan's singleton types allow you to even specialize functions on particular instances of a type!

The ideal is that Dylan compilers are able to determine the real types of all arguments at compile-time, which would make multiple dispatch calls no more expensive at runtime than a static dispatch call in C. If the types can't be accurately determined by the compiler, then it's usually the same as a dynamic dispatch call in a single dispatch language such as Smalltalk or Objective-C. Of course, this makes Dylan compilers rather difficult to write.

For more information on Dylan, I recommend checking out Gwydion Dylan, a free software project to create working Dylan tools.

Colin

If you're interested in a language as fast as C++, but as nice as Python or perl, check out Dylan. A Gtk+ wrapper is under development. Gwydion Dylan is even written in itself, you can't say this about Tcl, perl or Python.

Garbage collection is a tremendous aid to writing good code.

Actually, last I checked, Perl's memory management was jut simple refcounting, not even smart enough to avoid leaking circular garbage.

Yes, current implementation of Perl and Python have the same problem. But naively implemented GC should not be used as an argument against GC.

The open source Gwydion Dylan does a little better. It uses the the Hans Boehm collector.

A well-implemented GC outperforms manual deallocation. (Programs utilizing GC will have more memory requirements, but memory is cheap these days).

Anyone interested in advanced programming languages in invited to join our
volunteer effort: Gwydion Dylan, an open-source implementation of the Dylan
programming for unix-compatible systems.

Gwydion Dylan's chief componenent is a highly optimizing Dylan-to-C compiler. The
Hans Boehm conservative garbage collector for C is utilized for memory
management.

http://gwydiondylan.org

(Harlequin Dylan, an commercial implementation of Dylan for Windows uses more
advanced GC techniques).

Dylan is an dynamic, object oriented language, which can be efficiently compiled.
Dylan is much more abstract than a language such as Java, but can compete
speed-wise with more static languages. The Dylan language features a wide-range
of productivity-enhancing language features, such as hygenic macros, keyword
arguments, multi-methods, advanced exception handling capabilities (and a lot of
other stuff which slips my mind at the moment.)

Anyone interested in working on Dylan language bindings for GTK+ is encouraged to join us:

http://gwydiondylan.org/gui.phtml

With a little work, we should have a great interface for programming GTK+ applications.

(Dylan is an advanced, object-oriented language that can be very efficiently compiled. Gwydion Dylan is an open-source, optimizing Dylan compiler for unix systems.)

This is a little different than a front-end, but there are a lot of (insert-your-favorite-language-here)-to-C compilers out there. There's probably at least one of these for Java.

Gwydion Dylan, a free open-source Dylan compiler for unix systems, has a Dylan-to-C compiler which generates surprisingly speedy C code.

Eiffel is undoubtedly a vast improvement over C++, but writing programs in it is arduous if you ask me. It seems like you have specify just about *everything*.

I think Dylan is a much productive language for most things.
Gwydion Dylan
Dylan descended from Lisp, but don't let that scare you away. It's got infix syntax, and it is fully OO from the ground up (much more so than Java). Just about everything is a first class object... methods... 'primitive' data types, even classes are objects.