So today I've tried opendylan.

Twice, actually. First time I tried its "IDE" (it even lacked syntax highlighting) on windows and it's failed to compile hello world because I have no MSVC or Pelles C installed and mingw is too mainstream to support, then I tried it on linux.

Guys, it's a total shit.

First, its syntax is more verbose than java, e.g.

define function main(name, arguments)
    format-out("Hello, world!\n");
    exit-application(0);
end function main;

I heard THEY call it "lisp with infix operators". Well, while escaping from LISP minimalistic syntax, they gone too far.

[b]`end function main`[/o]? WTF is that?

Second, make-dylan-app creates FOUR files for such little program. So much of boilerplate. WTF?

Third. `dylan-compiler -build my-lib.lid` builds app. Too long to type, but it's not even a point. Point is guess where it places executable. Not in current directory like all normal compilers do. But in `~/Open-Dylan/bin/my-lib`. Guess how much shit it spits on the screen.
http://pastebin.com/DQJMVjHu
That many.

Fourth. Guess how much time it takes to compile this hello world. 0.9 seconds. On my i7-970. g++ -O4 with std::cout does it in 0.5 seconds. D2 compiler in 0.25 seconds. Walter Bright is may waifu, I guess. Results are not surprising since it's calling `cc` under the hood.

TL;DR. It's so bad that I don't even want to check if its macros system is strong enough to define macros that will help to eliminate boilerplate from `end function main;`

-O4
That's some serious optimization you got going there.

So, what is this and why should I care? Especially if it's shit, /prog/ isn't supposed to hold your blog entries you know.

"lisp with infix operators"
What's the point of that if it's not homoiconic?

>>1
You cant have both macros and "define function end function"  crud.

What's the point if /prog/ is not homoerotic?

>>3
What's the point of that if it's not homoiconic?
Person, saying that Lisp with infix operators is not homoiconic is like claiming that you can't be gay unless you are completely naked.

The interesting parts of Dylan are gradual typing on multimethods and the possible optimizations.

>>7
and the possible optimizations.
which take 0.9 seconds to compile format-out("Hello, world!\n")

IHBT

>>8
are gradual typing on multimethods
The context is ``gradual typing on multimethods''.
and the possible optimizations.
This appears in the context of ``gradual typing on multimethods'', so:
and the possible optimizations that gradual typing enables on multimethods.

>>10
format-out could as well be a multimethod similar to << from sepples.

>>11
Even if it was, my argument would still be unrelated to compilation speed.

>>6
Just look at OP's code and you'll see that it's not close to homoiconic.
If you want a Lisp with infix operators, simply make a metacircular evaluator that takes every even list element (cadr, cadddr, ...) as an operator with the the result of the preceding procedure as the first parameter and the next cadr after the operator as the second parameter (so, cadr operator evaluates first, only then [code]cadddr[/code operator takes the result of that operation and the element after it as its parameter and evaluates before going on with the list).
But that's unnecessarily complicated and rather useless, prefix notation is easy to get used to and can be quite nice at times.

>>13
it's not about prefix syntax, it's about all the fuck parentheses

>>14
Then note the arity of every function and group expressions based on this.

>>15
I'd rather have group sex.

>>15

doesn't work for variable length argument functions, or when you pass in functions as arguments to functions and you don't know how many arguments they are supposed to accept. You could put parenthesis with these special cases though, and let the interpreter figure things like not = x * y + + 3 / 4 5 * * * 4 5 6 7