Great post!

Some thoughts:

1: completely agree. Immutability is something that should be default! I’ve taken this lesson from my Haskell courses at school.

2: A simple idea: do away with ‘em completely. They’re just causing more harm/hassle than they buy.

But thinking about it for more than a few seconds—this is a tough question – one that I feel reveal the conflict between testability and interfaces/IntelliSense/code clients.

One idea would be for classes to implement some kind of hinting towards the compiler, similar to overriding Equals() and GetHashCode() in java/c#. Question is – would it be better than public/internal/protected/private/whatnot?

A try at expressing the general problem -

• code has different audiences/masters at different times. One master is the “package close audience” – those classes using the objects internally to solve their specific issues. Another master is the unit tests. A third one is other packages—that is if the class is part of the “package API”.

Haskell solves this by making “module APIs” explicit. Modules have to declare what is visible to the outside world (default: everything). Any code on the inside is visible to all other code, alsways (in one file/module). So in Haskell there is no need to “tag” every single atom with public/private/whatnot.

In any case – simplicity will be part of the solution I am certain.

3. Yeah I’ve gone down the code-generator-road more than once being “locked into” C# for the last few years. But I don’t disregard the code-generator-road very much (but I would like better support for it inside Visual Studio .. it is kind of hackish to get it to work slick in that environment!).

One positive side of code-generator-road is that the “main language” could be kept simpler.

4. Agreed. I like pythons attempt - doctest - where the documentation of classes/methods also serve as unit test code.

5. Yeah while I do see where you’re coming from (Haskell monads etc. - been there to) - and having TDDed my way out of more than one dependency jungle myself—I can see this in the future too. But it is a distant future.

How much of this list is covered by F# ?

Please, kill this squalid language!

Echoing Matt – F# is it (IMHO)

I’m with anonymous.

It’s also about time that languages attempt to solve the problems that dependency injection addresses.

I don’t see how this can be done and would be interested what you have in mind. I know the way the Java-world addresses DI (using ad-hoc XML-configuration languages, as for example Spring does) is not really very appealing. Switching to a dynamic language would allow one to specify dependencies more easily in the regular host language, but apart from that, I don’t see any possibilities to simplify the mechanics of DI (or alternatives). I’d appreciate very much if you could elaborate this a bit more.

F# is nothing more than a complete copy of OCaml, which is derived from Caml and SML. Their pattern matching/type deconstructing is really nice!

Compiler extensibility is king IMHO. Take a look at the .Net-language Boo. It’s an enabler for productivity. And if there is one thing our industry really need, it is tools for increasing our productivity.

Fabulous post, Michael. You have awakened a variety of now-suppressed desires; please forgive the length. I want all of what you suggest (except perhaps #4; I’ve not tried it yet), and more!

Regarding #1, I’d love to see that be a pervasive principle, so much so that common objects (like List and Set) are immutable as well, requiring extra work for mutability. And that in general, all the language libraries only give you mutable things when it’s required.

Related to #2, I think defaulting to privacy would be a great start, too.

As to other things I’m after:

Something I’ve always wanted is a better focus on, for a lack of a better term, run-time self-description. I’m forever figuring out how to wedge logging, state description, and diagnostic context data in to programs in a way that’s both pervasive and not absurdly obtrusive. I would love it if a language took that seriously.

I’d also be delighted to see first-class support for refactoring, especially of APIs. I want more freedom to refactor without making giant messes for other people. I want the software equivalent of the web-server redirect baked in, so shims and adapters for old APIs are easy, consistent, and managed mostly automatically. And I’d like to be able to easily provide API users with a set of automated transformations that bring their code as up to date as possible, with notes on where they need to fix the rest.

Related to that would be serious library management. I don’t know how it is in MS-land (although based on DLL hell, probably not so good), but there are a lot of one-eyed Java programmers who have been forced to stab themselves after accidentally glancing at an explanation of how Java classloaders work (or, more accurately, don’t).

As long as I’m dreaming, that leads me to another eternal absence: a plausible story on addressing the various common use cases for a mainstream language. The reason that there are almost no Java command-line programs, for example, is because Java puts every barrier possible in the way of that. Difficult to call from the command line. Poor argument handling. Years without any easy way to distribute a runnable thing as a unit. Incredibly slow startup times. Version issues. And as I mentioned, library issues out the wazoo.

Which brings me to what I really, really want: for the language designers, from the first week, to work in a big room with a lot of devs using the evolving language to make different kinds of shippable software. Without that, I think any from-scratch language is destined to either be a hodge-podge (coughperlcough) or something that’s great only in theory—and for a strictly limited set of theories mainly based on what’s wrong with the last generation of languages.

And with a sense of mercy for your audience, Michael, I’ll stop here, as it turns out I’ve been holding things like this in for years. :-)

I’ve had this “Zero:th argument idea” floating around for some time.

When a thread of execution enters a method, it not only gets hold of argument one to N, but it also gets hold of a “namespace of types+functions”—the whole context it executes in.

For example:

void MyMethod(int a, int b) {
  // in here, we can use ANYTHING
  // for example, we can use fopen,
  // printf or whatever is available in the
  // "total namespace" at this point.
}

I’d like to call that “total namespace” the “Zero:th argument” to the method:

void MyMethod(0th context, int a, int b) {
// context available here - it is the zero:th argument
}

Much of my experience from testing comes down to what Michael describes as dependency injection – that we make available a small context to the method under test, so that we can sense the effects the method has on that context.

And assume the method will not be using fopen() and friends—something we really cannot “test us out of” in any way I can think of.

What if the next mainstream language made the Zero:th argument explicit instead of implicit? So that you had to specify which “things you were to use”? And then the unit test code could override the meaning of that context-content, just as we use dependency injection today?

One more addition to wish list: Integrate all concurrency primitives with language constructs. We don’t need N libraries/frameworks with N concurrency abstractions. IMO, this is essential to promote uniform concurrent programming.

One more addition to wish list: Integrate all concurrency primitives with language constructs. We don’t need N libraries/frameworks with N concurrency abstractions. IMO, this is essential to promote uniform concurrent programming.

It’s a bit different, but Oz ( http://en.wikipedia.org/wiki/Oz_(programming_language) ) has many of the characteristics that you list.

Looks like Clojure has most of the features you’d like to see (except of the I/O separation). Making multithreading easier ootb and playing very nice with Java are a bonus.

Two things I’ve been thinking I’ve wanted in a language for a while are:

1. left to write assigning so I can write:

(do this) (assign result) (to this); eg:

myObj.calculateNumber() => someVariable;

I don’t know, I think in left to right, so I’m constantly finding I have to Jump around my line, I write the end and then have to go back and write the start. If I could have a standard new() method as a constructor and a ==> to mean something like ‘var’ in C# then I’d love to able to write a line like the way I find my self writing them in reverse now:

MyClass.new() = => myObj;

2. I’d like my methods to be able to accept parameters ‘mid sentence’. so for example I could write a method like

public string Replace(string find)With(string replace){}

so I could write code like:

myString.Replace(“old”)With(“new”) => newString;

Cheers,

Ben.

@Ben:

You can get similar readability with named parameters:

myString.Replace(“old”, with=“new”)