Lambda the Ultimate

I don't like "lightweight" because people seem determined to take it as referring to functionality rather than ease.

If I feel like pushing two sets of buttons at once I sometimes talk about 'agile languages' :-)

I don't think looking at things like type systems, interpretation vs compilation, etc. to define "dynamic" work that well. It leads to endless arguments about where to draw the line where, I suspect, that there isn't a line to draw. There's a spectrum of languages that are more/less "dynamic" (or whatever) as measured on a number of different scales.

In these languages you customize programs by hacking them while they run. Sometimes that just means assigning variables, other times it means replacing whole definitions, loading new modules, etc. To pickup a user's customizations these programs typically eval a dotfile during startup, as the Jython example does (along with bash, emacs, etc).

While I agree the term in not very precise or technical, I think we all know exactly which languages he is talking about.

And I think we even know what design philosophy they share ("more stuff" happens at runtime than compile time, tendency to quick and dirty, often appeals to "non-programmers" as much as programmers, etc.)

I would suspect our uneasiness with the term is twofold: - it doesn't conform to our own preference for more technical distinctions. - we don't like the implied "marketing value" the term gives those languages at the expense of others we like (also or instead).

Unfortunately, these very factors probably account for the popularity of the term. ;-)

I suspect that people will argue that certain features might make a language more or less suitable for this kind of use, and that's probably a worthwhile discussion. But in the end, Udell doesn't seem to be arguing for a particular kind of extension language. He just seems to be arguing for the use of programming languages to provide configuration/customization features to software.

Here is what I wanted to add to my original post, but didn't:

The term lightweight language that some practitioners prefer is not one bit more meaningful. It makes me sad that well known researchers that know better tacticly endorse this term. If some other community had originated the use of this term, these academics would have been the first to debunk it.

easy to acquire, learn, and use.

What's the difference between acquire and learn?

Use for what purpose? (e.g., think about using to build real time mission critical embedded software)

Based on what previous experience?

Were any of the cognitive factors that are assumed to be relevant ever empircally studied? Were the results significant?

Are lightweight languages (a) small languages or (b) languages that provide useful modularity constructs?

And if the answer to all these that The term "lightweight" refers not to actual functionality does it not mean that the term isn't helpful?

I am quite certain that people writing about dynamic languages don't mean ST, but I am not sure why not...

It seems to me that there are hidden assumptions about the type system, etc. that are not very sound.

(BTW: I don't think builtin documentation should be considered together with fundamental features. The distinction is important.)

The only thing that springs to mind is extensible languages, which is a problem because everyone will have the dreaded xml spectre in the back of their mind. The reason why that springs to mind is that when you say type system expressiveness I think type system extensibility.

'Languages with stuff like eval, read-eval-print loops, builtin documentation, etc.'

Dynamicism might be understood as a continuum from no dynamicism to 100% dynamic (probably neither state being feasible for a language to have) so the question is how does one measure dynamicism of a language. I agree that something like eval must be possible, but am thinking that a language which finds an explicit eval function necessary might be less dynamic than the optimal level of dynamicism, given that there are a languages that have an eval function now that are still not what we might term dynamic.

Another suggestion: First Class languages might be considered to be at a high level of dynamicism.

That was the only distinction I could come up with as well...

I don't think these properties necessarily go together. That's why I suggested we try to deconstruct the term.

when we say builtin documentation I suppose we're saying the language has a help feature, something like:

? myfunction returns "myfunction is of type function: input=0, return=MyVariable"

I disagree. I think these really add to dynamicism, although I think it would be nice to have a help function that did more than returned a string describing the construct help is being requested on.

Do you have some particular counterexamples you're thinking of?

The dichotomies can lead to trouble though. Is Scheme compiled or interpreted?

The scales are not much better. How expressive is Haskell's type system relative to Smalltalk's, er, um, does Smalltalk *have* a type system?

Jon's use of "dynamic language" may be good enough. At least I don't think there is an easy replacement for a casual conversation, although there might be for a PhD thesis.

See here (for example). The distinction is iteself problematic, it may be viewed as an implementation issue.

I don't think PhDs are needed. Practitioners are well aware of the issues - but it is easy to get sidetracked by faulty terminology.

I know you know that Scheme can be compiled, and that C can be interpreted. But this fact is often overlooked.

I wrote a more detailed response to this post but decided to delete it for two reasons: 1) I don't care about "dynamic" or "lightweight" languages on a formal basis, don't use them (except for dirty and quick scripts), 2) It would probably start a flamewar because people are too emotionally involved on these issues.

