Lambda the Ultimate

The angle I'm looking at it from is that of the language designer, not the tool designer or user. Well, I mean: I want the language designer to be informed by what the tool designer, and thus the end-user, has to live with once the language is defined.

So while aliasing in some language might seem powerful, useful, and cool, there are down-sides to it. Ditto mutable variables. Ditto syntax choice (Lisp macros vs. Java macros). Etc. So while tools are getting better at some pace, if the languages in use didn't kinda suck in this way or that way then wouldn't the pace be even better?

If people designed languages to make the 'ancillary' (JetBrains isn't owned by Sun) tools easier to make, and to make more accurate and precise, I think that would be nice (assuming it doesn't result in an otherwise yukky language).

If end-language-users could concisely see what pros/cons there were to any given language's design, that would perhaps help advance the overall cause of making high-quality systems.

These issues were discussed here on LtU many times, of course. I don't think there can be any good formal mapping, because both languages and tools evolved to quickly.

However, I seem to recall some review articles that may be relevant to your query, so I suggest searching the archives. I particular, I think there was a discussion of psychological factors that provided classifications that might be trarnsferable to the tool-design domain you asked about.

(I'll go searching, thanks for the reminder!)

Languages plural as a universe is changing rapidly. Ditto tools. However, a given language singular probably doesn't drastically change that fast, and there are probably some core relatively immutable truths about the design (e.g. Erlang doesn't have mutable variables). So if there were:

1) a table of "design choice" to "ramification", that would be language agnostic. A classic example would be concurrency choices. This particular mapping table could get into various flame wars (static vs. dynamic typing) but any individual could use their own preferred version of the table.

2) a table of "specific language" to "design choices" listing the core things about a given language, and is updated over time as new releases come out.

Obviously then you just "join" the two tables. If (dreaming) this sort of perspective on trying to understand a language were common, then the language developers could maintain their Atom / RSS / Semantic description of their language and folks could use it for doing compare / contrast exercises.

I just wonder if this kind of information is talked about a lot in FAQs and on sites like LtU and on comp.lang.XYZ threads, and it would perhaps be of use for it to be boiled down into a canonical and useful format?

Like I said, I don't think this is possible. The interaction between different design choices is simply to extensive. But you are welcome to try... Let us know if you have a proposal we can look at!

I didn't mean to gripe, really, and you do seem more receptive to feedback from tool vendors/users than many. You just hit a hot spot for me, obviously, and nearly triggered a bit of a preach.

Nonetheless, it's worth noting that if you don't assume that tooling is an afterthought, some really quite interesting possibilities open up for a language designer. For instance, your question is phrased as to how language features can enable better tools. That's good, but incomplete, in that it assumes a pure producer-consumer relationship between the language and the tools. A more complete question would include the possibility that the existence of tool technologies can feed back into the design of the language, improving it. Smalltalk is the canonical example of this, but it's design leveraged the state of tools in the mid '70s. Less obvious is how the existence of fast compilation, application servers, and refactoring IDEs have fed the evolution of Java and the JVM. In the medium-term, I imagine we'll see this feedback in terms of module/versioning/dependency-management systems complex enough to merit a full-featured content management system, type annotations systems that more-or-less assume that a powerful static analysis engine is helping you maintain them, and probably language features I can't even imagine that leverage tool technologies for requirements tracability, documentation, and testability.

I don't mean to paint a picture that is restrictive other than trying to get at what I think is the heart of something - the choices a language design made. As in, Java doesn't yet have closures, so that means it is harder to do X, Y and Z with tools or anything else. People who don't know enough about PLT perhaps won't ever have realized this limitation.

So in a way I'm looking at this as a way to advertise the qualities and benefits of things like Erlang or Haskell etc. over the usual suspects of Java/C++/C#.

It could also be used to work "backwards" - say I want to develop telecomms software and I've never heard of Erlang (as if). I could go to the list of features and then see what languages support them.

Sorry if I'm being totally unable to convey what I see in my head about all this :-)