Home

News: Sun's Victoria Livschitz: "Envisioning a New Language"

  1. Sun's Victoria Livschitz, in "Envisioning a New Language," presents a lot of provocative ideas and advocates changes which, as she puts it, "require a very deep cut into the programming, execution, memory management, and threading models -- just about everything that makes up a programming language." Here are a few ideas:
    • Give the local virtual machine (LVM) the ability to act as a container for managed application code. Create a virtual machine and distributed runtime environment that in principle subsume the functionality of the application containers and middleware. While retaining middleware from an interoperability standpoint, the basic needs of distributed applications, such as load balancing, failover, remote communications, mobility of services and their containers, quality of service, and service-level management, should be embedded into a runtime environment for the language
    • Provide support for contextual programming, autonomous executable entities, and software evolution and reuse.
    • Create a set of core system-level constructs built into the language, designed to make the task of the formal codification of systems a far more intuitive process, as compared to programming in object-oriented languages. Candidates for core constructs: entity, process, organizational principle, condition, relationship, event, and rule.
    • Build a rich set of reuse mechanisms directly into the language. Three general-purpose reuse mechanisms:
      • Derivation, which specifies the rules of creation of a new metaphor by changing properties of the existing metaphor.
      • Composition specifies the rules for creation of a new metaphor as an aggregate of several existing ones -- or the direct opposite of that, the decomposition of an existing metaphor into several ones.
      • Adaptation specifies the rules of lightweight "morphing" protocol that can be used to adapt a metaphor developed for one domain to the needs of another domain, if the two are properly isomorphic.
    Obviously I'm just providing a vague sketch of some fairly complex ideas that I admit to finding a bit overwhelming. Anyone care to take all this on?

    Threaded Messages (35)

  2. Haha, this is what happens when people that don't actually know anything about programming - somehow think they do. All of the concepts mentioned are either already "in the language" or are mis-conceptions about what syntax is and how it affects semantics.
  3. a good idea, conceptually[ Go to top ]

    Every programmer has its own preferences for using patterns or frameworks. There are far too many ways, which lead to Rome. A new programming language / mechanism that stands closer to application-functionality can reduce many costs, i think.
    But traditional programmers must switch activities into more and more determinable and measurable tasks. And that is a frightened thought, isn’t is...
  4. a good idea, conceptually[ Go to top ]

    I take it you don't actually type code either, do you? It's very important that you separate your perception of programming, what's generally hard to do and what needs solving from the things that really are [hard and needs solving].

    Manager-type suggestions almost always either render quick and easy ways to type up (or drang and drop) HelloWorld applications - totally worthless - or very high-level word-masturbating descriptions on how to create generic messaging applications or hugely oversized enterprise solutions for non-existant problems (read IBM) with integration (funny really).
  5. a good idea, conceptually[ Go to top ]

    Be honest: current application development is chaos. Step into that helicopter, rise to the sky, see for yourself! Current languages are not created to automate on this scale. Than land again an continue with our work: programming applications (yes, I do program, fulltime JAVA).

    I don’t know if this particular "implementation" or "solution" of the concept is right, but as I said before, the concept is good.
  6. All of the concepts mentioned are either already "in the language" or are mis-conceptions about what syntax is and how it affects semantics.
    I can't agree with that for two reasons:

    1) She didn't say anything about syntax. She said her new language has new semantics. Ie, it has new abstractions.

    2) She mentioned that her ideas could benefit from a new virtual machine.
  7. ... and the best new lang is:[ Go to top ]

    Groovy! It's almost java, but dyamic (like all modern langs).

    Look how easy to work w/ collections.
    C#, Ruby, ObjecteC don't come close!
    Just make next Java more Groovy.
    .V
  8. ... and the best new lang is:[ Go to top ]

    Just make next Java more Groovy
    Why you don't use groovy? It's is compiled to bytecode.
  9. Ruby doesn't come close to Groovy?[ Go to top ]

    Look how easy to work w/ collections.
    > C#, Ruby, ObjecteC don't come close!

    You can't possibly be serious.
  10. The concept of a "distributed runtime environment" that sort of magically cares about the distribution of my components in my opinion seems to be a misconception. I believe ideas like this were quite popular a few years ago when someone discovered the proxy pattern and made us believe that cables are something to abstract from. However, after following this path for a while our industry more and more learned that cables are the main issue (maybe only second to persistence-mapping) to consider when developing enterprise applications. (Remember Fowlers first law of distributed objects...)

    Having said that, I still do believe that research in this area is necessary and useful...
  11. Don't forget the next quantum leap in hardware: multicore processors. The way we deal with threading, coprocesses and parallel computing is going to have a huge impact in the way we design and code, and that's not too far in the future. So it's not jut about distributed components and network anymore, there'sa whole new world opening up in front of us where we'll have some sort of distributed architecture inside a single box. Sure, we can code systems that can make use of such new concepts right now using existing tools, but are current languages best fit for that, or should we start thinking about new paradigms, tools, etc? We're risking inventing a new kind of airplane when all we have are steam engines, as far as stupid analogies go ;).
  12. parallel computing is going to have a huge impact in the way we design and code
    Multithreading in current servers isn't enough?
  13. parallel computing is going to have a huge impact in the way we design and code
    Multithreading in current servers isn't enough?
    Multithreading per se may be enough. General developer's knowledge of it may not:
    http://www.gotw.ca/publications/concurrency-ddj.htm
  14. The concept of a "distributed runtime environment" that sort of magically cares about the distribution of my components in my opinion seems to be a misconception. ... However, after following this path for a while our industry more and more learned that cables are the main issue...
    You seem not to understand what a computational grid is. Imagine a program stored in New York that must first process a petabyte file stored in Tokyo and then next process a petabyte file stored in London. The fastest way to do this is to move and resume the program to wherever its current data file is stored. Process migration also helps cycle scavenging and high availability.
  15. Got your point. I certainly believe that "moving code" might be a good idea in many situations (while I find your example a bit abstract...). However, she didn't mention computational grids in the interview...
  16. Considering that the hype languages of the moment (Ruby et al) are just putting some fine touches on the same object-orientation foundation that has been around for decades I think we're not going to see spectacular changes in software development from that direction.
    So a fundamental rethinking, an alternative to object-orientation is long overdue.
    Of course it's hard to evaluate these ideas by reading the interview since none of us has programmed using the constructs mentioned here.
    But the proof of the pudding is in the eating. It'll be interesting to see what comes out of this.

    btw imo mentioning Groovy in this thread amounts to trolling: it's not in any way as innovative as Metaphors.
  17. Considering that the hype languages of the moment (Ruby et al) are just putting some fine touches on the same object-orientation foundation that has been around for decades I think we're not going to see spectacular changes in software development from that direction.So a fundamental rethinking, an alternative to object-orientation is long overdue.Of course it's hard to evaluate these ideas by reading the interview since none of us has programmed using the constructs mentioned here.But the proof of the pudding is in the eating. It'll be interesting to see what comes out of this.btw imo mentioning Groovy in this thread amounts to trolling: it's not in any way as innovative as Metaphors.

    I agree with you about object-orientation. However I don't see how anything she says in the interview even touches on problems like the logical complexity of consistent change in decentralized systems. Four wheel objects, each in its own VM is fine, but what do they do? Why are they in four different VMS? What problem does she want to solve? Does she talk about high availability or about something conceptual? I fail to see what this "mataphor" stands for. All of this sounds a lot like some of the agent based systems froth. But maybe she onto and simply fails to explain it in this interview. I don' know.
  18. Considering that the hype languages of the moment (Ruby et al) are just putting some fine touches on the same object-orientation ...
    I agree with you about object-orientation. However I don't see how anything she says in the interview even touches on problems like the logical complexity of consistent change in decentralized systems. Four wheel objects, each in its own VM is fine, but what do they do? Why are they in four different VMS? What problem does she want to solve? Does she talk about high availability or about something conceptual? I fail to see what this "mataphor" stands for. All of this sounds a lot like some of the agent based systems froth. But maybe she onto and simply fails to explain it in this interview. I don' know.
    You explained it realy well. It's hard to say if she really have some idea, but nobody understand what she is trying to explain. I'm very sorry (and I hope it will not fire back to me), but this article is definitelly stupid.
  19. The article is stupid if you are a sceptic.
    I'd say the article is unsatisfying; it offers too little information for the reader to get a clear mental image of how this is going to work.

    Object-orientation once also started with very philosophical, vage theories.

    She'll have to be very brilliant and have a lot of resources to pull this off.
  20. ... I don't see how anything she says in the interview even touches on problems like the logical complexity of consistent change in decentralized systems.
    ...
    All of this sounds a lot like some of the agent based systems froth. But maybe she onto and simply fails to explain it in this interview. I don' know.
    You explained it realy well. It's hard to say if she really have some idea, but nobody understand what she is trying to explain.

    I think that the basic difficulty is that what is described in this interview is not a finished solution, nor even a solution-in-progress. The subject here is ideas-in-progress. These are ideas that may eventually lead to a solution, and as such they are (to me) quite interesting.

    The distributed environment part is not because you want to distribute your software, but because you want not to care about where the software is running. As long as the service-level is met, it doesn't matter where the service is running, be that on your desk/lap-top, a server in the basement, or a computer cluster on another continent.

    As for the agent-like quality, I imagine that the idea here is that the individual pieces (agents) will be conceptually simpler than the current giant enterprise systems. But you'll still need somebody to envision how these pieces will go together. There's still hard work, but perhaps new software environments can make it more manageable.
  21. Woo what a discussion! I would like to add my few ideas too.
    First I used to program (from ASM C/C++ UNIX and win32 /.NET CORBA J2ME JavaCard, J2SE, J2EE...)
    In my opinion the basic idea of the new language as I understand it from the paper is to replace middleware in a common language.

    Well I would like to take the sample of Java, who tried years ago to make the famous bytecode independent of the OS/hardware putting this moto into a new language. I remember it was so cool. But, I am still not sure when I want to run an EJB Server on a Smartcard. Ok this point is obvious! Let’s go for a little more subtle one. Let’s say you want an authentication algorithm. Sometime it will run on a server sometime it may run a smartCard. Do you believe you can reuse the same class file in both environments? For the one which are not sure the answer is unfortunately no until you want o achieve usable performance (well until we can really bundle a the 8 cpu core with dozen of Go of RAM into a smartcard, I remember some people telling me that according to the so famous law within at maximum 3 year this well be possible (well it was 6 years ago)).

    Now, do you really thing we can achieved better result with distributed computing? Do you think that time-constraint environment have the same rules as non time-constraint environment? Do you think a transaction-oriented protocol work the same way as a non transaction protocol, do you believe using a GPRS link is the same as using a 1GB Ethernet link, do you think using Bluetooth is the same as using Wimax ? Conceptually and according to the over famous osi layers yes! I still have some doubts.

    Well, in my mind most of the solution is choosing the right tool to handle the job. And also most of the time different job belongs to different people. Ask an ASM specialist to design a communication protocol; I am not sure it's efficient. So the main idea to put all this stuff into a grandiose language!

    This "one size fits all" vision looks a far away idea... maybe people should first try to enforce the good use of already existing things instead of creating new things that solve problems which do not exist yet.

    (Disclaimer: it is my own opinion, there is no offense)
  22. It's hard to say if she really have some idea, but nobody understand what she is trying to explain.
    An understanding of grids, cycle scavenging, or utility computing surely gives an appreciation for her ideas.
  23. "But maybe she onto.." was supposed to read "But maybe she's onto something..."
  24. Sounds interesting !!
  25. Oh my...[ Go to top ]

    Holy cow! Reinvent the whole computing field and solve the so-called "software crisis" through a few all-embracing abstractions ? I sure hope she'll let us know when she's done.
  26. Victoria wrote:
    I guess I'd like to finish with a famous quote from Fred Brook's classic work, Mythical Man-Months: "Plan to throw away one prototype. You will, anyhow."

    I believe it's time to step back and consider the first 50 years of computing as one gigantic prototype. If we had the courage to start over, we could build a new software creation and execution model to address the software engineering challenges of the 21st century, such as distributed processing, autonomic computing, and software evolution -- natively, within one conceptual universe. The programming language is a great place to start.

    This idea should be tempered by Fred Brooks' second system effect where the second system tends to be disastrously overdesigned.
  27. Monstrosities[ Go to top ]

    This idea should be tempered by Fred Brooks' second system effect where the second system tends to be disastrously overdesigned.

    Quoting from the definition:
    second-system syndrome is when one is designing the successor to a relatively small, elegant, and successful system, there is a tendency to become grandiose in one's success and design an elephantine feature-laden monstrosity

    I'm sorry but we seem to already have the feature-laden (not bin-laden) monstrosity so let's leave the poor Brooks out of this :-)
  28. Give the local virtual machine (LVM) the ability to act as a container for managed application code. Create a virtual machine and distributed runtime environment that in principle subsume the functionality of the application containers and middleware. While retaining middleware from an interoperability standpoint, the basic needs of distributed applications, such as load balancing, failover, remote communications, mobility of services and their containers, quality of service, and service-level management, should be embedded into a runtime environment for the language

    This is actually what we are doing at Terracotta (http://www.terracottatech.com/) in our Distributed Shared Objects (DSO) technology.

    But instead of inventing a new languague (or introducing new APIs), we are using the APIs and bytecode instructions that we already have in Java and instead extending their semantics, in order to have Plain Java code, written for a single VM, work correctly (and scale) in a distributed environment.
  29. DSO[ Go to top ]

    This is actually what we are doing at Terracotta (http://www.terracottatech.com/) in our Distributed Shared Objects (DSO) technology. But instead of inventing a new languague (or introducing new APIs), we are using the APIs and bytecode instructions that we already have in Java and instead extending their semantics, in order to have Plain Java code, written for a single VM, work correctly (and scale) in a distributed environment.
    I can understand the analogy you are trying to make but, unless I have missed something, DSO does not yet:
    - subsume the functionality of application containers
    - subsume the functionality of middleware
    - support mobility of services and their containers
    - support application-level quality of service and service-level agreement
    - solve the software crisis
    - address a problem space somewhat similar to the one described in the interview
    - bring world peace

    But except for these small bits, you're right, DSO has it all solved already thanks to the magic of distributed "synchronized" blocks :-)
  30. DSO[ Go to top ]

    Right. I guess I deserved the sarcasm.

    We do not do (and will not do) all that. But we do parts of it (and thinking in this direction) and I was merely pointing out that I think that we are on the right track.

    I should have been more clear on that, sorry.
  31. Please ingore, I'm not serious[ Go to top ]

    Someone has recently saw The Matrix. What does this anything to do with a VM?

    Regards,
    Horia
  32. no another language[ Go to top ]

    I can program in: ASM, C, C++, Java, Perl, Forth, SImula, and Pascal.

    I can do the same program in assembly than in Java, This is because I can program, The programming language is supposed to help you to express your program, to facilitate and expedite the development (it will take 20 times longer in assembly than in java), but both programs are and act the same.

    People still confounding programming with a PROGRAMMING LANGUAGE. This is a problem that I can see with the Java People (I was ask in interviews what is the difference between HashMap and HashList). I need to hold my tongue and do not ask what is the loading of 75% as default parameter. Hey they never took computer classes (why, they never took computer science classes, is Java).

    Thanks
  33. I just doubt it[ Go to top ]

    The point is that a whole new programming language will not change much. No silver bullet! Some DSL (Domain Specific Language) Creator might help.
  34. ...and how much of it is education?

    I'm in complete agreement that substantial improvements, at least from a theoretical standpoint, could be made in programming languages. However, I'm not convinced it will make that huge of a difference because not enough people will be able to effectively use them. Think about it, how many developers do you know what effectively use the existing OO capabilities in languages like Java?

    I'd like to point out the C++ has substantially richer support for OO programming that Java does, yet Java has been much more successful at encouraging OO programming.
  35. erlang..[ Go to top ]

    As someone mentioned at Lambda the ultimate thread about this article, she seems to be describing erlang.
  36. food for thought[ Go to top ]

    not that this academic stuff will have any effect on my daily tasks for years to come if at all, but it is very interesting nonetheless to consider some out-of-the-box ways of looking at fundamental challenges in development. even in the daily sense of things, the concepts victoria presents could positively affect what developers are doing by opening the mind some.