Home

Jon Udell: Languages and environments

Languages and environments have always been fellow travelers. At some point they'll begin to part ways. Domain-specific languages will continue to flourish; they're the future of programming. But they'll target fewer environments.

It's easier to learn languages than to learn environments. So while these things have tended to proliferate in pairs -- each language carrying around its own environment, like a turtle with its shell -- my argument is that over time the environments will tend to consolidate.

Jon offers a couple of entertaining examples, but the fundamental point is worth thinking about.

Until quite recently the general view was the exact opposite of what Jon is arguing: languages, it was argued, are going to be consolidated. Remember Java as the cure all solution to software?

The proliferation of programming languages, domain specific and otherwise, isn't news for LtU readers. It is a good sign to see it mentioned on Infoworld.

By Ehud Lamm at 2005-04-05 15:55 | General | other blogs | 7335 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Semantic Esperanto

my argument is that over time the environments will tend to consolidate.

There is some ambiguity about what he means by "environment".

I get the sense that he means VM + libraries. For languages sharing VM + libs to work though, I think all the languages in a given environment would have to be semantically equivalent at some base level (cf. dotNetification of pre-existing langs )

I think this is a pretty big challenge to what most LtUers mean by "language design".

By Marc Hamann at Tue, 2005-04-05 17:13 | login or register to post comments

I agree

There is some ambiguity about what he means by "environment".

Right. I think this is really more subtle than it seems. It's not just about PL level semantics (though that's an important part of it), it's about the variety of possible software architectures.

I think all the languages in a given environment would have to be semantically equivalent at some base level

This is an important issue when environment becomes synonymous with library and/or class hierarchy. It's a bit less problematic on the VM level, since VMs can support a wider variety of options than spcecific PL choose to expose.

By Ehud Lamm at Tue, 2005-04-05 17:46 | login or register to post comments

Not all VMs are create equal

It's a bit less problematic on the VM level, since VMs can support a wider variety of options than spcecific PL choose to expose.

Maybe, with a well-designed VM.

Existing VMs seems to play better with some children than with others, and any VM is likely to optimize better for some scenarios/paradigms than others.

By Marc Hamann at Wed, 2005-04-06 02:12 | login or register to post comments

This Sounds an Awful Lot Like...

...Jean-Claude Wippler's Minotaur. The current incarnation of JC's thinking along these lines is vlerq, which also consists of an easily-embeddable virtual machine with scripting and/or native code on top and C-based dynamic extensions. Definitely check it out: as usual, JC's onto something good.

By Paul Snively at Tue, 2005-04-05 18:08 | login or register to post comments

Ruby on Rails

It's not clear to me that Rails could easily be ported out of Ruby. One of the reaons it works is its ability to dynamically map object slots to SQL queries. In a language which doesn't permit overriding slot access and update operations, that's going to be quite ugly.

So it could be hooked in to Python or CLOS, but probably not Java or OCaml.

By bts at Tue, 2005-04-05 20:17 | login or register to post comments

Hibernate

bts: So it could be hooked in to Python or CLOS, but probably not Java or OCaml.

On the contrary; Hibernate uses CGLIB to build dynamic proxies to do precisely that. On the other hand, because Java is statically and explicitly typed, you still end up writing mappings by hand or using one of the various tools available to do so. The combination of dynamic typing and reflection seems to sit at a very interesting local optimum with respect to these kinds of integration tasks: they can be made almost completely transparent, and often there's such an enormous performance differential between the systems being integrated (e.g. business logic vs. persisting objects in a relational database) that the fact that the tool is dynamically typed and often reflecting (i.e. looking up) things by name at runtime is just noise in profiling.

By Paul Snively at Tue, 2005-04-05 21:29 | login or register to post comments

It is a question of value system

Although you can have dynamic proxies in statically-typed languages, it doesn't graft neatly into the value-system of the programmer. Statically-typed environment value static checking. A lot of test strategies of statically-typed language are designed around assuming that type is already checked.

Here is a concrete example.

While the following code fragment 

customer_name = a_recordset["customer_name"]
is fine for most dynamic language practitioners, it is not quite good enough for static language people, who prefer
customer_name = customer_records.customer_name
where the customer_records is a typed recordset, and customer_name field is statically typed.

This type of practice is kind of like writing key parts of a Lisp application imperatively. It jars the reader.

By Chui Tey at Tue, 2005-04-05 23:52 | login or register to post comments

Dynamic proxies as implemente

Dynamic proxies as implemented in plain Java (resp. CGLIB) are typed as the interface (resp. the class) they proxy. So, it grafts neatly into the value system of programmer: Hibernate-persisted objects are plain old java objects (POJO), no specific code/ancestor/interface required.

That being said, if you want a Java example of painful simili dynamic features, go and check (Lazy)DynaBean, PropertyUtils and BeanUtils. (don't forget that in order to use that, the vast majority still has to manually box/unbox scalar values)

By Christophe Grand at Wed, 2005-04-06 21:07 | login or register to post comments

"Frameworks" et al - terminal terminological ambiguity

I don't think Udell's article is an appropriate LtU topic; it's far too vague and his terminology too imprecise. Udell uses the term "environment" in a general sense (all inclusive). He's trying out various "frameworks" (RoR, .NET, etc.). There's considerable slippage in his terminology since he also includes "Perl's Class::DBI" module in his comparisons. While the combination of Perl's Class::DBI + MayPole (or one of many other Perl frameworks) might be considered roughly equivalent to RoR or .NET, he doesn't say that.

So in the end he's merely trying various software tools and, while we all appreciate his work, I honestly don't know why this is an LtU topic.

By xeo_at_thermopylae at Tue, 2005-04-05 21:18 | login or register to post comments

LtU doesn't work this way

Lambda deals with issues directly related to programming languages, and programming language research. However, we allow ourselves moderate forays to bordering issues like programmabiliy and language in general (from the FAQ).

LtU isn't just for discussing research papers. We strive to include as much of the field as possible. We discuss mainstream languages, and obscure languages. We talk about formal calculi, and about informal speculation etc. etc.

In my opinion Jon's article was worth taking a look at. That's why I posted the link. You are entitled to think it isn't all that interesting, and that's fine. I am not interested in all the topics raised here, but as long as some people in the community think something related to PLs is worth discussing, that's ok. That's why we have quite a few editors, with different interests, experience and point of view.

By Ehud Lamm at Wed, 2005-04-06 09:45 | login or register to post comments