Lambda the Ultimate

Parrot is vaporware and probably not relevant anymore. The CLR and the JVM are similar I suppose, with the CLR having some more features to support languages like C++. The only thing I know about the DLR is that it's a common layer for dynamic languages that ease interop with the CLR.

This is kind of odd, I know, but I just downloaded this vaporware from http://www.parrotcode.org/source.html

Is it a ghost? Have I been hacked?

Oh wait, I know what it is.... it's called "fallacy"

Come back to me to when you've got Python, Perl, or Ruby running on it that can be used in a production environment. Random source code doesn't make it non-vapor.

The woes of Parrot are well known

With all due respect to Dan, his views on Parrot have little to do with technology. He has had no involvement with Parrot for two years and several releases. (To my knowledge, there may have been as much as $10,000 of funded Parrot work since then as well.)

I apologize if this is off topic, but it surprises me that Parrot doesn't get more attention from LtU. A completely free virtual machine built explicitly for dynamic and little languages, intended for production use and transparent interoperability, and attempting to offer better compiler tools through features such as attribute grammars seems very much in line with the practical side of PLT to me.

You mean, like NekoVM ? Except maybe that :

• NekoVM has already reached 1.0 (latest version is 1.5.3)
• NekoVM have 3 productions language available : Neko, NekoML and haXe
• NekoVM is lightweight (dll < 100KB)

It may not be as general as the CLR or JVM but the AVM2 (ActionScript VM) may be worth considering.

It is a JIT VM that drives the Flash Player (v9+), the upcoming Apollo runtime and, eventually, Firefox (via the Tamarin open source donation to Mozilla).

I'm currently attempting to translate JVM bytecode to run on it and considering doing the same for YHC.

AVM2 will probably become the most widely deployed VM, so it is an interesting target platform.

The new AVM2 JIT engine is interesting. As an aside, the guy that is doing Vista Smalltalk and Vista Lisp that originally was targeted at what now has become Silverlight has also targeted the Flash runtime.

AVM2 will probably become the most widely deployed VM, so it is an interesting target platform.

If you look at all Flash versions in totality, it is the most widely deployed desktop software in the world.

...for dynamic language implementors, since you can not generate AVM2 code on the fly (it *might* be possible, but the current situation requires gruesome hacks such as server-side round-tripping)

You can post on his blog and tell him to stop wasting his time.

Yes, I am familiar with Vista Smalltalk... For your information, it's an interpreter, not a compiler. Interpreters obviously don't generate code. No mainstream dynamic language is implemented as an interpreter (even Ruby has YARV now, a bytecode compiler).

You might have some success emulating a bytecode interpreter on the AVM2, though. The performance will not be good, mostly due to memory management (boxing, frame GC) issues.

If the AVM2 was as good as a modern Java VM, a SISC-like approach would work. But it's not quite there yet.

Silverlight development requires knowing HTML, XML, XAML, Javascript, C#/IronPython/Ruby, running the applications inside browsers (although the plugin promises no platform dependencies).

Uhmm, no, and that's like saying you have to know every language that exists.

Furthermore, most of the graphics programming is done with XML.

Actually, with the CLR you could do your graphics procedurally. Besides, you use a tool to do graphics. Most people won't be handcoding XAML.

What the world needs is a single programming language that has functional and object oriented abilities, a good audio-visual sub-system, can optionally run within a browser, has an optional static type system, can offer abstractions over the database and the network, allows for declarative programming etc.

No, maybe you need a single programming language, but "the world" doesn't need a single programming language.

And before someone says 'use different tools for different tasks, no single tool can be good for everything', I would like to point out that, in programming, there are no truly different tasks: web page programming is gui programming (layout of graphical elements and event callbacks), xml-style declarative programs can be used for myriads of other tasks (from declaration of database schemas to laying out parsers ala Spirit to forming SQL queries), etc.

Completely ridiculous.

Completely ridiculous.

What part of that statement is completely ridiculous?

What part of that statement is completely ridiculous?

He's just reiterating his main point that all "we" need is one language.

"In programming, there are no truly different tasks" seems pretty suspect to me, to say the least. For some reason, my word processor makes a terrible accounting program.

Your word processor and accounting program is not programming.

They are programs, which represent "truly different [programming] tasks". If they didn't, it wouldn't be necessary to write two separate programs.

They are different programs, both built out of the same programming tools.

"I am not so sure all tasks could be done by tool X. Tool Xs have practical limits, i.e. whatever the tool X designer has thought of to put in. Once you want to do something not convered by the tool X, then the problems start."

Uhmm, no, and that's like saying you have to know every language that exists.

I am not sure I can program UIs with C#. From the documentation I have seen, the UI requires XAML, since Microsoft heavily promotes it even for Vista apps.

Even if it is possible to do the same fancy UIs with C# as with XAML, it would be pointless if the task that takes 10 lines in XAML requires 100 C# lines. And Microsoft is guilty of that (complicating one tool in favor of another) in plenty of cases.

Actually, with the CLR you could do your graphics procedurally. Besides, you use a tool to do graphics. Most people won't be handcoding XAML.

I am not so sure all tasks could be done visually. UI designers have practical limits, i.e. whatever the UI designer has thought of to put in. Once you want to do something not convered by the UI designer, then the problems start.

No, maybe you need a single programming language, but "the world" doesn't need a single programming language.

Perhaps, but am I the only one who sees each new tool being 99% similar to the previous ones? I am tired of trying to learn "new" things that do exactly the same things as the previous ones.

Completely ridiculous

Could you give a reason why? Especially in the context of Silverlight, which is what countless other frameworks/environments/libraries like Applets/Flash/Flex/Ajax+JS/DHTML/Forms/[put your own framework here] do.

I am not sure I can program UIs with C#. From the documentation I have seen, the UI requires XAML, since Microsoft heavily promotes it even for Vista apps.

No, the XAML elements are .NET classes. You can use C#, VB, IronPython, IronRuby, Boo, F#, Nemerle, etc...