The only thing I want to say is, regardless of previous experience, when you're doing a simple task (e.g. some small script, application configuration) it's far easier to pick a "lightweight" language, learn and use it than to use some similar "heavyweight" language. For example contrast (in the context of writing simple tasks) Ruby with Eiffel (or C++) or Perl with Ada (or C). How much time would you spend to obtain and install the language (with the necessary environment), learn how to solve your simple task and to deploy and use the resulting application on each situation?

For example contrast (in the context of writing simple tasks) Ruby with Eiffel (or C++) or Perl with Ada (or C). How much time would you spend to obtain and install the language (with the necessary environment), learn how to solve your simple task and to deploy and use the resulting application on each situation?

I am not sure the answer is as obvious as you want it to be. (Is learning Perl really easier than learning C?) But I agree that there are sitations where the differences implied are important. I want to pinpoint the language features that make this the case, instead of lumping them all together.

Simple example: In perl it is easy to write a file filter, since the language provides syntactic (and semantic) support for "read all lines of file, and apply loop body to each". You don't get this for free in Ada. It is possible to build a library to make this as easy in Ada as in Perl - but only almost. Beacuse Ada doesn't have anonymous and first class functions, it's hard for a library to provide h.o.fs that resemble normal construct (i.e., the actions have to be written seperately). A macro facility might help.

Given such a library one could make it a part of the standard distribution or not.

So, for this small example, we can see several language properties that contribute to the different "feel" of the two languages.

I think that this sort of analysis is useful, and is quite needed for terms such as "dynamism".

Doug Kaye: Would you define “dynamic languages?”

Jon Udell: From a technical perspective, there is a distinction between, in the dimension of typing, strong and weak typing. So an example of strong typing would be Java.
IT Conversations

IMO there are three factors involved:

1. How simple/expressive is the language?
2. How comprehensive/consistent are the standard libraries?
3. How simple is the deployment process?

The first item is related to the learning process. Also it relates to what you said about Ada: if you can extend the language (with HOFs or macros for syntatic extension) things are easier and usually languages with such features are simpler because they have less basic control-structures.

The second item is related to the usage. Having a comprehensive and consistent standard library means that I can do more things out of the box and that they have few (if any) interaction problems. For example in Java you can confidently write a program that uses sockets, GUI and regular expressions without having to download third-party libraries, and you know that there aren't incompatibilities between these features. In other languages you have to pay attention to compile library X with some flags and library Y with other flags, or remember that you need to use an older version of library W because the new one is incompatible with the new version of library Z (and you need the new features from Z). Also a consistent library is easier to learn, because it'll use fewer idioms. In this item most "dynamic" languages have comprehensive libraries but they aren't much consistent.

The third item is related to both ease of acquire and use. When I say deployment process I mean creating an application unit (executable, script, bytecode archive file) and running it. In some languages that's not simple enough (i.e. I have to figure which compiler flags should I use because without them the code doesn't compile or the performance (either space or time) is awful).

IMHO these are the properties that contribute to the different "feel" of language implementations. "Dynamic" languages usually are bearable on item 1, nice on 2 and good on 3. FPLs usually are good on 1, awful on 2 and bad on 3. Mainstream languages that aren't "dynamic" usually are bearable on 1, good on 2 and bad on 3. (side note: this point system is: awful -2, bad -1, bearable 0, nice +1, good +2). So I guess people look at these properties when are evaluating the "dynamic" or "lightweight" quality of some language, instead of assessing the relevant factors you mentioned.

1. How simple/expressive is the language? 2. How comprehensive/consistent are the standard libraries? 3. How simple is the deployment process?

It's interesting that important though these factors are, they aren't what comes to mind on hearing the word "dynamic." Compare to what others said in this thread (e.g., weak typing).

• Memory Safety
• Object Encapsulation
• No Static methods that grant authority
• No static mutable state

