Lambda the Ultimate

1. A syntax for defining enumerated types. This syntax provides linguistic support for the Typesafe Enumeration pattern.

2. An automatic conversion from primitive types to their corresponding reference type wrappers. This conversion facilitates the integration of generics into the language, and reduces inessential clutter.

3. Enhanced for loops allow convenient iteration over collections, without the need for an explicitly defined iterator. This reduces the need for boilerplate iteration code and the corresponding opportunities for errors.

4. Static import. A mechanism to allow the use of unqualified constants.

Useful links: The JSR document describing these proposals in more detail http://jcp.org/en/jsr/detail?id=201 and the discussion on The Server Side.

It's interesting to note how these changes are mostly cosmetic alterations to syntax rather than deeper semantic changes such as adding blocks. There's an interesting wiki page I started a while back that offers some interesting proposals that would really shake up Java.

Has anyone here found design problems with the Nice language?
(Nice was discussed a while back)

This is hardly enough and way too late to save Java I'm afraid.

The 4 features are superficial alterations that make no real impact on the expressivity, complexity or type-safety of the Java language. Significant additions would have been blocks, higher-order functions (perhaps through syntactic sugar for the reflection API's Method class), default arguments to methods to reduce the need for method overloading (as seen in Nice), Python-style raw strings to simplify usage of regular expressions and an aggressive purging/refactoring of the standard APIs.

Understanding programming language "success" in terms of disruptive technologies seems a useful step.

A complementary step is understanding programming languages as brands.

Given the continual feature accretion in mainstream programming languages (and corresponding complexity), language choice degenerates to brand choice. I had a good experience with a previous model of language x so I feel comfortable choosing the new model language x when it's available. Maybe I justify this by saying that the new model language x has all-the-latest-features (but then so does brand y!).

That seems to explain the existence of VB.Net - VB.Net is so different from VB6 (and so like C#) that it can only be an appeal to brand loyalty.

Of course it is because all languages are immaterial in .NET as one aggainst another. I wrote an essay once that virtually everyone in the .NET community applauded. I've said it a million times and I'll say it agian: Languages in .NET *only* exist to express the semantics of the CLR and BCL. It's the Runtime and the Base Class Libraries that *are* .NET. Choosing a syntax and getting 60% more verbosity in the case of VB.NET is a matter of choice and one thats largely irrelevant. So it's not that VB.nET doesn't resemble VB, it's that .NET does not resemble Win32 programming.

Next thing we'll see, in Java 4 is everyone asking for a revamp of the syntax- how about a space for a method call! [ :p1 :p2 | code ] for blocks!

So why is there a VB.Net? Because VB is a brand. (As is C++, as is Java, ...)

It's funny to watch the Sun/MSFT war heat up into Java/C# "future featuritis" battles, when the real benefit of these virtual machines is the libraries that people continue to extend them with.

I do most programming in JScheme now because I can easily use all the libraries for Java in a more accomodating environment like Scheme.

I doubt much software at all will be written in Java or C# (or VB.NET) in a few years. They're too complex for most tasks. More and more people are realizing the benefits of simpler languages, it is just a matter of time.

I was going to use Sun Labs Ace Project as an example of a code generator, but now they seem to be calling it a new Java-based language...

The question I have for ACE is, what are its bounds?

Some simple languages are so because they are not as expressive, they simply cut features.

Other simple languages are so because they are just as expressive, or more, just using simpler axioms.

One of the biggest software systems created are ERP-systems, and all of the successful ones are data-driven. That means that the meta-data and the rules/commands/... are stored as DATA.

What we need is a language that make it easy to create data-driven systems, but where we still get benefits from a compiler like type-checking

data-driven systems & compiler like type-checking
Is there some technical issue preventing this?

The question I have for ACE is, what are its bounds?
The 4GL problem again?

That would be essentially any member of the family of strongly-typed functional languages: Standard ML, Objective Caml, Haskell, Concurrent Clean, Oz, Erlang... One of the features of these languages that I think is underappreciated is their rich data structuring and DE-structuring (pattern-matching) facility. It's perhaps noteworthy that in "Essentials of Programming Languages" one of the first things the authors do is implement a nice abstract data type facility, with pattern matching, for Scheme, their chosen pedagogical vehicle. No such effort is necessary using Scheme's cousins.

Which is the whole point of Scheme, of course: to provide a small set of mechanisms in which to build all the rest with relatively little effort. That's why Scheme is a good language for that book as well as for SICP.

The 4GL problem again?

Potentially. I don't know the range of ACE's expressiveness or how ACE supported dropping into Java.

Patrick, hopefully you of all people know that I wasn't being critical of Scheme or the EOPL authors' choice to use it, but rather pointing out why I was recommending other functional languages to Mattias. The development of interpreters and compilers is a heavily data-driven task, which is why EOPL recommended itself as an example and why the authors chose to add the data structuring/destructuring macros that they did to Scheme. It's a testament, I think, both to the power of those constructs, and to Scheme's elegance, that that was all that they felt necessary to add to Scheme for EOPL's purposes!

Learn the fundamentals, don't just jump to the popular language or the one that has the one feature you desire, whether it is objects, concurrency, pattern matching, backtracking, etc.

(Neither was I trying to suggest we all program in Scheme: I'd love to see more people become even familiar with at least one language in your list. They're all worthwhile.)

I hate that we're "training" the present legion of programmers to be "object-oriented" and not much else. It's like training U.S. citizens to be "consumers" without educating them in the constitution, how we got it after 20k years of cultural development, and how we might make it last beyond the present "war on terrorism".

We are just on the early edge of losing legions of programming and engineering position in the U.S. to less expensive regions of the world. I have no problem with that, but a so-called "advanced" society has to be able to innovate to avoid stagnation.

Innovation comes from boldness and deep understanding. Whether that innovation is applied to the attaining the ideals of the "American Dream" or simply getting to the next generations of information technology.

(Apologies for the drawn-out political analogies.)

I agree and disagree-). I agree that it is technically feasible for VB6 to sit on top of the CLR and I disagree both that it is practical or useful (and the rest of what you said)-)