Even if it is possible to do the same fancy UIs with C# as with XAML, it would be pointless if the task that takes 10 lines in XAML requires 100 C# lines. And Microsoft is guilty of that (complicating one tool in favor of another) in plenty of cases.

You don't have to use C# and you will be using a tool to do the GUI and vector graphics.

I am not so sure all tasks could be done visually. UI designers have practical limits, i.e. whatever the UI designer has thought of to put in. Once you want to do something not convered by the UI designer, then the problems start.

The UI is done visually, not the program logic, just like has been done for how many years now?

Perhaps, but am I the only one who sees each new tool being 99% similar to the previous ones? I am tired of trying to learn "new" things that do exactly the same things as the previous ones.

What your needs are and what the "world's" programming needs are two different stories.

Could you give a reason why? Especially in the context of Silverlight, which is what countless other frameworks/environments/libraries like Applets/Flash/Flex/Ajax+JS/DHTML/Forms/[put your own framework here] do.

As I stated before, your original paragraph was a reiteration of "the world" needs a single programming language. There's not "countless others". There's HTML, CSS, and Javascript (AJAX), and there's Flash (which is apples and oranges). Now there's Silverlight.

No, the XAML elements are .NET classes. You can use C#, VB, IronPython, IronRuby, Boo, F#, Nemerle, etc...

XAML elements may be .NET classes, but how easy is it to program with XAML? that's the big problem: XAML is good for what it has been programmed for, but If I need something not thought by XAML developers, I need to go down C#/IronPython/whatever...which means I have two know 2 things, instead of one.

In other words, XAML is not the actual programming language, it is simply a skin for a library made with a programming language.

You don't have to use C# and you will be using a tool to do the GUI and vector graphics.

The UI is done visually, not the program logic, just like has been done for how many years now?

It sounds like you never programmed graphical applications. There has never been a case where visual editors could cover 100% of UI requirements. There is always need for programming.

What your needs are and what the "world's" programming needs are two different stories.

Then perhaps I am the only one who sees the same things being repeated over and over in a different form.

As I stated before, your original paragraph was a reiteration of "the world" needs a single programming language. There's not "countless others". There's HTML, CSS, and Javascript (AJAX), and there's Flash (which is apples and oranges). Now there's Silverlight.

No, it's not apples and oranges. HTML/CSS, Javascript/Ajax and Flash are GUI building tools. They are the same thing, implemented differently.

XAML elements may be .NET classes, but how easy is it to program with XAML? that's the big problem: XAML is good for what it has been programmed for, but If I need something not thought by XAML developers, I need to go down C#/IronPython/whatever...which means I have two know 2 things, instead of one.

In other words, XAML is not the actual programming language, it is simply a skin for a library made with a programming language.

I thought we already went over this, but XAML will typically be the output of tool that does vector graphics. You don't actually "program" in XAML.

It sounds like you never programmed graphical applications. There has never been a case where visual editors could cover 100% of UI requirements. There is always need for programming.

It sounds like you're not reading what I'm writing. You can do your UI in XAML or a real language.

Then perhaps I am the only one who sees the same things being repeated over and over in a different form.

Or perhaps you're the only one that sees the need for one programming language to rule them all. But use just one programming language if that's what you want.

No, it's not apples and oranges. HTML/CSS, Javascript/Ajax and Flash are GUI building tools. They are the same thing, implemented differently.

All cars are the same thing, implemented differently. All we need is one car.

Come on Achilleas, this isn't so hard to understand.

There are so many dimensions along which to evaluate things. I read into Achilleas's comments "I want to extract the central goodness of all these different languages into some core. With libraries." I read into Dave's comments "I value the fact that each language is trying to fit a particular ecological niche."

Just because a language fits a niche doesn't mean it is the only or best way to fit that niche. All cars have problems.

Just because a language is something new or different or seems to just be a rehash of something that happened in the 60's doesn't mean it didn't contribute something - perhaps only something socially, rather than really technically.

My mental summary so far is that creating a truly good multi-paradigm language is nigh impossible?

I've come to the conclusion that what Achilleas really wants is Lisp - as in "how can we integrate the declarativeness of XML within a language".

I read into Dave's comments "I value the fact that each language is trying to fit a particular ecological niche."

No, what I was really saying is that it's pointless to cram everything in a single language. Common Lisp users might disagree, but it goes beyond that into the realm of personal preferences of what people feel comfortable with.

Some PLT blogs make it sound like their Super Macro Powers might go a good distance in that direction? Dunno.

It's quite possible to do a programming language which fits most niches.

Take C; it is used for low-level stuff. How can we change it so it covers more niches?

We can add optional garbage collection, so as that we don't have to worry about memory management; gc also enables truly complex data models.

We can add first-class functions, so as that we can do functional programming.

We already have the const keyword, so we can do pure functional programming, if we want.

We add first-class tuples, so we can declare trees in literal form. This allows us to declare html/xml/other tree data structures, within the code.

We can add a multi-dispatch mechanism, based on the input types, so we get object-oriented programming for free, while solving the expression problem as well.

We remove header files and add symbol files which are imported.

We make a binary bytecode protocol with a standard ABI (nowadays all bytes are 8 bits, isn't it?).

We add strong types, templates/generics and type inference.

We define the bytecode to output computation trees, where computational dependencies are visible; then a future virtual machine can extract parallelism by executing independent computations in parallel, possibly in multicore systems.

We add imports with URLs; we let the vm manage library interdependencies.

We make a virtual machine that downloads modules lazily, using the URL information of the imports.

We add reflection/retrospection, so as that we can have serialization and other useful functionalities.

We add a macro system which can take a specific piece of code and translate it (at compile time!) to another piece of code.

We make the compiler a library. We use this library to implement an 'evaluate' function so as that programs can be infinitely extended by themselves.

Isn't the above possible? of course it is.

Wouldn't it cover most programming needs? it would.

That's what I want. I know such a thing would make my and my colleagues' lifes easier. Programming would not be a constant battle with the tools, but an enjoyable experience.

So you want Perl 6? But seriously, I don't know who "we" is, but have at it.

I'm (didactically) wondering:

a) what comes closest currently?

