Today’s Thought

By Brian Hurt | Published: July 8, 2010

Great tools are what you get when your language sucks.

The tools are developed to work around short comings in the language itself. If the language didn’t have those short comings, you wouldn’t need the tools, and they wouldn’t get developed. The best language would be just fine with just notepad and a compiler. So bragging about how great the tools are for your language is bragging about how your language sucks, and needs significant amounts of help to make development in it tolerable.

No related posts.

This entry was posted in Programming Language Punditry. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • http://blog.barrkel.com/ Barry Kelly

    With respect, that’s an asinine thought. Smalltalk has had some of the best tools for the longest times, but that’s because of the unity and regularity of the language and its runtime, not in spite of it. And conversely, C++ has historically had poor tools not because it’s a great language – frankly, it sucks – but because its poor design made it so hard to tool.

  • http://blog.barrkel.com/ Barry Kelly

    I want to add further. Tools are developed when there’s a market for them. Primarily that means that the language has adoption. Every large application, no matter what language it’s written in, can benefit from certain generic kinds of tooling: code completion over modules, documentation popups in the editor for API calls, code navigation based on symbols invoked (but that isn’t fooled by naming coincidences, like simple-minded – or even lexically aware – greps). These all help because large apps don’t fit in every team member’s head in their entirety. Tools that provide these basic functions add to any language that represents itself as text. (But graphical languages cannot be programmed without tools.)

    Bragging about the tools for your language indicates that (a) your language has an excellent design and is easily tooled, or (b) your language has widespread adoption and is a mature and reliable fixture in the programming landscape, or (c) both. Of course, the lack of tools doesn’t necessarily mean the opposite.

  • http://muellerware.org/ Patrick Mueller

    It’s not just large applications that benefit from those sorts of generic tools that Barry mentions. Even small applications can benefit from these tools if you have a large library of code to deal with. Python is a good example here; I often write short little python programs, but constantly refer back to the web-based doc to figure out what functions to use. Which is, frankly, painful.

    I will, on the other hand, admit that I’m a reformed Smalltalker.

  • http://d.hatena.ne.jp/jartur/ jartur

    LISP in many of its forms and, say, Erlang have Emacs with great integration — one of the best tools available. LISP used to have things like OpenGenera — something modern tools can not even come close to for other languages. But dare you actually say that LISP is that awful?

  • http://slobodanblazeski.blogspot.com/ Slobodan Blazeski

    Not true, Lisp and Smalltalk are perfect counter examples.

  • Scot

    I won’t comment about Lisp or Smalltalk as I’ve never really used them, but Java and some of Java’s surrounding technologies are perfect examples of this. I wouldn’t want to code much in Java without an IDE, but JVM languages like Groovy are such an improvement on Java that I can happily use nothing but a text editor and a command line.

    I remember when Java Server Faces came out there were comments about how tooling would eventually be created that would take care of all the painful bits. After using it without the tooling I’m never going back to JSF if I can help – even if it does have tooling by now (no idea if it does or not – there are easier technologies to use). So it’s not just languages that tend to suck if they need heavy tooling to be of any use, frameworks that need tooling have a tendency to suck as well.

    Question for the Smalltalk fans – how easy is Smalltalk to use without tooling?

  • Michael O. Church

    Interesting thought, but I actually disagree strongly. I think that the strength of tools reflects on the size and power of a programming language’s community. I don’t think that tools are built to overcome shortcomings of the language so much as they are built to increase the quality and productivity of the programming experience, which can be improved dramatically no matter how great the language is.

    For example, Ocaml and Haskell are awesome languages, but as compiled languages, you still have nasty build-system problems (Makefiles) that emerge on large projects… and this is in no way a fault of the language itself. Hence, tools are built to deal with this.

    On the comment that a great language is “just fine” with an ordinary notepad, I’d agree, but Haskell is “just fine”, of course, with a notepad and compiler; but the fact is that even when the language is awesome, it’s not so awesome as to make better tools unnecessary.

    Of course, the languages that tend to have the best tools right now are those that have the largest communities, which tend also to be mediocre languages (Java, C++). That’s not because of an causal link between poor language and great tools, but other factors entirely– namely, the enormous number of mediocre programmers who are afraid to learn newer and better languages.

  • http://perl.scaffidi.net Hercynium

    Just my $0.02… Perl is an oft-maligned language – and sure, it sucks in a lot of ways, but the thing that keeps me coming back to it over and over are the quality of the tools. With CPAN as the keystone, one can install just about any of these tools as easy as can be.

    examples: Devel::NYTProf, Perl::Tidy, Perl::Critic, local::lib, CPAN::Mini, perlbrew, Devel::REPL, all the Test::* stuff, and many many more…

    The fact that the language itself is so insanely malleable also tends to be a big plus – many of the add-ons I use give Perl some very convenient and advanced capabilities.

    examples: Moose, Devel::Declare, Try::Tiny, perl5i, and so on.

    So, one could argue that Perl sucks big time, but IMO, its tools more than make up for it, and I end up feeling deprived every time I code in other languages.

  • Steven

    Congratulations on finding a counterexample to a generalization. You may be the first ones in all of history.

  • http://kablambda.org/blog Tom Davies

    You really need some examples to indicate what you are thinking.

    Take Java, which has great tools (e.g. Intellij IDEA’s refactoring support). This tools is made possible by Java’s static typing — which I’d argue is a great language feature. Are you arguing that Java has a deficiency which makes refactoring tools necessary?

  • http://p10q.com Tom Harada

    I agree with the claim. But only with tools that solve problems which the language can also equally solve by being improved. There are some problems that both tools and language can solve, but with unequal levels of effectiveness.

    Language improvements that make up in concision what they might lack in flexibility and specific, thorough solving of the entire problem (compared to tools) are worthwhile.

    But yeah, I think the claim of the post is correct. Language tools and language are somewhat inversely related because they compete over the same space. But the other point (as perhaps some make) is that language tools also open up possibilities for new design, etc. So there’s really two competing relationships.

    It’s sort of like a general and a scout. Really good scouts might be signs of a weak general. I think that’s Brian’s point. But it is possible to have both be really good in certain circumstances. Or to have both be really bad, etc.

    Also, when people think about examples and counterexamples, it’s maybe important to remember that ‘language’ is a very fluid concept. It’s maybe better to think about ‘language’ in terms of a language hierarchy (or hierarchy of abstractions). There are little languages in syntax, in high level design, in modules, in interfaces — everywhere there is abstraction. It’s language all the way down. So if your tools (which also form a language set — mostly for solving the higher-level problem of doing actual development logistically) are top heavy that means there’s an inelegant quality to the hierarchy. You’ve got a tree branch which is unusually large. Sometimes this isn’t bad (a huge set of libraries like CPAN, etc.) — but arguably it prevents other parts of the tree from properly developing, etc.

  • Angelo Pesce

    I do understand the spirit of this post (i guess) and i do think that indeed many tools are bad patches to fundamental flaws. A big example would be debuggers. I would any day prefer to use no debugger in a interactive language (live coding) than a debugger in a statically linked one (c++). But i would love even more both, an interactive langage with a graphical debugger i.e. A good langage supports tools, like c#. A bad language doens, and still neds them to be half decent, i.e. C

  • ChriS

    A blog post with an interesting perspective on languages v.s. tools
    http://osteele.com/archives/2004/11/ides

  • Categories