Mapping language style to ancillary issues?

It would be of interest to me to see a codification of the impact language style has on ancillary tools. For example, I want my IDE to show me wherever a given variable is used. You can try to do that with just textual searches, but if the language allows runtime aliasing then you are presumably going to have a more difficult time of statically generating the relevant information about variable use. Or, you are going to have to restrict the breadth of information generated. (IntelliJ actually does do something along these lines for Java, although I suspect it doesn't follow aliasing chains?)

I'd guess that language styles are more-or-less amenable to particular such issue. I guess I see this as a way of guiding myself and others towards understanding another angle on why e.g. functional programming matters, or mutable state is evil, etc.

Comment viewing options

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

State of art evolving too fast...

In no particular order:

Tools are evolving quickly, so you're looking at a quickly moving target. For the most part, the things that you would think would be difficult for tools (aliasing, unhygenic macros, unhygenic aspects, textual inclusion, certain aspects of subclassing) are still difficult, but becoming less so every year.

Variable use in Java is an easily solvable problem, since variables can't be aliased (there is no 'address-of' operator, and calls are all by-value). Value usage in Java is the difficult problem, since values can be aliased to different variables.

IntelliJ doesn't attempt to follow aliasing chains in any way in it's static analyses, refactorings, or searches. For searches, what's normally done is to search for where any variables of a given type are read or modified, and take a worst case assumption that any appropriately typed variable could alias any other appropriately typed variable. For idiomatic Java (post 1.4), this is mostly safe and effective, doesn't produce too many false positives or false negatives.

I've managed to get through this entire response without ranting about the use of the word 'ancilliary' to denote the programs most working developers use for the majority of their workflow. Guess the SSRIs are working...


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

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.

Lanuages vs. lanuage

(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

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!

Assumptions of ancilliarity limit your thinking

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 :-)