I feel that this factor is somehow related to dynamicism of a PL. Then again, being capability-friendly may be just a special case of static typing...

The perception I have from a general use of the `dynamic language' term, is that it refers to languages which allow to easily write and modify their programs (definitely not C or Java, but rather stuff like Python, Scheme, etc).

However, being "dynamic" could be a language trait (in which case it may surely mean that all/most decisions are deferred until run time), it can also be a program trait (allows to load plugins), or a process trait (allows easy change during development).

Maybe considering dynamic as the opposite of static could help in our understanding of both terms ?

A dynamic language is a language in which most decisions are deferred until run time. A static language is a language in which most decisions are made at compile time.

That's a great definition for two-staged programs. What about mutli-staged code? In general we have a list of decisions' amount per stage, or even a continuous distribution graph (distribution of probability of a decision to be done at this stage). Do we measure dynamicism (dinamicity?) as a position of center of masses of decisions graph against stages? Or as a degree of spikeness of the graph (choose your concrete statistic function here)?

Another metric might be the length or branching factor of the "stages" list (in a broad sense). On one side of the spectrum would be the closed-world one-chunk languages with static typing, on the other - languages that can introduce new code at very fine level of granularity (think eval).

So, for very static languages the "stage tree" is a very short list, and for very dynamic it is a very fuzzy bush. Hmm, I need to formalize this, as I do not master English enough to present my point clearly.

I agree that the implied antonym of "dynamic", as it is used here, is probably "static".

Static type-checking is type-checking that takes place all at once: at "compile-time", if a compilation stage is involved, or at some other point such as when a module is loaded. It normally happens prior to execution. In an environment where modules can be loaded on demand, during execution of other code, "static" type-checking might take place "dynamically".

Any type-checking at all must in fact involve the consideration of some piece of state: some inert code that can be inspected by the type-checker, and that can be safely assumed not to change during the inspection process. Even delayed-until-the-very-last-minute type-checking is "static" in this sense.

The difference between "static" (so-called) and "dynamic" (so-called) languages is neither one of degree (of "dynamicity", or some other such fuzzy notion) nor a flat binary opposition. I would suggest that it has to do with the size of the smallest "atom" of state that can be independantly verified by a language's type-checker.

In a language like Python, individual method calls are checked at the point of invocation to make sure that the targeted method exists and the number of parameters matches (if these conditions aren't met, the invocation is senseless and execution simply cannot continue). No other type information is used in the process: this small piece of state is examined independantly of the rest of the program's state.

By contrast, the type-checking performed by a Haskell interpreter requires the type-checker to "remember" all of the type definitions that have previously been submitted to it: each new statement is checked for consistency with every statement that has gone before. The smallest atom of state considered independantly by the Haskell type-checker is the whole program (that is, programs are checked independantly of other programs).

How so?

Capability friendliness a special case of static type checking... How so?

You right, it's not a special case. The only problem in JavaScript is lack of encapsulation; in Scheme, it's global mutables in defines. If one removes defines from Scheme, it's capability-ready, but I am not sure how to work in such restricted language.

I jumped to conclusion about static type checking probably because one can use types for catching undesired behaviors, but of course it's easier just to remove the whole class of these behaviors from the language.

By this definition, Turing machine is very static, while lambda and pi calculi seem to be more dynamic.

And every language with a MOP is very dynamic.

Closely related is probably the degree to which code can be manipulated as data. There seem to be very fine shades in this, e.g. program written in machine code is dynamic (assuming the architecture allows), while the same program written in pure assembly language is not - you can modify instructions, but you don't know with what values; for code manipulation you need to know opcodes and instructions encoding in general, which strictly speaking is not part of the language. There is still a possibility left to create a library that provides this knowledge, so we can say that dynamism is enabled, but not actively supported by assemnly language. Another example is Java, in which one can create new classes on the fly, but doing this requires knowledge of bytecode, class definition layout, etc., and as such is not part of the language, therefore Java is not dynamic (and the first definition agrees - Java has reification, but no high-level reflection in the language, just low-level bytecode manipulations).

All in all, raw manipulation of code enables dynamism, but alone does not make the language feel dynamic. For dynamism, one needs reflection/reification on the same conceptual level of details as the rest of the language.

"define" could work with multiple top-level environments, given no means of referencing another environment from some other.

The Scheme library may need looking at for avoiding confused deputies, etc.

"define" could work with multiple top-level environments, given no means of referencing another environment from some other.

In this case:

1. a top-level environment becomes a minimal unit of trust (there is no security inside an environment)
2. a top-level environment becomes a maximal unit of trust (there is no possibility to interact with other environments)

The Scheme library may need looking at for avoiding confused deputies, etc.

Of course, even if the language itself is secure, it's up to developers to use it properly. Actually, when I said that defines are the only problem, I meant Scheme as a core set of five or so special forms, and not the whole R5RS - I had to be more specific.

Nope, there exist static, i.e. compile-time MOPs, for example in EuLisp. The idea of a static MOP is one of the precursors of aspect-oriented programming. (There are now several approaches for dynamic AOP, but one of the stressed advantages of AspectJ in the beginning was that everything is done at compile-time.)

Nope, there exist static, i.e. compile-time MOPs, for example in EuLisp.

Cannot we say that in languages with compile-time MOP we have in fact two languages - one (dynamic, because of MOP) that calculates the code, the other (static, because there is no MOP) that executes the code?

That returns my attention to another idea - if a PL has stages with different rules, then chances are the number of stages is fixed. Even if the rules for stage n+1 are defined recursively from rules for stage n, and therefore allow infinite number of stages, the look and feel (cognitive issues, hehe) will be not dynamic. Leading to a hypothesis: to feel dynamic, language must have unlimited stages with the same rules (sublanguage) on each stage. A quick and dirty solution for that requirement being eval.

No, that's the idea. If you'd like to run untrusted code, you create the top level environment in which to run it. There would be no means of accessing the other top level environments in which other code is running, unless some definition in that environment enables such access.

That untrusted code could use define, but only to affect its own top level.

I think this relation you see is an artifact of the operating systems we're used to; under a capability OS you could have a very static language oriented towards building small closed-world binaries that works well at capability programming. But if you built those binaries in Unix, where do they get their initial capabilities? Where do they go after the program has run? So it's natural for a capability language to be a dynamic language in Luke's sense, above -- it wants some OS-level features we don't normally get, so it's easiest for it to just be its own OS.

That untrusted code could use define, but only to affect its own top level.

Exactly. On the other hand, if you ban define completely, Scheme becomes nice capability-secure language, with capabilities being closures. I didn't prove that, but have a very strong feeling it's true.

But I also feel we have to move this discussion off this thread :-)

Most of the characteristics described so far seem to make the initial approach to programming easier, at a potential cost (of robustness or clarity or performance) if the program grows large or complicated. Of course, those costs may never materialize.

Under that interpretation, there's no reason why any particular language characteristic (with the possible exception of intrinsic verbosity and pedantry!) need be incompatible with a low-commitment environment. People assume that, for instance, static typing is inherently high-commitment because they haven't seen a really nice low-commitment environment for a statically-typed language with type inference.

I like the conceptual separation of 'language' and 'environment', because it allows me to consistently assert things like: "I prefer static languages and formal proofs because they encourage better programs." AND "I prefer dynamic environments because they encourage better programming.".

Personally, I think that terms like `lightweight', `dynamic' and `agile' are marketing-speak which try recast a demerit as a merit. They sell the proposition that programming is easier than statically typed languages make it appear, that you don't need the extra support an ST language can provide. For many people, this is an attractive proposition to buy into because it assuages their fears and insecurities about tackling large projects, and rationalizes their unwillingness to become better informed about a field that they perhaps suspect (correctly) is far larger and more subtle than they are comfortable with.

Think about Ptolemy and Copernicus. It's much easier to live in a world where you think you already understand how and why things work than to live in one with lots of variables and unknowns, or, indeed, one which you realize you might never totally comprehend.

"I can't understand why people are afraid of new ideas. I'm afraid of the old ones." — John Cage

I agree to stay out of this, but to say I disagree with much of the rest of Frank's message.

Well, I do agree with the John Cage quote.

They sell the proposition that programming is easier than statically typed languages make it appear
Agreed.

Oh gawd, not this discussion again...
No, we cleverly skipped past that discussion and discussed terminology instead ;-)