Ted Leung on the air
Ted Leung on the air: Open Source, Java, Python, and ...
Ted Leung on the air: Open Source, Java, Python, and ...
Tue, 24 Aug 2004
Platforms for dynamic languages
There were lots of comments on yesterday's post on dynamic languages. I was trying to look at the implications for Python if either Sun or Microsoft decided to put large amounts of resources into changing the language in some way.
I've grown to like Python, although the thing that I like the most about Python was a bit of a surprise to me. I look at dynamic languages through the prism of Lisp and Smalltalk, with an emphasis on the Lisp side. Like many Lisp people, I like the simplicity and regularity of the s-expression syntax, and the fact that the syntax facilitates powerful macros. I was disappointed when Apple switched Dylan from a s-expression syntax to a Pascal like syntax. Sometime in 1998 a friend showed me a book on Python, and I, like many others, recoiled from the indentation based syntax without ever using it. My opinions on this have changed as I've had a chance to work with Python. I find it very easy to write, as well as easy to read.
However, there are places where I don't agree with decisions that have been made. Lack of a conscise notation for dealing with closures, rejection of proper tail call semantics, no support for continuations, no macro system, and no way to do optional type declarations (although this is slated for Python 3000, whenever that is).
While I like Python and prefer it to most of the languages that have reasonable sized communities, I am definitely still searching for a home. There are lots of folks experimenting with ideas out there, Groovy, Boo (which looks interesting except for the required static typing -- I'm interested in how they handle macros), and others. In the meantime, if the JVM and CLR push each other to include better support for dynamic languages, I'll be happy.
[00:06] |
[computers/programming] |
# |
TB |
F |
G |
16 Comments |
Boo doesn't require static typing; you can use what they call "duck typing".
Personally, I think most of the changes you're looking for are design tradeoffs that would make Python into Lisp. But there's nothing stopping you from writing a compiler that implements tail calls, or a simpler closure syntax, or macros, or even type declarations, and translates the result to Python bytecode. Heck, write an import hook and you can have it happen automatically.
You'll still get to use all the Python libraries just fine. No continuations, of course, as that requires major C-core hackery and/or threads.
Posted by Phillip J. Eby at Tue Aug 24 05:16:50 2004
Personally, I think most of the changes you're looking for are design tradeoffs that would make Python into Lisp. But there's nothing stopping you from writing a compiler that implements tail calls, or a simpler closure syntax, or macros, or even type declarations, and translates the result to Python bytecode. Heck, write an import hook and you can have it happen automatically.
You'll still get to use all the Python libraries just fine. No continuations, of course, as that requires major C-core hackery and/or threads.
Posted by Phillip J. Eby at Tue Aug 24 05:16:50 2004
Just curious: What are your reasons not to stick with Scheme or Lisp? What do you think about things like JScheme, Kawa or Sisc?
Posted by Stefan Tilkov at Tue Aug 24 09:33:00 2004
Posted by Stefan Tilkov at Tue Aug 24 09:33:00 2004
I'm also wondering what you're looking for. You like prefix notation, but not the languages that use it?
Posted by Gordon Weakliem at Tue Aug 24 11:49:31 2004
Posted by Gordon Weakliem at Tue Aug 24 11:49:31 2004
FWIW, Smalltalk makes a lot of these same compromises, and very consciously. Well, many implementations do have continuations (though I don't think it's a standard part of Smalltalk), and it has a nice closure syntax. Anyway, I think it's important to understand that these aren't simply missing features but explicit choices, and they aren't unique to Python. Some languages have made the same choices in a less explicit way, they just choose the simplest way to do things, but I don't think that's the case here.
People seem to be most creative when they are under some restriction, total freedom tends to be overwhelming. Of course, not all restrictions are good, and you can decide if Python's restrictions are constructive ones. But I don't think a complete lack of restrictions is the answer.
BTW, Boo macros seem to be a rather complex affair. I didn't study them, but from afar it looked like they were a hook into the compilation process at a pretty low level, where the compiler uses a visitor pattern, and the macros hook into that. But I guess that's inevitable with a language that isn't as syntactically transparent as Lisps.
Posted by Ian Bicking at Tue Aug 24 14:34:36 2004
People seem to be most creative when they are under some restriction, total freedom tends to be overwhelming. Of course, not all restrictions are good, and you can decide if Python's restrictions are constructive ones. But I don't think a complete lack of restrictions is the answer.
BTW, Boo macros seem to be a rather complex affair. I didn't study them, but from afar it looked like they were a hook into the compilation process at a pretty low level, where the compiler uses a visitor pattern, and the macros hook into that. But I guess that's inevitable with a language that isn't as syntactically transparent as Lisps.
Posted by Ian Bicking at Tue Aug 24 14:34:36 2004
I have heard the comment that Python lacks "concise notation for dealing with closures", but I am not exactly sure what that means.
Google found many definitions of "first class closures", but none of them had what I would find most helpful, a two part example:
1) Code the solution of a problem using the language's first class closure notation (or an ad-hoc notation if need be)
2) Code the solution of the same problem, without the closure notation, simulating the functionality with more "conventional", more "procedural" code.
Do you know of a write-up of first class closures with such an example?
Posted by Manuel M. Garcia at Tue Aug 24 17:27:23 2004
Google found many definitions of "first class closures", but none of them had what I would find most helpful, a two part example:
1) Code the solution of a problem using the language's first class closure notation (or an ad-hoc notation if need be)
2) Code the solution of the same problem, without the closure notation, simulating the functionality with more "conventional", more "procedural" code.
Do you know of a write-up of first class closures with such an example?
Posted by Manuel M. Garcia at Tue Aug 24 17:27:23 2004
Philip,
The default for Boo is that you supply types (or let inference supply them), and you escape using duck typing.
And you're quite right: I'd like to have a very Lisp like language with a Python like syntax. The problem with writing a new compiler is there'd be little incentive for me to do that atop the existing Python VM.
Posted by Ted Leung at Tue Aug 24 22:00:49 2004
The default for Boo is that you supply types (or let inference supply them), and you escape using duck typing.
And you're quite right: I'd like to have a very Lisp like language with a Python like syntax. The problem with writing a new compiler is there'd be little incentive for me to do that atop the existing Python VM.
Posted by Ted Leung at Tue Aug 24 22:00:49 2004
Gordon, Stefan,
I want a language with Lisp like semantics, with a syntax like Python. The problem with Lisp and Scheme is the fragmentation of the libraries, FFI, etc. Much as I like Lisp and Scheme, I don't really think that the communities using them are going to grow. I want to use the language, not just be smug about it.
Posted by Ted Leung at Tue Aug 24 22:04:49 2004
I want a language with Lisp like semantics, with a syntax like Python. The problem with Lisp and Scheme is the fragmentation of the libraries, FFI, etc. Much as I like Lisp and Scheme, I don't really think that the communities using them are going to grow. I want to use the language, not just be smug about it.
Posted by Ted Leung at Tue Aug 24 22:04:49 2004
Ian,
I am definitely aware that features have be omitted by design. I just disagree with those decisions, that's all.
The Boo macro stuff did look fairly complicated. Dylan was the only language I've seen that had a usable looking syntax for macros.
Posted by Ted Leung at Tue Aug 24 22:08:45 2004
I am definitely aware that features have be omitted by design. I just disagree with those decisions, that's all.
The Boo macro stuff did look fairly complicated. Dylan was the only language I've seen that had a usable looking syntax for macros.
Posted by Ted Leung at Tue Aug 24 22:08:45 2004
Manuel,
I'd be happy if Python's restrictions on lambda were lifted. If your interested in syntax that takes closure usage even further, you could look at Groovy or Ruby. I'm fairly sure you could build much of that syntax with a good macro system.
Posted by Ted Leung at Tue Aug 24 22:10:30 2004
I'd be happy if Python's restrictions on lambda were lifted. If your interested in syntax that takes closure usage even further, you could look at Groovy or Ruby. I'm fairly sure you could build much of that syntax with a good macro system.
Posted by Ted Leung at Tue Aug 24 22:10:30 2004
"if the JVM and CLR push each other to include better support for dynamic languages, I'll be happy. "
Do you mean JVM & CLR or 'Java Community and Microsoft'? I mean, are you looking for specific changes in the platform that would provide better support for dynamic languages? If so, what would those changes be? Or, are you simply saying that you hope that dynamic languages continue to make inroads in these communities?
Posted by Larry O'Brien at Tue Aug 24 23:20:47 2004
Do you mean JVM & CLR or 'Java Community and Microsoft'? I mean, are you looking for specific changes in the platform that would provide better support for dynamic languages? If so, what would those changes be? Or, are you simply saying that you hope that dynamic languages continue to make inroads in these communities?
Posted by Larry O'Brien at Tue Aug 24 23:20:47 2004
Larry,
I'm mostly interested in technical improvements to the VM, in order to provide efficient implementation of some of the features that I mentioned above (tail call and continuation support being high on my list). These kinds of changes are exactly what Jim Huginin will be working on at Microsoft.
Microsoft has been interested in dynamic languages for a while -- they showed up at OSCON 2003 to ask what features dynamic language developers needed in the CLR. This year (at OSCON) Jim (the author of IronPython) announced he was going to Microsoft. The CLR technical strategy is a multi language strategy. I also would lump the Mono folks in here because they have the same view.
Sun has acknowledged the importance of dynamic languages via the Groovy JSR, but their moves in this area have been timid. Perhaps Tim Bray will be able to get some more energy focused on this issue.
I'm looking for a marketing contest that forces a VM/platform level arms race, to the benefit of dynamic language users and implementors.
Posted by Ted Leung at Tue Aug 24 23:40:13 2004
I'm mostly interested in technical improvements to the VM, in order to provide efficient implementation of some of the features that I mentioned above (tail call and continuation support being high on my list). These kinds of changes are exactly what Jim Huginin will be working on at Microsoft.
Microsoft has been interested in dynamic languages for a while -- they showed up at OSCON 2003 to ask what features dynamic language developers needed in the CLR. This year (at OSCON) Jim (the author of IronPython) announced he was going to Microsoft. The CLR technical strategy is a multi language strategy. I also would lump the Mono folks in here because they have the same view.
Sun has acknowledged the importance of dynamic languages via the Groovy JSR, but their moves in this area have been timid. Perhaps Tim Bray will be able to get some more energy focused on this issue.
I'm looking for a marketing contest that forces a VM/platform level arms race, to the benefit of dynamic language users and implementors.
Posted by Ted Leung at Tue Aug 24 23:40:13 2004
Hi, great points.
I thought I should pop in and clarify some points about boo.
boo has ruby-like true closures (already implemented in the svn):
<example>
def each(items, action as callable):
for item in items:
action(item)
sum = 0
each([1, 2, 3]) do (item as int):
sum += item
print(sum)
</example>
and boo will have a better/easier way to define syntactic macros and attributes through ast literals (http://jira.codehaus.org/browse/BOO-95) before we reach 1.0.
Cheers,
Rodrigo
Posted by Rodrigo B. de Oliveira at Wed Aug 25 06:18:22 2004
I thought I should pop in and clarify some points about boo.
boo has ruby-like true closures (already implemented in the svn):
<example>
def each(items, action as callable):
for item in items:
action(item)
sum = 0
each([1, 2, 3]) do (item as int):
sum += item
print(sum)
</example>
and boo will have a better/easier way to define syntactic macros and attributes through ast literals (http://jira.codehaus.org/browse/BOO-95) before we reach 1.0.
Cheers,
Rodrigo
Posted by Rodrigo B. de Oliveira at Wed Aug 25 06:18:22 2004
re. efficient implementations of tail-call and continuations.
What I'm still getting used to is the proposition that these things can / should be platform issues, as opposed to language implementer issues. I read Hugunin's Iron Python paper and saw it as a call to implementers "do the fast thing when you can, do the slow thing as a special case," but I'm beginning to realize that many people see it (and, more dramatically, his new job) as being about the platform.
I would have guessed that Open Source proponents would favor a "thin VM" approach in which the abstract machine is as simple as possible and thus imposes the fewest assumptions / constraints on language implementers. I suppose the feeling is "Well, just as Hugunin showed with Iron Python, even if the platform provides a facility X that is easy to use but sometimes slow, an innovative language implementer can work around it"?
My naive take is that I'm concerned that changes in the abstract machine to efficiently support, in particular, continuations, would have far-reaching implications, either imposing overhead on all programs or involving a restructuring of the underlying "virtual hardware".
As chance would have it, I'll be interviewing Hugunin on Friday -- what should I ask him?
Posted by Larry O'Brien at Wed Aug 25 11:46:58 2004
What I'm still getting used to is the proposition that these things can / should be platform issues, as opposed to language implementer issues. I read Hugunin's Iron Python paper and saw it as a call to implementers "do the fast thing when you can, do the slow thing as a special case," but I'm beginning to realize that many people see it (and, more dramatically, his new job) as being about the platform.
I would have guessed that Open Source proponents would favor a "thin VM" approach in which the abstract machine is as simple as possible and thus imposes the fewest assumptions / constraints on language implementers. I suppose the feeling is "Well, just as Hugunin showed with Iron Python, even if the platform provides a facility X that is easy to use but sometimes slow, an innovative language implementer can work around it"?
My naive take is that I'm concerned that changes in the abstract machine to efficiently support, in particular, continuations, would have far-reaching implications, either imposing overhead on all programs or involving a restructuring of the underlying "virtual hardware".
As chance would have it, I'll be interviewing Hugunin on Friday -- what should I ask him?
Posted by Larry O'Brien at Wed Aug 25 11:46:58 2004
Ted,
Some options:
The Common Lisp version "don't use Scheme, use PLT-Scheme!" is to use Steel Bank Common Lisp. It has with it threads, sockets, and asdf-install, which lets you install new libraries with (asdf-install:install "library") when they are set up on cliki - many are.
The CLR and the JVM both have Lisps that interact with other libraries and classes. There's dotLisp for the CLR and Armed Bear Common Lisp for the JVM.
Wait for Parrot, I'm sure someone's going to slap a Common Lisp on top of that, then we should be able to use all that CPAN goodness.
Posted by Ralph Richard Cook at Wed Aug 25 11:55:09 2004
Some options:
The Common Lisp version "don't use Scheme, use PLT-Scheme!" is to use Steel Bank Common Lisp. It has with it threads, sockets, and asdf-install, which lets you install new libraries with (asdf-install:install "library") when they are set up on cliki - many are.
The CLR and the JVM both have Lisps that interact with other libraries and classes. There's dotLisp for the CLR and Armed Bear Common Lisp for the JVM.
Wait for Parrot, I'm sure someone's going to slap a Common Lisp on top of that, then we should be able to use all that CPAN goodness.
Posted by Ralph Richard Cook at Wed Aug 25 11:55:09 2004
re. efficient implementations of tail-call and continuations.
What I'm still getting used to is the proposition that these things can / should be platform issues, as opposed to language implementer issues. I read Hugunin's Iron Python paper and saw it as a call to implementers "do the fast thing when you can, do the slow thing as a special case," but I'm beginning to realize that many people see it (and, more dramatically, his new job) as being about the platform.
I would have guessed that Open Source proponents would favor a "thin VM" approach in which the abstract machine is as simple as possible and thus imposes the fewest assumptions / constraints on language implementers. I suppose the feeling is "Well, just as Hugunin showed with Iron Python, even if the platform provides a facility X that is easy to use but sometimes slow, an innovative language implementer can work around it"?
My naive take is that I'm concerned that changes in the abstract machine to efficiently support, in particular, continuations, would have far-reaching implications, either imposing overhead on all programs or involving a restructuring of the underlying "virtual hardware".
As chance would have it, I'll be interviewing Hugunin on Friday -- what should I ask him?
Posted by Larry O'Brien at Wed Aug 25 12:40:34 2004
What I'm still getting used to is the proposition that these things can / should be platform issues, as opposed to language implementer issues. I read Hugunin's Iron Python paper and saw it as a call to implementers "do the fast thing when you can, do the slow thing as a special case," but I'm beginning to realize that many people see it (and, more dramatically, his new job) as being about the platform.
I would have guessed that Open Source proponents would favor a "thin VM" approach in which the abstract machine is as simple as possible and thus imposes the fewest assumptions / constraints on language implementers. I suppose the feeling is "Well, just as Hugunin showed with Iron Python, even if the platform provides a facility X that is easy to use but sometimes slow, an innovative language implementer can work around it"?
My naive take is that I'm concerned that changes in the abstract machine to efficiently support, in particular, continuations, would have far-reaching implications, either imposing overhead on all programs or involving a restructuring of the underlying "virtual hardware".
As chance would have it, I'll be interviewing Hugunin on Friday -- what should I ask him?
Posted by Larry O'Brien at Wed Aug 25 12:40:34 2004
Larry,
On platform vs implementer: the level that VM's are operating at it is slowly creeping upwards, for better or worse. Because the VM's include things like type systems, that makes it harder to implement languages that do types very differently. When I say harder, I mean hard to make an implementation that is efficient.
FWIW, I didn't interpret the scope of Jim's job being the platform -- I was in the room at OSCON, and he said himself that he was going to be working on CLR platform issues for dynamic languages
On open source VM ideas: well the open source folks have (to date) build single use VMs tailored to their languages. We'll see if Parrot is able to reverse that trend. Dan Sugalski seems to be looking at all the right things (at least from my point of view)
Things to ask Huginin: What kinds of changes to the CLR are being proposed? Will these changes go to ECMA? What's the timeline? What are the relative strengths/weaknesses of the JVM/CLR for dynamic languages?
Posted by Ted Leung at Wed Aug 25 13:04:15 2004
On platform vs implementer: the level that VM's are operating at it is slowly creeping upwards, for better or worse. Because the VM's include things like type systems, that makes it harder to implement languages that do types very differently. When I say harder, I mean hard to make an implementation that is efficient.
FWIW, I didn't interpret the scope of Jim's job being the platform -- I was in the room at OSCON, and he said himself that he was going to be working on CLR platform issues for dynamic languages
On open source VM ideas: well the open source folks have (to date) build single use VMs tailored to their languages. We'll see if Parrot is able to reverse that trend. Dan Sugalski seems to be looking at all the right things (at least from my point of view)
Things to ask Huginin: What kinds of changes to the CLR are being proposed? Will these changes go to ECMA? What's the timeline? What are the relative strengths/weaknesses of the JVM/CLR for dynamic languages?
Posted by Ted Leung at Wed Aug 25 13:04:15 2004
You can subscribe to an RSS feed of the comments for this blog:
Add a comment here:
You can use some HTML tags in the comment text:
To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk
Add a comment here:
You can use some HTML tags in the comment text:To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
<a href>, <em>, <i>, <b>, <blockquote>, <br/>, <p>, <code>, <pre>, <cite>, <sub> and <sup>.You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk
![[Valid RSS]](http://www.sauria.com/blog/images/valid-rss.png "Validate my RSS feed"){kind=small}