b) is it possible? would all those things end up collapsing under their own weight? would the semantics be too hard to get really working? using a different language per-task means you can get something that is vaguely honed for that task, no?

I do not see any reason why is it not possible. Most languages cover most of the functionalities anyway; is a matter of putting the functionalities together.

Perhaps but note that for example gc and manual memory management are quite incompatible: if you want your language to be useful in a space where gc is not acceptable, then you need to have *two* standard libraries..

Also the usability of the gc in some niche will heavily depends on the qualities of the gc: if it moves memory it'll be unusable with C libraries, if it doesn't move memory the memory usage is likely to be high, etc.

For the const keyword, one need to be careful: C++ const are not really constant..

[[ Wouldn't it cover most programming needs? it would. ]]
VM based runtime tend to have slow startup: they're not necessarily ideal for client application..

Perhaps but note that for example gc and manual memory management are quite incompatible: if you want your language to be useful in a space where gc is not acceptable, then you need to have *two* standard libraries..

Not really. If the type system allows for GCd and non GCd types, then generics/templates can be used to provide one standard library.

Also the usability of the gc in some niche will heavily depends on the qualities of the gc: if it moves memory it'll be unusable with C libraries, if it doesn't move memory the memory usage is likely to be high, etc.

That's why GC should be optional.

For the const keyword, one need to be careful: C++ const are not really constant..

You are correct. But I obviously wasn't talking about C++.

VM based runtime tend to have slow startup: they're not necessarily ideal for client application..

Not really. It depends on the design.

Perhaps but note that for example gc and manual memory management are quite incompatible: if you want your language to be useful in a space where gc is not acceptable, then you need to have *two* standard libraries..

Have you looked at SmartEiffel? The implementation uses optional GC (default on) but only one library, which was entirely written with the absense of GC in mind. To turn of the GC, wouldn't you just ignore implicit memory deallocation instructions? Then, only library writters would be affected.. and they'd still only have to write one lib, just meant for GC off.

I would be surprised if a library API designed for manual memory management would not look significantly different (read: more complicated, less flexible) from one written with GC in mind.

Edit: In other words, I am convinced that the one-library approach does not give you the best of both worlds.

Could you please elaborate on your quote that the one library approach does not give you the best of both worlds?

In the manual memory management languages I've used libraries commonly expect you to pass them a chunk of memory that they will then initialise. Of course in a GC'ed world this is not the usual way of doing things. This is a simple example of where they clash.

Initialization is no different from assignment. In a non-GCd environment, the contents of a new memory block may be uninitialized, but in a GCd environment, the contents would have to be initialized to a meaningful value (if the block contains pointers, that is), or the GCd block should be added to the collector (along with the rest of the graph) after initialization.

You have to worry about ownership, and that generally requires all kinds of kludges in the interface. In particular, you might need to compromise abstraction and high-levelness to allow clients to control deallocation according to their needs.

Not all libraries of a language needs to be non-GCd. For those libraries that the developer feels direct memory control is required, a little bit extra effort in the API could solve the problem.

Note, that this choice has an impact on the 'style' of the standard library: D's standard library use a COW style by default: if you do an operation on an object and that it turns out to be a NOP (for example a tolowercase on a lowercase string) then the function return the same object, otherwise it'll allocate a new object and do the copy and return the new object.

Of course you can't do such kind of thing with manual allocation in mind (well you could, but users would complain that the API is hard to use)..

I'm surprised that Eiffel used a library where the GC is optionnal as Bertrand Meyer made a quite strong point in favor of the GC in OOSC where he says that you can't have an object oriented design without a GC..

You may be interested in felix (we're in between websites at the moment, but the mailing lists are very active). A lot of what we're trying to do is along your lines of what you want:

Take C; it is used for low-level stuff. How can we change it so it covers more niches?

Felix generates c++ code, and have a very extensive binding language to c because of this. This allows for extremely simple binding to external libraries. We're also considering a llvm backend as well, but no work has been done for that.

We can add optional garbage collection, so as that we don't have to worry about memory management; gc also enables truly complex data models.

We're currently do garbage collection for pure felix data types, but c++ bound data needs manual collection. More work is needed here though.

We can add first-class functions, so as that we can do functional programming.

We already have the const keyword, so we can do pure functional programming, if we want.

We add first-class tuples, so we can declare trees in literal form. This allows us to declare html/xml/other tree data structures, within the code.

We remove header files and add symbol files which are imported.

We've got all of this. We're working on adding monads for even more pure functional programming support.

We can add a multi-dispatch mechanism, based on the input types, so we get object-oriented programming for free, while solving the expression problem as well.

We add strong types, templates/generics and type inference.

We currently have polymorphic overloaded functions and typeclasses available for constrained polymorphism. We haven't figured out how we want to do classes yet. Felix has type deduction instead of inference. This means that you have to declare the types at function boundaries, but inside functions you don't need to specify types unless felix's type checker needs assistance resolving an overload.

We add imports with URLs; we let the vm manage library interdependencies.

We make a virtual machine that downloads modules lazily, using the URL information of the imports.

We have a nice pkg-config like system for building the code, but we don't do URL loading. I'll add it to our bug database.

We add a macro system which can take a specific piece of code and translate it (at compile time!) to another piece of code.

We have a decent macro system now, and we're in the process of experimenting with a the GLR parser dypgen, which would let us do much more extensive user-level syntax manipulation.

Ok, let's go over it one more time.

I thought we already went over this, but XAML will typically be the output of tool that does vector graphics. You don't actually "program" in XAML.

UI design tools have limitations. There was always a situation where the GUI designer did not offer what we wanted, and we had to code.

So, XAML is going to be good, unless you need something not covered by the UI tool. So, in that case, which is pretty usual, the programmer would have to 'switch to manual mode', which makes XAML irrelevant.

It sounds like you're not reading what I'm writing. You can do your UI in XAML or a real language.

I am sorry, but it seems the reverse. Let me rephrase it for you, in order to understand it:

Suppose you want to do a GUI. You have 3 options:

1) use XAML. It takes 100 lines.

2) write the code in a real language. It takes 1000 lines, but you can do things not possible with XAML.

3) write the code in a XAML-like (i.e. declarative) programming language. It takes 110 lines, but you can do things not possible with XAML.

