Lambda the Ultimate

I'd say that's right, as far as it goes.

Type inference usually refers to "implicit" static typing, where types of variables are statically determined from analysis. The Hindley-Milner type system upon which ML and other languages are based is one example.

That doesn't preclude a dynamic type system from being statically analyzed with some type inference mechanism. For example, Python (the compiler, not the language) is capable of performing type inference for many cases in Common Lisp. It's used by CMUCL, SBCL, Scieneer, and others.

Amusingly enough, I first read this sentence like this:

It is possible to write ("useful") programs to create any function/class/method/namespace abstraction

:-)

A particular language might be interpreted or compiled in different implementations; does that mean sometimes it's a scripting language and sometimes it isn't? A good example of this is Haskell. GHC compiles Haskell, and Hugs interprets it. Does this mean that Haskell is sometimes a scripting language? Haskell also tests the boundaries of the second requirement: to write any useful program, you must bind main to a monadic action. This might be considered a function, and it might not. Under the GHC implementation, monadic IO actions are implemented as functions where type IO a = World -> (a, World), but other implementations might do it differently. Again, does this mean that with the GHC implementation it's not scripting, but with other implementations it is? Here's hello world program in Haskell:
main = putStr "Hello, world!"
Even if main is technically a function, the programmer doesn't have to worry about that. Does it pass or fail your second requirement?

Anyway, there are very few languages (I can only think of Tcl and Onyx) that are directly executed from the source with no internal intermediate stage. The rest of them use a bytecode, an AST, or compile to machine code. But for the ones that compile to machine code, it is trivial to set up a shell script to compile the file and store it in a temporary file, then immediately execute the temporary file. How is this different from compiling it to a bytecode and then executing it, apart from implementation details? To the programmer, it works the same way.

I generally try to avoid talking about "dynamic languages" and "scripting languages"; they're vague and don't convey much information. It's much more useful to talk about "languages with advanced reflection capabilities", "dynamically typed languages", "languages that have repls", "languages with an implementation that interprets the code", and "languages that don't require you to write an explicit main function/class". Everyone has their own idea of what scripting languages and dynamic languages are.

Sorry if this came off as trollish.

The difference between a scripting language and a programming language is the difference between a conflict and a war. When the government wants to kill people but the public won't swallow it, a war is a conflict. When the government wants to kill people and the public will swallow it, it's a war. Hence Korea and the War on Terror.

Similarly, when a language community wants to seduce non-programmers or make the language seem simple, they advertise it as a scripting language. However, when they want to seduce professionals or be taken seriously, the language becomes "not merely a scripting language..."

The difference between "scripting" and "programming" is spin.

I agree that scripting has come to mean "non-serious language" and that the term is carelessly thrown around. However, it does (did) have a useful meaning.

A scripting language is something that manages high-level control and data flow for one or more larger components (like shell scripts, video game scripts).

Since "scripting languages" can sometimes be used to create entire programs without external components, I think the term "scripting" more accurately applies to the way you are using the language. The term "scripting language" is just an approximation that lets you know that a language's primary use is scripting.

By that definition, I don't think Python can be considered primarily a scripting language. The misuse of the term probably started when Perl came around. It's good for shell-style scripting, which is probably why it is called a scripting language, but can also be used to write full programs. Since Python is somewhat similar to the "full-fleged program writing" side of Perl, I guess everyone just used the same term.

The difference between "scripting" and "programming" is spin.

I want to expand on this. I think it is true, but as the advertising world has shown us, spin clearly makes a difference on people's perceptions of how they use a product.

So what is the "brand image" of "scripting" vs. that of "programming"?

Scripting is:
- fun and informal
- easy enough for a "non-programmer"
- get stuff done in three lines

Programming is:
- serious and mathematical
- done by specialists
- requires careful thought and planning

Is it possible that the respective spin actually does affect the design choices for a given language, as well as the culture and practices that surround it?

What do those of us who want BOTH aspects to our PL do?
Spin ourselves sick?

What do those of us who want BOTH aspects to our PL do?

So, design and implement your PL the Right^TM Way, then just release it under different names, probably disabling some features :)

Like Scripting Edition, Programming Edition, Backyard, Cleanroom, BDSM Editions...

Well, businesses usually differentiate their otherwise identical products by packaging

I realize that you are (probably) joking Andris, but you seem to have continued with the idea that it is JUST "spin" or JUST meaningless packaging that we are talking about.

I'm proposing that the stated values of a programming community or of a PL designer DO have a significant effect on what features are introduced and what practices are typical for that PL.

I don't know about anyone else, but I've grown tired of the thesis/antithesis of scripting/programming and want to go beyond to a synthesis of the underlying values at issue.

Could both things co-exist in one PL without it becoming a dog's-breakfast of features?

Or are these values really mutually exclusive?

My point is similar to Ehud's (hopefully I understood his), but more extreme: many of the attributes that we assign Scripting Languages have nothing to do with the actual language, and everything to do with the implementation.