Knowing the internals of VB6, I know that the internals of VB6 are completly and utterly implemented in COM. That was good when the underlying object system was COM but real bad now-) Why? Because the COM binary memory layout and the CLR's memory layout are totally different. My slides on COM Interop on my web site go into the many differences but there are big huge differneces: COM and other legacy code sits on top of unmanaged memnory heap, they use v-table binary "contracts", on and on, whereas the CLR is managed and thus the CLR chooses a layout for types and objects at runtime targeted to the specific machine. And there are dozens of other differences you can check out if you are interested.

What's the point? The point is that all COM "stuff" has to go through the COM Interop layer in .NET to transition the stack from a unmanaged stack to a managed one (they exist in totally seperate worlds - seperate processes, etc). During this transition, which is a minimum of 30-40 x86 assembly instructions, types get marshaled, identies have to be presereved, and the the processor has to go through a "transition thunk" to go from one stack to the other. Long story short: COM Interop is fraught with problems (see this for more detail. So with this mess, the VB team made the same logical choice that the VS team made: it was impossible.

Then, addressing your other points that "about C# (assuming they implemented VB.NET in C#) that makes one create a language thusly.", I totally disagree. And this "Sure, VB6 would've had to undergo some minor changes to use the .NET libraries, but it wouldn't have to have become what is now VB.NET.", even more. This doesn't reflect the understanding of the CTS and CLR that I have. Let me explain. Microsoft, in their design, took all that we expect a modern programming language to do and absracted most of those notions into the CTS (The Common Type System). The CTS defines at the metadata level what types are and logical constructs. The model is an OO one, for better or for worse. More so, the model for the BCL libraries are totally OO, that's how you use them. So, of course, it was chosen that C# should best reflect this model. C# is the CLR language, defined along with the CLR, that best expresses the CLR and CTS semantics. There were choices made also for developer productivity: that most people were far more productive with one OO programming model versus dozens of models for programming to Win32 before.

Back to VB.NET. In order to express the CLR and BCL best, VB.NET had to change radically to be an OO language that expressed the CLR and CTS semantics and allowed easy access to the BCL. It made sense and it makes sense now.

As to how that plays with the standard VB6 developer, time will tell. I agree with you and others, that this is not the programming model that many VB "seat of the pants" coders know or are currently productive in. Thats why there has only been about a 8% conversion rate. But a lot of that is when developers are faced with the learning curve of the CLR and BCL, and that the majority of examples are in the lingua franca of .NET, C#, just say forget it, I'll just use C#. The rest who don't want to learn those skill sets stay with VB6.

No strongly-typed languages are not the answers, unless they can compile during run-time. If you look at data-driven system, 95% of the domain-dependent stuff can be handled by data, but sometimes code is needed. So actually the problem is how can you have compilation during runtime and still type-checking (the standard answer for this is script languages, but has anyone seen big systems created using script-languages :-)

In many ways, probably COM + script languages is one of the attempts to solve this problem, however no one can build a big system that should be used for 20 years on top of something that always changes (like MS's stuff).

I think the problem is that programming languages are designed by programmers who think that the biggest problem in the world is writing a compiler or creating smart data structures. (It might be an interesting problem to solve if you required that there should be at least 100 people designing and writing the compiler :-)

Functional programming languages have a long and time-honored history of blurring the distinction between compile-time and runtime. Indeed, to this day, Lisp is often still described as an "interpreted language" because it is interactive, in spite of the number of implementations that don't even bother to include an interpreter. Some languages, e.g. Oz, explicitly include a compilation API.

If you look at data-driven system, 95% of the domain-dependent stuff can be handled by data, but sometimes code is needed.

Sure, but this leaves open the question as to whether this code needs to be generated at runtime or not.

So actually the problem is how can you have compilation during runtime and still type-checking (the standard answer for this is script languages, but has anyone seen big systems created using script-languages :-)

Well, if you have a strongly-typed language with a compiler available at runtime, then you obviously have type-checking, so perhaps I'm still missing something. Regardless, there's more than one way to skin this cat: you could use the language to implement a rule system as an interpreter, then write a compiler from the rules to bytecodes and interpret the bytecodes. Or you could write a self-applicative partial evaluator for your target language, and then apply the partial evaluator to your rule interpreter, thereby deriving a rule compiler. Etc. etc. etc.

Maybe model-based computing is the answer:

http://www2.parc.com/spl/projects/mbc/