I would take #3 anytime.

Or perhaps you're the only one that sees the need for one programming language to rule them all. But use just one programming language if that's what you want.

I am suprised that you seem not to understand that using only one programming language increases productivity.

All cars are the same thing, implemented differently. All we need is one car.

Cars is a totally different domain, so your analogy is flawed. You buy a car based on the image you want to project to others. Buying a car is more about emotions than anything else. That's why many different models exist.

On the other hand, programming is all the same: for example, an XML loop is a C loop is a Haskell loop is a Javascript loop. In programming, differences between languages are superficial.

UI design tools have limitations. There was always a situation where the GUI designer did not offer what we wanted, and we had to code.

UI design tools have limitations, but the code doesn't. This isn't an either/or situation. Anything that you can do in XAML you can do in C#, VB, Javascript, IronPython, IronRuby, Boo, F#, etc..

I am sorry, but it seems the reverse. Let me rephrase it for you, in order to understand it:

Suppose you want to do a GUI. You have 3 options:

1) use XAML. It takes 100 lines.

2) write the code in a real language. It takes 1000 lines, but you can do things not possible with XAML.

3) write the code in a XAML-like (i.e. declarative) programming language. It takes 110 lines, but you can do things not possible with XAML.

I would take #3 anytime.

False trichotomy. See above.

I am suprised that you seem not to understand that using only one programming language increases productivity.

I'm surprised that you seem not to understand that not everybody wants the kitchen sink.

Cars is a totally different domain, so your analogy is flawed. You buy a car based on the image you want to project to others.....

I'll stop right there since you made a wrong assumption.

UI design tools have limitations, but the code doesn't. This isn't an either/or situation. Anything that you can do in XAML you can do in C#, VB, Javascript, IronPython, IronRuby, Boo, F#, etc..

False trichotomy. See above.

Nope. You don't get it, do you? ok, let me say it again, in different wording: It takes too much code to override the limitations of the UI designers, unless the code is in declarative form.

I'm surprised that you seem not to understand that not everybody wants the kitchen sink.

I think that not everybody wants the spaghetti kitchen sink. If it is a well formed kitchen sink, I would take it over 5 or 10 different languages used together (or trying to use together).

It takes too much code to override the limitations of the UI designers, unless the code is in declarative form.

Arbitrary, personal opinions on "too much code" doesn't mean much. But in any case, I don't know how "declarative code" solves your problem of wanting one language.

I think that not everybody wants the spaghetti kitchen sink. If it is a well formed kitchen sink, I would take it over 5 or 10 different languages used together (or trying to use together).

We're actually probably in agreement more than you think on this issue, but you get the context all wrong. For example, I'm not a big fan of XML. If I was to work on a new Java web project, and all things being equal, I would rather use something like Wicket, Echo2, or GWT for the presentation layer and db40 for the database layer.

But I don't expect to user SuperJava++ to work on a device driver.

Suppose that you want to write a login window with the following elements:

1. a username textbox
2. a password textbox
3. a login button
4. a cancel button

The XML code could look something like this:

<window name="logindlg" title="login" layout="grid" layoutparams="2x2">
    <label text="username:" alignment="right"/>
    <textbox name="username"/>
    <label text="password:" alignment="right"/>
    <textbox name="password" echo="*"/>
    <button text="login" click="login"/>
    <button text="cancel" click="logindlg.cancel"/>
</window>

The Java-ish code would look something like this:

    Window logindlg = new Window();
    logindlg.setTitle("login");
    logindlg.setLayout(new GridLayout(2, 2));
    
    Label label1 = new Label();
    label1.setText("username:");
    label1.setAlignment(Label.ALIGNMENT_RIGHT);
    logindlg.getContainer().add(label1);

    TextBox username = new TextBox();
    logindlg.add(username);
    
    Label label2 = new Label();
    label2.setText("password:");
    label2.setAlignment(Label.ALIGNMENT_RIGHT);
    logindlg.getContainer().add(label2);

    TextBox password = new TextBox();
    password.setEchoChar('*');
    logindlg.add(password);

    Button loginButton = new Button();
    loginButton.setText("login");
    loginButton.setActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent ev) {
            login();
        }
    });
    logindlg.add(loginButton);

    Button cancelButton = new Button();
    cancelButton.setText("cancel");
    cancelButton.setActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent ev) {
            logindlg.cancel();
        }
    });
    logindlg.add(cancelButton);

Which is much more typing than XML.

If we had a way to make a DSL, the code could be like this:

    var logindlg = (Window title="login" layout=(GridLayout 2 2) [
        (Label text="username:" alignment = Label.ALIGNMENT_RIGHT)
        (TextBox)
        (Label text="password:" alignment = Label.ALIGNMENT_RIGHT)
        (TextBox echo='*')
        (Button text="login" click={login()})
        (Button text="cancel" click={logindlg.cancel()})
    ])

See how much shorter the declarative version is? it looks like XML, but it is code. And since it is code, I don't have the limitations of XML: I can do anything I please with it.

But I don't expect to user SuperJava++ to work on a device driver.

Why not?

I've followed this debate, and I think I understand both sides of this issue.

I agree with Achilleas to the extent that current languages like C# are so inexpressive that declarative DSLs like XUL will often be much more concise. Also note that the more expressive/powerful the language, the less verbose it is, possibly approaching the last declarative example in length (using higher order functions, I think you can probably approximate it closely); in fact, using Nemerle's macros you could probably achieve Achilleas' last declarative example almost verbatim. I also think he should have pulled out this example a long time ago to clarify his position.

