Lambda the Ultimate

inactiveTopic Dynamic languages and virtual machines
started 8/26/2003; 8:55:39 AM - last post 11/24/2003; 7:44:14 PM
Ehud Lamm - Dynamic languages and virtual machines  blueArrow
8/26/2003; 8:55:39 AM (reads: 5633, responses: 32)
Dynamic languages and virtual machines
Jon Udell posts some thoughts about the role dynamic languages can have in improving robustness (what else) of distributed computing. Don Box's has a rejoinder.

I think programming language technologies can sure help with the robustness and integrity of distributed (and cross language) processes. Obviously, I don't think "dynamic languages" are an important part of the solution.

Indeed, some implementation technologies are related, in particular preserving type information at run time (see our previous discussions on implementing generics/templates on the CLR).

But much more important are things like proof carrying code (discussed on LtU Posted to general by Ehud Lamm on 8/26/03; 9:09:16 AM

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
8/26/2003; 12:31:15 PM (reads: 1386, responses: 0)
...more capable run time engines (i.e., VMs) enable techniques and design choices that are not supported natively by contemporary hardware.

This statement will, of course, allways continue to be true...

James Hague - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 6:07:09 AM (reads: 1308, responses: 1)
Too bad Box closed with a swipe at Perl. I am tiring of faux higher-level discussions that merely serve as tools for promoting/criticizing the languages that the author loves/hates.

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 6:39:48 AM (reads: 1326, responses: 0)
Yeah, that wasn't the most important part of his message. But, personally I am more fed up with people who use every bit of new technological infrastructure to argue that static typing is doomed.

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 6:43:03 AM (reads: 1293, responses: 8)
Jon's has more to say on the issue (and so does Box).

Matt Hellige - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 7:45:53 AM (reads: 1317, responses: 7)
Jon Udell says:

For example, both Perl and Python are dynamic, in the sense that you need not declare a type when first assigning to a variable. But while Perl's typing is weak -- you can just assign a date to a variable that holds a number or a string -- Python's is strong. Once a variable has a value, Python cares very deeply about what its type says that thing can or can't do.

I confess that I really don't understand this comparison. Either that, or he's just wrong:

  [dhcp107136: mmh]$ python
  Python 2.2.1 (#1, Dec  4 2002, 20:47:08) 
  [GCC 3.2.1] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import time
  >>> x = 5
  >>> x = "hello"
  >>> x = time.localtime()
  >>> x
  (2003, 8, 27, 10, 31, 18, 2, 239, 1)
>>>

Isn't this precisely what he was saying you can't do in Python? I admit that I really don't remember a single thing about perl, so maybe somebody else understands the point that he was making?

Bryn Keller - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 8:31:36 AM (reads: 1343, responses: 5)
He's just saying that unlike Perl, Python won't do any implicit conversions or casting. For example, you can't use a string where a number is expected. Perl will sometimes convert values from one type to another (turning 1234 into "1234", say) depending on context. Python won't.

Matt Hellige - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 8:52:23 AM (reads: 1362, responses: 2)
Oh, I see. Do you agree, then, that his example of assignment was bad, then? Is there ever a time when variable assignment exhibits this behavior?

Isaac Gouy - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 9:35:56 AM (reads: 1265, responses: 0)
Have you ever used an interactive environment for a Pascal-like language? It is a very different experience from using one for Lisp, Smalltalk, or Python.

With the best intentions, it's hard not to get distracted and confused when languages are used as short-hand for some more specific idea. Language implementations are too varied and our experience of them too particular.

IDE for a Pascal-like language?
Delphi? ETHs Oberon-2 workstations? XDS Oberon-2 that compiles so fast it might-as-well-be incremental compilation?
Oh! "Pascal-like" is being used as short-hand for 1970 command-line tools. I seem to remember using a DEC 10 Lisp implementation just like that.

Bryn Keller - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 9:51:31 AM (reads: 1375, responses: 1)
Yes, I can't see how assignment could usefully demonstrate the property (I think) he's talking about.

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 12:46:09 PM (reads: 1372, responses: 0)
Well, if it v = exp and exp raises a type error

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 1:21:36 PM (reads: 1291, responses: 0)
This a good example of why "dynamic typing " is such a useless term.

At least "dynamic checking" (latent typing) means something concerete. But when you simply talk about "dynmaic" languages, and discuss typing, nobody really knows if you are thinking about weak type systems, run time type checking, type systems/semantics pairs you don't like (0 is not a boolean, damn it), component technologies, or about something completely unrelated like high order languages, or interactive shells. [The list above is not meant to be comprehensive...]

I think more bits are wasted yearly due to people prefering the all too generic term "dynamic languages," than we can sustainably produce.

Patrick Logan - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 9:36:03 PM (reads: 1203, responses: 0)
Delphi? ETHs Oberon-2 workstations? XDS Oberon-2 that compiles so fast it might-as-well-be incremental compilation?

Compiling fast is not the point, although it is a component of the point. The point is the programmer's *overall* experience in an interactive environment. A large component of the overall experience is the unit of work supported by a language.

Strongly typed, dynamically checked, imperative, OO languages like Lisp, Smalltalk, and Python, in my experience have a different feel by being more "manipulable" in an interactive environment. For example they are easier to build and test programs by evaluating smaller expressions and creating test data more easily.

Systems like Delphi, Think Pascal, Energize (for C++), VA for Java, etc. are very useful, but have not had the same feel in my experience. I think the language design makes it more difficult on tool developers even when the tool developers have experience with the more dynamic languages. (Energize and VA are the two in this latter category I know of.)

Patrick Logan - Re: Dynamic languages and virtual machines  blueArrow
8/27/2003; 9:40:45 PM (reads: 1196, responses: 1)
This a good example of why "dynamic typing " is such a useless term. At least "dynamic checking" (latent typing) means something concerete.

I could go along with this terminology. More to the point.

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
8/28/2003; 12:00:46 AM (reads: 1229, responses: 0)
Cardelli defines some useful terms.

I just noticed this statement in the introduction to Pierce's TaPL: Terms like "dynamically typed" are arguably misnomers and should probably be replaced by "dynamically checked," but the usage is standard."

Isaac Gouy - Re: Dynamic languages and virtual machines  blueArrow
8/28/2003; 6:59:56 AM (reads: 1162, responses: 0)
Patrick:The point is
Giving a command-line Pascal as the example doesn't communicate the point you wish to make.

IDEs that separate out the unit of work and also provide context, seem better to me as-well: working on a method rather than a file, evaluating isolated expressions rather than a file.

Perhaps statically checked languages make providing this functionality more difficult for tool developers. Certainly there are a large number of programmers who have become accustomed to larger units of work and see no particular need to change - that really makes things difficult for tool developers.

Isaac Gouy - Re: Dynamic languages and virtual machines  blueArrow
8/28/2003; 7:09:19 AM (reads: 1167, responses: 0)
Cardelli defines some useful terms
Perhaps everyone on LtU could adopt and evangelize that terminology, even if they would find it hard to agree that "From the point of view of maintainability, even weakly checked unsafe languages are superior to safe but untyped languages (e.g., C vs. LISP)."

Dan - Re: Dynamic languages and virtual machines  blueArrow
9/1/2003; 9:53:01 AM (reads: 1087, responses: 1)
Which just goes to show that Jon shares a common misunderstanding about perl. Perl is strongly typed, and even statically typed. Perl doesn't allow is restrictive sub-typing, which is a different matter entirely. It also has complex base type behaviour which includes what other languages would consider autoconversion--in most cases it is not autoconversion--but perl does not, as it's merely part of the (arguably excessively rich) base type behavior.

$foo is a scalar, and will always be a scalar, and will always hold a scalar value. It does not hold an integer, or a string, or a float, or a reference, or a filehandle--it holds a scalar. When taken in a particular context that scalar may provide a more restrictively typed value, but that does not mean that the scalar itself is more restrictively typed.

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
9/1/2003; 12:19:23 PM (reads: 1104, responses: 0)
Good point. That's why, in one of my earlier posts and in many other cases, I try to remind people that the design of the type system is just as important as whether it's weak or strong. If I explicitly allow crazy conversions to happen automatically (think PL/I) no amount of type checking will rescue me from the mess this will surely give rise to.

andrew cooke - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 5:05:49 AM (reads: 518, responses: 5)
I'm finally reading Cardelli's paper (referenced earlier in this thread). On page 4 he says "[...] LISP is an example of such a language. These languages are strongly checked even though they have neither static checking, nor a type system."

I could understand that if it ended with "static type system."

Maybe I don't understand Lisp, but I thought that the dynamic checking that it uses was based on labelling values with types. If that is the case, then it seems somewhat unhelpful to say that a language that relies on system of types does not have a type system.

In contrast, for example, Tcl is dynamically checked, but has no types (or one, which he already notes as equivalent to none).

If you don't allow Lisp a type system, then how do you distinguish between these two languages (Lisp and Tcl)? Is the distinction unimportant?

(When I was thinking about posting this here, I planned to add the rider that I didn't want to start a pointless argument about the pros and cons of Lisp and dynamic typing, as currently on ll1, but I see that's just been posted here, so I guess maybe I need to go looking for the signal in that noise... ;o)

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 5:21:04 AM (reads: 518, responses: 4)
Ah, but he defines type system to mean exactly that:

Type system: A collection of type rules for a typed programming language. Same as static type system.

andrew cooke - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 5:30:19 AM (reads: 521, responses: 3)
<strike>Where's that quote from? I keep looking through those first pages and can't find it.</strike> (hope that works - w3c.org says the strike element is deprecated... [on edit: rats!])

Ah. Thanks.

But still, how do you then distinguish between Lisp and Tcl? Maybe it's outside the scope of this paper, but it seems (to me) to be an important difference, if you're going to argue that this terminology should be used in general discussion.

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 5:58:45 AM (reads: 527, responses: 2)
I guess the distinction you made holds. The fact that we prefer to restrict the term 'type system' to static typing, shouldn't be such a show stopper. When you want to refer to a dynamically checked system, you can simply say so explicitly.

andrew cooke - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 8:09:05 AM (reads: 531, responses: 1)
My point (which I won't labour any more!) is that Tcl is dynamically checked too, from the definitions there (Tcl does not generate forbidden errors) (unless I've misunderstood). Or did you mean "dynamically checked type system"? That would be either a contradiction or incorrect, given the defintion you gave earlier (since it's equivalent to "a dynamically checked static type system").

I guess I'm being pointlessly pedantic now - I asked because I thought I'd misunderstood something (either Cardelli's paper, or the distinction between Lisp and Tcl). I agree that a standard - even a possibly not-quite-perfect - nomenclature is better than none.

Ehud Lamm - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 8:42:25 AM (reads: 542, responses: 0)
Well, a language can be statically and strongly typed, and even be type sound, while the type system is no good (e.g., the only allowed values are 0 and 1).

Isaac Gouy - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 9:36:21 AM (reads: 495, responses: 0)
finally reading Cardelli's paper
Well, it help's to re-read it a couple of times and then preface everything you write with "Cardelli's term X" - Cardelli's term 'typed'.

Many recent cross-postings between comp.lang.functional & comp.lang.lisp were misunderstandings about whose definition was being used, or ownership disputes over unqualified use of 'typed' 'type system' ...

In that paper, Cardelli didn't seem particularly interested in 'untyped' languages.

how do you then distinguish between Lisp and Tcl?
What happens if you do something like "hello"/5 in Tcl?

Patrick Logan - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 10:47:55 AM (reads: 486, responses: 4)
But still, how do you then distinguish between Lisp and Tcl?

You distinguish Lisp and TCL by their function definitions.

Lisp (and by Lisp I mean mainly Common Lisp and Scheme) define funtions on strings, others on numbers, and so on for arrays/vectors, symbols, etc. These functions were designed to expect specific types of objects and in most cases cause a failure of one kind or another if other types of objects are applied to them.

TCL-like behavior could be defined within these Lisps. Just define new functions that expect specific types of objects but provide TCL-like behavior rather than fail. Rather than fail on unexpected object types, define the rules by which those objects will be coerced to others of the expected type before applying the function.

andrew cooke - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 2:23:16 PM (reads: 493, responses: 3)
if i understand tcl and lisp correctly, you might simulate the behaviour, but the implementation would be different.

in tcl, "foo/5" (or whatever the correct syntax is) is (i believe) an operation on two strings ("foo" and "5") that would indicate an error in some way because one of the string values cannot be handled by the function. in lisp, in contrast, the compiler/runtime distinguishes between strings and integers because they have different types (typically they are tagged; they have different internal representations). in lisp, the information that is used to avoid forbidden errors is additional to the value.

since i have used neither for more than trivial programs, i may be wrong here, but that is the difference that i feel cardelli's ontology misses.

actually, i vaguely remember something about the last version of tcl (8?) moving away from what i described above to something more like lisp, for speed.

Isaac Gouy - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 3:42:31 PM (reads: 495, responses: 2)
that is the difference that i feel cardelli's ontology misses

Why do we care about the distinction you're making - is it more than an implementation detail from a 'type system' perspective? (I've no idea - this isn't a trick question).

Patrick Logan - Re: Dynamic languages and virtual machines  blueArrow
11/23/2003; 6:36:18 PM (reads: 471, responses: 0)
in tcl, "foo/5" (or whatever the correct syntax is) is (i believe) an operation on two strings ("foo" and "5") that would indicate an error in some way because one of the string values cannot be handled by the function. in lisp, in contrast, the compiler/runtime distinguishes between strings and integers because they have different types (typically they are tagged; they have different internal representations). in lisp, the information that is used to avoid forbidden errors is additional to the value.

(define saved-/ /)
(define (/ x y)
  (let ((x (if (string? x) (string->integer x) x))
        (y (if (string? y) (string->integer y) y)))
     (saved-/ x y)))

This is essentially what TCL does with types as opposed to Lisp. The difference between TCL and Lisp is / as opposed to saved-/.

andrew cooke - Re: Dynamic languages and virtual machines  blueArrow
11/24/2003; 4:59:29 AM (reads: 498, responses: 1)
Why do we care about the distinction you're making

Yes, I have asked myself the same question (Patrick clearly feels it's irrelevant). I've found three answers:

- An ontology should be sufficiently flexible to cover even marginal cases. The difference does exist, so we should be able to talk about it. Isn't everything "implementation detail"? How is this argument different from saying that everything is Turing complete, and/or that the halting problem means types cannot prove programs correct? In other words, whatever distinction we make is qualitative (and I think one of the good things about Cardelli's paper is that he's careful to make explicit these subjective decisions).

- This kind of detail is important. There is a difference between "5" and 5 in Lisp; there isn't in Tcl. That difference appears in programs - it's important to programmers. And it must be important to people with more theoretical concerns - how do we discuss the interaction between "types" and classes in Lisp if we don't have a vocabulary for the types? What about something like CMUCL, where type declarations are optional - isn't that interesting (and how would that work in Tcl?)?

- It doesn't matter :o)

Alternatively, I think you can say that from Cardelli's perspective it is irrelevant. He's concerned with static type systems and nothing else (as previous posts here have shown, perhaps embarassingly, I have little sympathy for the smug lisp weenies, but even I winced at the way he dismisses Lisp). But it is possibly, vaguely, relevant if we're choosing a vocabulary to use in discussions here, where wider issues are discussed.

Isaac Gouy - Re: Dynamic languages and virtual machines  blueArrow
11/24/2003; 4:29:14 PM (reads: 484, responses: 0)
a vocabulary to use in discussions here
Yes, whether these differences matter depends on what we're trying to do. If we are trying to say what is a 'typed' language and what isn't then maybe Cardelli's terms are fine. If we're trying to summarize the differences between Lisp and Tcl then maybe they aren't.

I've found that thinking of Smalltalk as 'untyped' in Cardelli's terms is quite helpful. Maybe it's unusual to think of Smalltalk as being both 'untyped' and 'having "concrete" types' without seeing a contradiction ;-)

Patrick Logan - Re: Dynamic languages and virtual machines  blueArrow
11/24/2003; 7:44:14 PM (reads: 448, responses: 0)
Patrick clearly feels it's irrelevant

I think the syntax of each language is relevant. TCL's makes it easy to do string processing. Lisp's makes it easy to do more general programming in the large.

I think the distinctions that TCL and Lisp make toward, say, "5" and 5 are also relevant. But the point I want to make is that this distinction is more of a style distinction than a deep theoretical or implementation distinction.