Take Smalltalk, for example. Many Smalltalk proponents will tell you that their language is better than (C/C++/Java/C#/Haskell/Whatever) because it lets you change your program while it executes, even though this capability has nothing to do with the language itself, and everything to do with the implementation.

To users, a "Scripting Language" has very little to do with language, and everything to do with scripting. PERL is a scripting language not because it has dynamic variables, or because writing large programs in it is a torture :-) It is a scripting language because you can "copy con > a.pl", type a single useful sentence, and execute it by invoking "a".

But a language can explicitly support run-time change, and provide useful interfaces to guide it. For example, Common Lisp provides CHANGE-CLASS and various generic functions to be customized like UPDATE-INSTANCE-FOR-REDEFINED-CLASS. And there are defined semantics for function redefinition, and how it interacts with function call sites. When Smalltalkers speak of run-time change, they are probably thinking of language features like these.

In which situations is it more productive to consider the programming environment as a whole?

* The program's textual source file is directly executable

No computer program source file in a high level language is directly executable. When you "execute" your Perl batch script, the source file is read, parsed, converted to bytecode and then the bytecode runs in the virtual machine, which is the one to actually convert what the Perl programmer meant into real assembly code to the underlying computer machine. Which, can actually be just another virtual machine, say, if you're running Python on Java via Jython...

* It is possible to write ("useful") programs without creating any function/class/method/namespace abstraction

That's the beauty about a large builtin library already programmed for you and code reuse... :)

Of course, you won't get away without writing your own functions and modules in a real large program, but for simple scripts, it's ok.

It is interesting to note that the first requirement is environmental in nature. Thus, ASP.NET (which takes a C# file and compiles it "as necessary" when new web requests arrive to the server) meets the first requirement, while failing on the second.

sorry, but no, ASP.NET doesn't compile a "code-behind" C# file as necessary: it compiles it before executing, even when jitting. C# isn't a scripting language by any measures.

Scripting languages are known for rapid prototyping, iteractive development, non-declarative typing and succint syntax. It's also known for a generous balance between object-oriented, procedural and functional programming, as its supporters comes from various fronts with various degrees of programming culture.

C# and Java come nowhere close. In fact, it's much easier to confound Ruby with OCaml than to try to picture C# as a scripting language.

Not that .Net doesn't have scripting languages, as IronPython or Jscript show...

Of course, you are absolutely correct that ASP.NET requires a compiled MSIL file as input, which it then JITs. But in fact, there's no real reason why it should not accept the actual source code (and in fact, I was involved in just such a project once, which led to my embarassing error here).

Scripting languages are known for rapid prototyping, iteractive development, non-declarative typing and succint syntax. It's also known for a generous balance between object-oriented, procedural and functional programming, as its supporters comes from various fronts with various degrees of programming culture.

You're mixing cause and effect. Rapid prototyping" and "interactive development characterize the environment, not the language (apart from the necessity of some languages to have a minimal amount of abstraction, as I've indicated above). Some scripting languages don't meet even these requirements -- how is Perl "interactive"?

Non-declarative typing: This, of course, is the real issue between us. I don't regard this as a requirement at all.

Some scripting languages don't meet even these requirements -- how is Perl "interactive"?

simple: i type the program in Emacs, save and then test it in eshell. :) Do you really think it is feasible to write large programs in an interactive repl? Interactive shells are there just to quickly find out and test features, but it is truly horrible to actually program in it.

Non-declarative typing: This, of course, is the real issue between us. I don't regard this as a requirement at all.

Still, all popular scripting languages feature non-declarative typing: there is strong typing, though no declarations: which leads to conciseness and rapid prototyping.

(a) By interactive development he doesn't mean to type everything into the REPL and not save it. Generally, working interactively means that you can conveniently access and manipulate a REPL, and you load your whole program into it, but all the work you do is saved into proper files. It is, in fact, truly wonderful to work in an environment like this, compared to the edit, run, crash, debug cycle.

(b) Perl is not strongly typed.

There is actually an interactive Perl implementation: The Perl Shell. It is kind of a nice way to find out what Perl expressions do interactively. It saves a lot of time and headaches, and is a reasonable shell replacement to boot.

Haskell programmers would suddenly become militant "lazy typing" advocates, because there's no reason for a lazy language to care about the types of values that are never demanded. And Perl programmers would tell each other that "lazy typing" is hopelessly complicated and impossible to understand.

Tune in next week when we give dynamic scope a much needed makeover by calling it "lazy binding".

The commercial world would avoid lazy typing like the plague, figuring anything that actually admits it's lazy should be shunned like a hot stock tip from Martha Stewart's broker. However, in a spurt of "innovation" by a major software company, the technology will rebranded as "just-in-time typing", and will then take the business world by storm.

Apropos some of this thread, there is this quote from Erik Meijer's homepage:

Before joining Microsoft, I was an associate professor at Utrecht University where I worked on advanced scripting languages such as Haskell, XMLambda, and Mondrian

That settles that. ;-)