I also agree with others stating that you probably can't have a single language suitable for programmers that's good enough for absolutely everyone; the semantics of such a language would probably be so complicated that it would require significant programmer annotation to express precisely what he means (at least given our current knowledge), in which case you would use a few smaller languages more well suited to the specific problems. You can have such a "universal language" that is suitable for machines, and I would call them "compiler intermediate languages" like LLVM (by "everyone" I mean the entire spectrum from low to high-level constructs, including memory allocation).

However, with embedded-DSL approaches like Formal Islands, you might be able to approximate the advantages of both and reduce the need for additional languages. Given current knowledge, I think Formal Islands (or similar extensible-compiler languages) are as good as it gets Achilleas.

You can have such a "universal language" that is suitable for machines, and I would call them "compiler intermediate languages" like LLVM

I was going to make a similar point in response to your other comment about typed assembly languages: Turing completeness works in our favor for low-level languages, because you can always generate code mechanically to get whatever semantics you want in your source language. You may pay a price in terms of performance etc., but it's often low enough to ignore.

But when it comes to high-level languages (for use by humans), there's a basic issue that different semantics don't somehow meld with each other just because you shoehorn them into the same host language: you still have to be familiar with the different semantics of each sublanguage or embedded language. That's why we use the latter terms — they're still different languages, and learning their semantics is the important part.

The gains of embedding are primarily convenient, practical ones such as ease of communication, or sometimes unification of syntax; there's no fundamental erasure of language boundaries (that I've ever noticed, anyway).

you still have to be familiar with the different semantics of each sublanguage or embedded language.

I agree. No one is going to know how to program in a logic language without understanding the semantics.

While semantics are eventually the most important part, perhaps you're glossing over how easy it is to learn the semantics given a simple surface syntax. Many people aren't at the knowledge level of developers/researchers here on LTU, but instead learn certain idioms from reading how-tos, blogs, tutorials, snippets, etc. which solve a specific problem (like event handling with closures in C#). They then start using these idioms daily, and their understanding of them grows, perhaps even to the point where they grasp the full semantics and power of the language (and maybe start looking for more and show up here ;-)).

Simple surface syntax makes it easy to create and communicate these snippets, and I don't think the "semantics mismatch" problem is any worse than what we have with powerful macros like Nemerle'; if anything, the familiar syntax may make it easier to learn the semantics for the same reason that C-like syntax tends to be a requirement for many industry devs to learn a new language.

As a good example of what we're talking about, the MOP of Lisp enables an encoding of multimethod dispatch, which completely alters method resolution. In order to know which generic function will actually be invoked while you're developing an application, you would have to understand multimethod dispatch.

So I think we mostly agree. I'll be interested to see to what extent simple syntax extensibility results in non-interopable/composable surface syntaxes, or non-extensible ones as less experienced devs create their DSLs.

The gains of embedding are primarily convenient, practical ones such as ease of communication

Yes, a big gain, which MS tried (or is trying) with the CLR.

I was going to make a similar point in response to your other comment about typed assembly languages: Turing completeness works in our favor for low-level languages, because you can always generate code mechanically to get whatever semantics you want in your source language.

Right, human-comprehensible interopability between different semantics of embedded languages will no doubt be a problem in some cases. For the particular example of GC/non-GC coinciding, there are possibly some VM tricks, but the library design problem you alluded to is certainly a challenge.

I'm currently leaning towards a lightweight, isolated language process model however, where each process gets its own heap and manages its own memory however it sees fit (like SIPs in Singularity); interoperation thus reduces to an IPC problem over channels or perhaps an exchange heap as in Singularity. The format of data transmitted is the problem, and as P/Invoke demonstrates, often interopable data is relegated to simple value types. But I think that's enough rambling for now... :-)

in fact, using Nemerle's macros you could probably achieve Achilleas' last declarative example almost verbatim.

I should've used Nemerle's macros system as an example in my response further down. But the point still stands. Java is the worst example.

I also think he should have pulled out this example a long time ago to clarify his position.

I thought everyone here knows that DSLs increase productivity.

I also agree with others stating that you probably can't have a single language suitable for programmers that's good enough for absolutely everyone;

But you can have a language for the browser and the server and for desktop applications, even real time (soft/hard), at least. My comments are in the context of Microsoft's language run-time for browsers. There is no need to have xml + html + javascript + java / php / python / asp + c# / etc. A single language could easily cover all these languages.

I am speaking, of course, not for the "exotic" needs of language researchers, but for the domain the Microsoft's DLR is about. It's absolutely crazy that I have to know 5 languages to do the same thing.

var logindlg = (Window title="login" layout=(GridLayout 2 2) [
(Label text="username:" alignment = Label.ALIGNMENT_RIGHT)
(TextBox)
(Label text="password:" alignment = Label.ALIGNMENT_RIGHT)
(TextBox echo='*')
(Button text="login" click={login()})
(Button text="cancel" click={logindlg.cancel()})
])


The only thing you've proposed is to put XAML (or some other declarative syntax) in the language proper.

By the way, Java is a bad example for a concise syntax. .NET languages like F#, Boo, or even C# 3.0 would be more concise.

Why not?

Why isn't C++ typically used for device drivers? Once again, this goes back to context. You want one language to rule them all for every project. "The world" doesn't.

The only thing you've proposed is to put XAML (or some other declarative syntax) in the language proper.

Not really. Think about the power to exploit this XML-like declarative language in a variety of situations.

For example, I can not use XAML to declare my database schema in the code. If I could, the following would be possible:

var db = (database "//localhost:1433/username=sa" [
    (table customer [
        (column id autoincrement)
        (column firstName (varchar 50))
        (column lastName (varchar 50))
    ])

    (table product [
        (column id autoincrement)
        (column name (varchar 50))
        (column code (varchar 10))
        (column value integer)
    ])

    (table purchase [
        (column id autoincrement)
        (column customerId (foreignKey customer))
        (column productId (foreignKey product))
        (column discount integer)
    ])
])

And if the above was formed using macros executed during compile, the macros could actually connect to the database and modify the schema prior to compiling.

That would save huge amounts of working hours and bugs.

