Envisioning a New Language: A Conversation With Victoria Livschitz

Metaphors attempts to address four topics essential to software development that are traditionally handled outside of the programming language. The first is support for distributed runtime environment, which I just talked about. The other three are (a) support for contextual programming, (b) support for autonomous executable entities, and (c) support for software evolution and reuse.

I am not sure what to make of this.

Comment viewing options

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

20 Configurations

A system that consists of just five standard components, each available in four commercial implementations, produces 20 configurations to test, certify, and support.

Wouldn't that be more like 4 * 4 * 4 * 4 = 1024 combinations?

20 configurations

would'nt it be 4^5 (five standard components) ?

20 Configurations

Oops, that's what I meant: 4 * 4 * 4 * 4 * 4 = 1024...

Where the visionary light comes from

I am not sure what to make of this.

Stop breathing for a short moment. Take a long breath thereafter and thanking god for not working in the SUN.

When I'm reading interviews like this I feel the strange euphoria of New Economy. Techno-babble but no clear concept - thousand metaphors are flowering. Nature, processes, autonomy, context-sensitivity, reactivity, little children are playing on the beach. Everything still under control? Yes, it's for your own security. The SUN of California is shining bright and burns my brain cells. Hey, where is Dijkstra if one needs him most urgently?

Being visionary myself I see a gigantic flow of money attracted by an eternal fire burning for the humanitarism of technology. The light in the center is intense but you can see a glowing cloud of desktop icons and animated gifs if you don't watch to straight into the flame. "Hey it's all pop!" The hippies around me are laughing. But soon they are gone, vanished in a screen running a showcase presentation...

Every now and then you have t

Every now and then you have to publish such articles; it's a business & marketing rule. Curiously, even one answer agrees with this:
A number of senior software people know that we are in deep trouble and that we don't have a get-well plan, but it's not profitable to talk too much about it -- except as a sell point for the new miracle product of the day.
For some reason, the miracle product is never educating developers better, or raising salaries, etc. However, a better language is always welcome. (Clarification: I like better languages. But they (or ,mostly their libraries) happen to be a great vendor lock-in tool, too.)

You can find the word "formal" in every other paragraph. It sounds like a higher level declarative layer where you can specify some things (my understanding is very fuzzy) about large components.

I am totally lost on the "open-file" process. I have no idea if the detection of the isomorphism is manual or automatic, and why the VM designers care (what kind of mistake could the VM designers have done??)

It's really a lot of handwaving and it's a fake interview (the interviewer is 100% satisfied with her answers; no follow-up questions, etc.) It's just a way of publicly stating that they're doing something.

Had a hole in my pocket and lost my silver bullet

Translated into English, here's how I read that part of the interview:

A number of senior software people know that we are in deep trouble and that we don't have a get-well plan, but it's not profitable to talk too much about it -- except as a sell point for the new miracle product of the day.

Q: Do you [have such a miracle product]?

A: [Yes.]

Ha!

This is hilarious.

What Livschitz says, it has been said many times in LtU.

What Livschitz says, it has been said many times in LtU. There is a software crisis, because too much time is spent in debugging. Cleverer compilers and richer languages are needed that can be used to express a variety of requirements.

What?

I have delivered projects, in Java, on which I've never needed a debugger once during development. It's a question of discipline and learning techniques that support the development of robust code. That's a people issue, not a technology issue. New programming languages won't stop lazy/poor programmers churning out crap.

As for requirements, programming languages express solutions, not requirements. Requirements need to be expressed in a way that makes sense to non-programmers; a programming language is not the right tool.

Just because your not using a

Just because your not using a debugger does not mean youre not debugging.

What???

As Li said, just because your not using a debugger, doesn't mean your not debugging. So either your trying to tell us that you don't use a debugger to do your debugging, in which case your argument is a red herring, or your trying to tell us that you have written programs that were bug free and hence didn't need to be debugged. Unless those Java programs were non-trivial, I find it rather hard to believe that they were bug free. If they really were bug free, then you are perhaps the best programmer in the whole world (congratulations). Since everybody that writes code that contains bugs is either a lazy programmer or a poor programmer (or perhaps both), it must mean that every other programmer in the world is either a lazy or poor.

Okay, perhaps I'm being somewhat hard on you, but I'm trying to make a point. (No hard feelings? Good.) I can understand what your are saying (or at least what I believe you are saying). Yes, it is true that with some discipline, a programmer can write better code, but even then a programmer is bound to make mistakes, and what is wrong with developing a language that helps you along the way? Why should you work alone? Why shouldn't my compiler tell me when I make a stupid mistake (or maybe I'm the only one who finds myself making such mistakes). Now, I'm not a good programmer, as I haven't been programming long enough to be good (I just graduated from college last May!), but I'm sure that even after 20 years of programming I will still mix up what I'm trying to write between my brain and my fingers, and I would like tools that would help my own discipline and techniques out a little.

Problem solved via Language Support. True or False?

I think that Nat is saying that the software crisis will not be solved with better runtime debuggers, cleverer compilers, or languages that can better express requirements. I think that not needing a Java debugger is his representative example.

I think Nat is saying that this software crisis is a cultural issue rather than a tool support issue.

I agree with that viewpoint, for whatever that's worth.

