Lambda the Ultimate

Now onto the main point...

If he really wants to make Python the "most widespread common scripting language ", then he should pay Guido to take out "whitespace as defining blocks" feature, and replace it with begin/end,(),[],{.} or whatever other delimters.

Disclaimer: This is not an argument for or against "whitespace defining blocks". ( Though I do personally hate it. ) It is an observation that if all the people who do not use Python solely for that reason, were to start using Python, then it would become the most popular language ( not just scripting language ).

ROTFLOL

Elegance is one attribute I would not associate with Python. And yet, Python remains simple.

That is how we proclaim the mystery of our faith.

Python's reached the stage, in terms of cruft and baggage (for the sake of backwards compatibility), where if you want "elegance" you have to choose a subset of the language and use it consistently - it's a bit like Perl in that respect, although the pathology is not quite so advanced.

Some smart people might complain about whitespace on the grounds that it's dumb (Eric Raymond said it initially made him think of COBOL, although he warmed to the language later on).

I don't have a problem with Python's use of white space myself. Would a novice programmer (syntax-virgin / tabula rasa) looking to do some "scripting" to make an OpenOffice "macro" necessarily be happier with curly braces? I have a feeling they're something you get a taste for by programming in a curly-braced language.

It might also be because, unlike Python, Haskell provides a mechanism to nullify the offside rule:

do x <- fetch ref
   put ref (x+1)
return 666

is the same as:

do { x <- fetch ref; put ref (x+1); return 666 }

Erik Meijer writes all his Haskell code in the latter style... well, he used to. I don't think he uses Haskell anymore. :(

Actually, people complain about the layout rules pretty regularly on the haskell lists (sorry, I don't have time to find references). Haskell does provide an alternative, and there are a fair number of people who use that style exclusively. This doesn't satisfy everyone, of course, but it seems to do pretty well.

Personally, I think the Haskell layout rules are a bit complicated and rather unnecessary...

Let's turn out attention to the more general question of scripting. The approach at the heart of `Python Scripting Everywhere` seems to be similar to the approach Microsoft is taking with their scripting efforts: expose domain-specific objects (DSOs) and use a general purpose scripting language, instead of designing separate domain specific languages (DSLs) for each application.

DSOs have some obvoius advantages: Maximize ROI from language implementations, multiple language support for each application (e.g, VBScript and JScript), shorter learning curve, multiple application scripting from inside onw script becomes possible.

Yet, one has to wonder whether the fact that you don't supply a DSL, with application specific language constructs hurts expressiveness badly enough to have impact on usability (esp. for end-users), expressive power (e.g., when and where can you plug in your scripts), abstraction level etc.

It's easy to understand why DSOs are becoming so widespread as opposed to DSLs. What are your thoughts on this trend?

When you need scripting it is almost always because you need to combine functionality from several domains. It's hard to create DSLs that can be combined. OTOH it's easy to combine DSOs, because they use the modularity functionality from the scripting language.

Has MSFT ever given much thought to end user scripting? Excel, yes, but that was a copy of 1-2-3. VB? Kind of, at least pre-VB.6.

Maybe there are other examples, but nothing with the impact of Hypercard.

Come to think of it, who *has* ever given much thought to end user scripting?

Hardly anyone. In fact, it is hard to get even the LtU readership interested in this. Perhaps decades of disappointment made people weary.

It's not that I disagree with Patrick and Sjoerd, but I am disheartend that the implication from what we are saying is that there's not much to language design beyond specifying a relevant vocabulary.

I use Javascript for most of my projects. Javascript even requires DSOs to do anything useful at all. Javascript is more than sufficient, but far from ideal. That's why I'm designing Loell.

But I don't like the idea of DSLs. Creating a language only for one domain seems like a waste. I'd prefer domain inspired language features. (That's probably how languages evolve most of the time) I don't think there are domain specific language features that aren't useful in other domains.

Despite this I believe most administrators continue to use DOS BATCH files to script Windows. In can think of several reasons for this:

1. In most cases directory/file access and the ability to specify command line arguments and environment variables is quit enough.
2. Likewise, the DOS BATCH flow control structures although very simplistic are usually enough. In fact, I'd imagine some admins may find the VBScript/JavaScript flow control structures intimidating.
3. Activating an external applications using WSH DSOs is a lot more complicated than simply typing them out in the DOS BATCH DSL.
4. Even with .bat files you can achieve quit a lot using piping. To implement piping with WSH you may need to resort to embedding that DSL in strings.

Add to all this the fact that Microsoft never provided a development environment for sys admins for constructing WSH scripts.

Aren't there some important differences? What about Python is class-based whereas Javascript is prototype-based (unless were talking JavaScript 2.0).

Other language features that I don't think Javascript has:

* yield * list comprehensions * keyword arguments?

We'll have to see how Monad succeeds in working around the issues you mentioned.

Perhaps JavaScript doesn't have but JavaScript with BeyondJS (A library written in JavaScript by Sjoerd Visscher and myself) adds all of the stuff you mention, and much much more:

> yield

BeyondJS implements lazy lists that are modeled after Haskell. A superior alternative to yield IMO.

> list comprehensions

Is this good enough:

var sum = (1).to(10).fold("+");

> keyword arguments

BeyondJS provides numerous currying methods that exceed the number of those provided by any other PL I'm familiar with.

Right. Because this amounts to the Turing Tar-Pit (in which everything is possible but nothing of interest is easy). You see, this is the difference between DSOs and DSLs. The issue is whether exposing DSOs makes programming interesting things easy enough, or whether higher-level programming constructs are needed.

Worse, even if you have DSOs, they are often not at the level you really need. For example suppose I want to write a script that processes a web page (say a bookmarklet). Javascript gives me the DOM, but this is not the level I want to think at. I want DSOs that convey application-level abstractions (e.g., I want an object implementing a discussion group message, not a cell of a table nested inside another table, in the second DIV on the page). Now I want to be able to write code that applies to all messages without struggling to get at them out etc. And all that, before I even begin to invent declarative constructs relevant to the kinds of scripts I am mostly interested in.

Speaking of XML and JavaScript, remember E4X, BEA's DSL for XML on top of JavaScript. Apparently they agree that a DSO is not enough.

Of course. Whatever made you think that I have only one complaint up my sleeve?