There are so many things that one can do using DSLs, especially declarative ones. For example (relative to the above):

1. to produce GUI forms straight from the database
2. to produce the GUI validation code automatically
3. to check SQL at compile-time
4. to automate report generation

Why isn't C++ typically used for device drivers? Once again, this goes back to context. You want one language to rule them all for every project. "The world" doesn't.

C++ is not widely used for device drivers mainly due to ABI issues (each compiler vendor implements its own ABI). But that's not always the case (googled links):

http://www.mactech.com/articles/develop/issue_04/device_driver.html
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx
http://www.cca-forum.org/download/tutorial/guide-html-0.1.0/ch03s02.html
http://uw714doc.sco.com/en/HDK_basics/cplus_top.html

And of course C++ is used in the embedded app space:

http://www.caravan.net/ec2plus/
http://www.embedded.com/97/feat9712.htm
http://en.wikipedia.org/wiki/Embedded_C++

You've completely switched topics now, and completely ignored what was said about using Java as an example. But we've gone back half a circle to you wanting Common Lisp or something like it, which has nothing to do with the DLR or XAML or anything else, except that it could be implemented on top of it (and probably could already be halfway done with something like Nemerle).

Ehud has laid down the law regarding your violation of LtU policies, so you might as well quit while you're behind.

I'll just reiterate that you can do most or all of the above using Nemerle, so if you're looking for a language to define and use these DSLs, then take a look at Nemerle's Macros. For an example of what you displayed above, see Nemerle's compile-time SQL macro.

In programming, differences between languages are superficial.

If that's the case, the differences between the languages you already have and the ideal language you want are superficial, so you should be happy with what you have.

Comparing gross features across languages, such as loops, is very close to a Turing-completeness argument, and the conclusion that differences between languages are superficial is equivalent to Turing-completeness — it's true, but it's orthogonal to the problem that you're interested in.

If you do some work with language implementation — even just to the degree encouraged by books like SICP, EOPL and some of the other favorites from the Getting Started thread (hint hint) — you quickly gain respect for the degree to which tradeoffs in language design are unavoidable, and pervasive. There really are limits to how much you can jam into a single language. You can only have your cake and eat if if you choose quite carefully what kind of cake you want.

For example, the desire for "optional garbage collection" is quite a problematic one — are there any languages you'd like to propose as having a model implementation of optional garbage collection? As you start adding in other requirements, such as first-class functions and strong types as mentioned in one of your wishlists, you're likely to run into serious trouble. For a humorous take on this, see The Two Doofuses, or Why Type Safety and the Garbage Collector Really Exist (previously on LtU).

The Lisp example might shed some light on this issue. Lisp supports embedded DSLs well: it allows you to embed languages in Lisp that have different semantics from standard Lisp. But embedding such a DSL in Lisp doesn't somehow eliminate differences between the semantics of the DSL and of the host language. What happens instead is that multiple languages are integrated using a similar surface syntax. However, the semantics remain different. For example, if you embed logic programming in Lisp, or relational data manipulation (e.g. SQL semantics), it becomes very clear that you're dealing with languages with different semantics, whose characteristics have to be learned and understood independently of the host language. You also still run into issues of communication between the different DSLs since they have different ways of dealing with data.

If that satisfies your desire for a single all-purpose language, then you're in luck, because that's achievable. It's also useful — as it happens, this capability is a big reason I enjoy using Scheme. But if anything, this only underscores that differences between languages aren't just superficial. Performing a task using a relational data manipulation language, whether or not it's embedded in Lisp, requires a significantly different approach than performing that same task using, say, a network of objects. And it turns out that there are some tasks which are more easily done with one approach than the other, which explains why everyone didn't just dump SQL when object-oriented languages (and databases) came along, or why people still use logic programming for some tasks but not others. The differences are not all superficial.

There's no question that it's possible to have general-purpose languages that meet a wide variety of needs. Looking at your wishlists, it seems to me that something like C# might, on paper, already come close to what you're looking for, or at least could reasonably evolve into it (think Linq, for example). Perhaps you agree with that. But if you disagree, you might find that it's because when you get beyond the high-level wishlist into the nitty-gritty details of language feature tradeoffs, there are many choices you don't get to make entirely freely, and they add up. So while C# might, at a marketing bullet-point level, satisfy much of your wishlist, the devil is in the details. Unless you take the position that the details are all superficial, in which case any language is good enough.

In programming, differences between languages are superficial.

Does it need to be said that this runs against the basic premise of LtU (and of anyone working on programming languages)? I really don't see a reason to discuss this type of view here. I think a discussion starting from this claim runs the risk of violating items 4b,4c,5,9, 10 and 13 of the LtU policies document as well as many of the items mentioned in the LtU discussion quality subsection of the "spirit of LtU".

It's important to have 'political' discussions about programming languages from time to time, as the progress in programming languages is directly tied to the wishes of the people involved.

It's not about politics but about your anti-social behaviour you do not even realize because you are not intentionally a troll but someone who simply doesn't stop and get it when he can't win an argument.

Just because I disagree, it does not mean my behaviour is antisocial. I have not insulted anyone.

My view is that programming languages could be much better than what they currently are. I have plenty of arguments on that.

Would you care to debate the issue?

My view is that programming languages could be much better than what they currently are.

Posting in a group devoted to studying the properties of programming languages that "differences between languages are superficial" is anti-social, not to mention difficult to justify technically. It could even be considered insulting, since many people here have spent years studying those "superficial" differences.

In your defense, it's not clear that you understand the problem with your claim, but that in itself is another problem: most people here have enough of a genuine interest in the properties of programming languages to have at least studied some of the basic introductory texts such as SICP, CTM, EOPL or others mentioned in the Getting Started thread. From your comments, it is clear that your study of such material has been limited at best. If you'd like to contradict me on that, I'd be truly glad to hear about it.

Ehud's comment was not about math, but about this apparent lack of genuine interest in, or respect for the subject.