I've been programming professionally for about ten years, twenty three years for fun. In my opinion, if MSDN and the Sun Java tutorials both included a section on test driven development in their prerequisites, much of the software crisis would disapper.

They do talk about it but in

They do talk about it but in their own style.

Why does it have to be either

Why does it have to be either/or?

I recently started asking my students to write unit tests and to use assertions. I don't see why this goes against also using the type system and the various modularization technqiues provided by the programming language. If better abstractions and/or abstraction mechanisms are found, I will be glad to have them.

To sum up: it can be a people problem and a language problem.

Yes

...if MSDN and the Sun Java tutorials both included a section on test driven development in their prerequisites, much of the software crisis would disappear

I don't know if it would disappear, but at least it would help out a lot. Note, that I'm not saying that we shouldn't be disciplined, in fact I'm a big fan of test driven development, however I also believe that it's worth having a language help me out (when it doesn't get in my way). For example, a type system that tells me when I pass an argument of the wrong type. I guess what I was trying to say is along the lines of what Ehud said: Why can’t it be both? Certainly test driven development can find the same types of errors that a strong type system can find (and more!), but the type system can find them sooner and point them out better. This allows me to be more productive (even if only a little more productive), and this is a good thing because its all about productivity in the end, isn’t it?

So, we need both. I need the programming language to tell me right away when I make a stupid mistake that it knows about, and I need test driven development to help me find the stupid mistakes the compiler has no way of knowing about.

Perhaps I make a mistake. I suppose that Nat may have been simply pointing out that compilers can't solve the problem, where I thought that he was making a much stronger statement: languages can't solve the problem and we don't need the language to help solve the problem if we are disciplined enough. For that I apologize.

Given enough monkeys you will eventually get shakespear

Does not mean they understand what has been created. It is difficult not to get allergic to an overwhelming amount of techno babble.

However, the favorite metaphors given (begin, do stuff, end) lacks support in most programming languages - well, it smells like "grammar" and is even given in some kind of ebnf form ... I bet a language with a syntactic extension mechanism could do just that.

Vaporware?

Google doesn't bring up anything about this "Metaphors" language, other than this interview and pointers to this interview. If it were a real research project you'd think they'd have a web page.

Reverse inheritance

Is there something somewhere else in the PL world like the
Class Vehicle abstracts class Car idea?

Victoria Livschitz says that this "may be extremely useful in a variety of scenarios.", but I can't think of any of them, probably because I dont understand what that would be good for (unless it is something like "declare an interface and then declare that an existing class is-a this interface").

Type-class generalization

John Meacham's Supertyping Suggestion for Haskell seems related

(Btw, something like what your quote describes is already possible,
e.g. in Haskell, making a type an instance of a type class is separate from defining the type,
also Scala's views seem to perform a similar purpose wrt traits)

Sather

Sather has this, for the exact reason you mention.

A and B

Two things come to mind. One is a way of getting around the lack of structural typing. The other is adding new methods to some group of already existing classes.

Erlang

Didn't she use a bunch of buzzwords and other obfuscations to describe what Ericson already did with erlang?

Erlang again

Funny, just yesterday I read another masterpiece from Sun, and thought - isn't it just an ad-hoc bug-ridden half of specification of Erlang? :-)

Well, Erlang's formal specifications do not appear in the results of a simply-minded Google query (though I heared they exist), so I put a smiley.

Erlang semantics

I would suggest that you take a look at Lars-Åke Fredlund's PhD thesis for a formal semantics of Erlang.

Core Erlang

You might be interested in Core Erlang - the linked page includes the "Core Erlang Language Specification" and "An Introduction to Core Erlang".

I'm not seeing any formal semantics in those papers, but since they describe a fairly small functional language core, the semantics are fairly "obvious".

Or Mozart/Oz

Oz (http://www.mozart-oz.org/) was the first thing I thought of when reading that article.

I was struck that the most "exotic" language she mentioned in that interview was Java and the others were Fortran, C and C++. That's setting the bar pretty low. I suspect that she's a whiteboard architect rather than an experienced developer and hasn't done much of anything with any modern languages.

She also seems not to have read End-to-End Arguments In System Design by Saltzer, Reed and Clark.

Take one:

A few key ideas seem to be a conceptual universe for thinking about software development rather than thinking about computation. Livschitz sees the software development universe as context as opposed to computation. The goal seems to be to express both context and computation. Most languages have a computational semantics.

What I make of Metaphors

  • One or more JVM-like virtual machines, capable of working as a distributed VM. Hot-replacable and migratory processes spread among the VMs.
  • Either support for embedded domain-specific languages or a souped-up interface description language capable of acting like a modelling language. (Probably the latter, although hope springs eternal.)
  • Fancy class manipulations.
  • An event-driven coding style.

As with the original hype around Java, it's potentially an interesting platform, but there's nothing really new there.

It makes complete sense to me

Java was the tool for a decaying platform incompatible with the mainstream to grab a piece of the market. They did it well, they got a large piece.

.NET was Microsoft stab in return. Solved some technical shortcomings, defused any possible bomb with the "VM" issue, and is getting some of that original piece back. Even letting the developer choose his own syntax flavor.

Metaphors is Sun's next strike in this (unequal) war.

Don't get me wrong, I'm not saying there are no technical merits. Just that these plans originate, develop and make sense business-wise, not programming-language-wise.

I've been checking this site for some time, first time I post. Really cool.