Posting in a group devoted to studying the properties of programming languages that "differences between languages are superficial" is anti-social, not to mention difficult to justify technically. It could even be considered insulting, since many people here have spent years studying those "superficial" differences.

Just because an opinion goes against the mainstream, it does not mean it is incorrect. I stand by my opinion that differences in programming languages are superficial, and I would like it very much to go into any technical details, if you want.

In your defense, it's not clear that you understand the problem with your claim, but that in itself is another problem: most people here have enough of a genuine interest in the properties of programming languages to have at least studied some of the basic introductory texts such as SICP, CTM, EOPL or others mentioned in the Getting Started thread. From your comments, it is clear that your study of such material has been limited at best. If you'd like to contradict me on that, I'd be truly glad to hear about it.

You've said that in another thread as well, but I've read those papers, as well as few others...and I found no evidence that having to use 5+ programming languages is how things are supposed to be.

Ehud's comment was not about math, but about this apparent lack of genuine interest in, or respect for the subject.

Perhaps you might not care about it, but I certainly do, and lots of other programmers that have to deal with the horrible mess of html, xml, javascript, java, php and hack upon hack that makes even the simplest task so incredibly difficult care as well.

And increasing productivity and making our lives easier in programming is directly connected to programming language theory.

Please don't continue this discussion on LtU. As I explained earlier, the issue isn't your views but your disreagrd to the LtU policies that were designed in order to protect the quality of discussions on the site. You are of course welcome to open your own site, and invite LtU readers to join the discussion there, or post your email so those interested can continue the discussion offline.

This is not a suggestion, but rather a decision: I feel this discussion has run its course on LtU, and will not allow the debate on "superficial" differences to continue here.

Given advancements in typed assembly languages (foundational proof carrying code in particular), we can almost have our cake and eat it too, ie. a type safe VM with manual memory management. What I'm currently reading: Certified Binaries.

As for what's available, last I heard BitC had GC and non-GC compilation profiles. If you compile without GC, you need to provide a safety proof on each deallocation.

For example, the desire for "optional garbage collection" is quite a problematic one — are there any languages you'd like to propose as having a model implementation of optional garbage collection?

Managed C++ (by Microsoft) is a good example of it.

For a humorous take on this, see The Two Doofuses, or Why Type Safety and the Garbage Collector Really Exist (previously on LtU).

I do not see how the story you posted is a valid argument. Type information can exist within the bytecode, eliminating the problem of what is a pointer and what is not (for example).

For example, if you embed logic programming in Lisp, or relational data manipulation (e.g. SQL semantics), it becomes very clear that you're dealing with languages with different semantics, whose characteristics have to be learned and understood independently of the host language. You also still run into issues of communication between the different DSLs since they have different ways of dealing with data.

No, there is no such issue. Getting the data from a piece of code that represents SQL and applying them in a piece of code that represents a logic language is very easy, if we are within the same language: the only thing we have to do is write the appropriate converters. We do not have different IDEs, different tools, different ABIs, different doc style, different VMs etc.

Different libraries for the same language have different semantics too, but the problem is not about semantics, but about complexity: for example, using 5 different languages for web applications (js, java, jsp, html, xml for example) increases complexity tremendously.

Performing a task using a relational data manipulation language, whether or not it's embedded in Lisp, requires a significantly different approach than performing that same task using, say, a network of objects. And it turns out that there are some tasks which are more easily done with one approach than the other, which explains why everyone didn't just dump SQL when object-oriented languages (and databases) came along, or why people still use logic programming for some tasks but not others. The differences are not all superficial.

The problem is not the different semantics, but the glue that makes it stick together: there has to be one. As it is right now, there is none, and that creates big problems.

Here is an analogy: matter is made out of basic elements. These elements have established rules in the way they can co-operate. If they did not have such rules, it would not be possible for matter to exist.

Looking at your wishlists, it seems to me that something like C# might, on paper, already come close to what you're looking for, or at least could reasonably evolve into it (think Linq, for example). Perhaps you agree with that.

There are key differencies between C#'s philosophy and what I have in mind. For example, I wouldn't make SQL part of the syntax, but I would form the language in such a way that any DSL could have been easily written in the language.

the devil is in the details

I haven't seen anything that makes it nigh-on impossible to make such a language. Perhaps you have some concrete examples?

programming is all the same: for example, an XML loop is a C loop is a Haskell loop is a Javascript loop. In programming, differences between languages are superficial

While I totally understand where you're coming from on this. You might break it down into a couple different hypotheses:

• all "large" programs become network problems: with data and events flowing about, no single programmer that knows the whole system, hooks into disparate sensors and actuators and data storage
• there is no such thing as a small, stand-alone program because programs depend on their runtime, operating system, etc.. A program is the size of its entire dependency chain, including hardware.
• the distinction between operating system and language is fuzzy and artificial

In the broad scale, there is no such thing as any single 'program'. There is a whole system of communication and behavior. And this system has broad, common concerns: resource utilization, efficiency, safety, security, survivability (resilience, robustness, graceful degradation, disruption tolerance, reliability), concurrency, resource management and accounting (including quotas), etc.

A GUI is part of the system as much as any other - a database, or a webcam, for example - and ought be able to attach to these resources. And it must still meet the same, common concerns described above.

So, I might suggest that the differences between programming tasks are superficial, fuzzy, somewhat indistinct. That doesn't mean a Domain Specific Language isn't useful for describing a particular task; rather, it suggests that any Domain Specific Language must exist as part of a system that gives it access to the necessary resources and supports the relevant whole-system concerns. One might say that, ideally, every DSL is part of a powerful but secure general purpose programming language.

But I wouldn't say that differences between languages are superficial. Indeed, I'd assert the opposite is true: what may appear on the surface to be minor, superficial differences between languages can be very deep in their impact on the relevant concerns: resource utilization, efficiency, safety, security, survivability (resilience, robustness, graceful degradation, disruption tolerance, reliability), concurrency, resource management and accounting (including quotas), etc.

Example: what appears to programmers as a slight difference in how users get access to a console (i.e. via an object vs. static method) might mean the difference between a programming language suitable for widespread distribution vs. one bound to "the" machine that runs it.

It is this nature of languages - that two languages 99% the same can have very different emergent characteristics for full-sized (network problem) programs - that makes the 'one-language-to-rule-them-all' language so difficult to develop.

Of course, any such language would still need to support DSLs (using something like Parsing Expression Grammars, or Extensible Attribute Grammars), because the 'superficial' differences in languages provided by dedicated syntax can be very, very useful for programmers. (There's a world of difference between Inform 6 and Inform 7, for example.)

Anyhow, while I can see where you're coming from, I don't agree with the words you used. Differences between languages can be very deep. Differences between programs (their underlying structure) are somewhat superficial.

Differences between UIs or between APIs can be deep again - with subtle variations that make big systemic differences. Those are, essentially, languages.

Isn't MS giving you all your points with Sliverlight?

"one programming language" - ya, you can program your entire client code with Ruby or C#, the XAML/code behind approach is an option but everything can be expressed procedurally if you wanted.

"declarative as possible without sacrificing flexibility when required" - sounds like the XAML/code behind approach. Declarative (XAML) with a flexible procedural out (code behind).

"native performance" - this is what MS obsesses over, at least you get that.

"good debugging tools" - as long as you use visual studio on Windows.

As someone has already noted, the parent post has a lot of technical errors/biased misconceptions. But maybe this is just because we are talking about Microsoft...

Seriously, think about what you're asking for. If C is a chainsaw with no guards that you can cut your leg off, then this monster would be the little red button for the Atom Bomb strapped to the computer. All this so you can keep from straining your brain a little bit with multiple syntaxes? Not worth it man, not worth it.

so Silverlight is useless for me.

Miguel de Icaza is promising Silverlight support on Mono.

Take that for what it's worth.

I used to find lots of software useless to me because the Vic 20 isn't supported. Then I figured out I can acutally use more than one operating system.

Many firms, including my main clients, are still running Win2K. I can't yet run Silverlight at work, though I can run Flash, and develop applications using XULRunner. You need XP SP 2 or Vista for Silverlight.

I think Mark Pilgrim has the best take on this.

All the cool kids are doing it.

Sigh. I used to have the strength to argue against such foolishness. Nowadays I’m reduced to nothing more than Grey’s-Anatomy-esque catchphrases. Seriously? Seriously? Do I really have to explain why this is a bad idea? Again? To a bunch of technological virgins who haven’t been fucked yet? Seriously?

Oh yes Mark, please explain it to us mere mortals. What would we do without your infinite wisdom?

Mark Pilgrim shouldn't have to explain to us what is the one true way.

I am blogger, hear me roar!

The issue here, isn't technology. CLR/DLR may be better than AJAX or whatever Adobe peddles or JVM or other ways of rendering web apps.

The issue which Pilgrim addresses are issues of vendor trust, of the openness of technology, etc. Quite a few folks would like to replace AJAX (an open architecture for all its warts) with something proprietary--either because they want to make money selling authoring tools (Adobe) or lock out competing operating systems (MS). .NET is some cool technology, but many in the CS world won't touch any of it with a ten-meter pole (even open source implementations like Mono) simply because of who is behind it. The computing world has not once but twice thrown off the yoke of vendor lock-in.

This issue is not a PLT or technological/scientific issue, and is probably outside the scope of LtU. But, when new technologies move from the lab to the marketplace (including FOSS as part of the marketplace), such factors do come into play.

The issue here, isn't technology. CLR/DLR may be better than AJAX or whatever Adobe peddles or JVM or other ways of rendering web apps.

Yeah, and I'll take Pilgrim's Gothkid-like anger as an indication that Silverlight/DLR is pretty interesting.

The issue which Pilgrim addresses are issues of vendor trust, of the openness of technology, etc. Quite a few folks would like to replace AJAX (an open architecture for all its warts) with something proprietary--either because they want to make money selling authoring tools (Adobe) or lock out competing operating systems (MS). .NET is some cool technology, but many in the CS world won't touch any of it with a ten-meter pole (even open source implementations like Mono) simply because of who is behind it. The computing world has not once but twice thrown off the yoke of vendor lock-in.

Everybody is always happy to tell us why "we" shouldn't be using this or that, and there is one true philosophy of openness, and "we" shouldn't trust Microsoft, blah, blah, blah.

This issue is not a PLT or technological/scientific issue, and is probably outside the scope of LtU. But, when new technologies move from the lab to the marketplace (including FOSS as part of the marketplace), such factors do come into play.

Yeah, random Blogger rage is outside of the scope of LtU.

This issue is not a PLT or technological/scientific issue, and is probably outside the scope of LtU.

Yes, we should try to rein in the discussion.

While I can understand this reaction to Mark's rant, this isn't just a question of cynicism. The problem is the blurry line between internal applications and the public web. There was a time in the late '90s when there was a legitimate concern that Microsoft might succeed in contaminating the web with ActiveX, so that non-Windows systems would effectively be locked out of big parts of the web. Ironically, the company which ended up succeeding best at that sort of lockout (and lock-in) was Macromedia, with Flash. Adobe appears to have taken some steps to correct that, although we have yet to see that play out.

I don't personally have any problems with platforms like Silverlight and Apollo[*]. I do have real concerns, though, about what impact it'll have on the use of open standards on the web.

[[*] Edit: I don't have a problem with their use between consenting parties who have choices. The problem arises where they become the only choice and force the choice of a particular platform, particularly in an environment that is otherwise based on open standards. As mentioned above, though, this is a very blurry line, and of course the most aggressive vendors will always try to draw it as far in their favor as they can.]

The market rejected ActiveX and the market pretty much rejected Applets. Flash is pretty universal, in a limited sort of way. The market will decide the fate of Silverlight.

Despite all the belly-aching about Microsoft trying to take over the web, most of the web will remain document-centric, and thus there will be no need for much of what Silverlight has to offer.

Some people just want to get beyond the limitations of DHTML for doing real apps.

You can look at something else besides diagrams.