The Blub Paradox also applies to editors/IDEs | Hacker News Reader

The Blub Paradox also applies to editors/IDEs

osteele.com

19 pointswmf22 comments

It seems to apply, but in reverse. I never really grasped what IDEs were for till I saw someone at a conference editing Java code in one. Now I get it: they're for generating the macroexpansions that your source code consists of in such languages.

I suspect IDEs are like Bail Bondsmen. It may be a good sign if you don't know what they're for.

Probably not the worst way to explain it. Now all you have to do is convince yourself that seeing the expanded code is a good thing, and you've just sold yourself completely on Java.

PS: It definitely can be a good thing, depending on your needs.

I suspect IDEs are like Bail Bondsmen. It may be a good sign if you don't know what they're for.

Do you have a special satchel full of these apt analogies? I I envy your analogical ability.

Peter piper picked a peck of alliteration, eh?

A good IDE, with good autocompletion features increases productivity a lot, plus it makes much easier for begginners to get started.

When you first starting, you don't know much of the API/features of a language, hence IDE features such as "Autocompletion", "Open Declaration", "Find References"... are extremely useful.

One of my frustration with working with Python is that none of the IDEs are that good, and methods/language features are not commented that well.

In the Java world, Eclipse + lots of code commenting = makes it insanely easy to get learn new APIs. Also, IDE's help a lot with debuging, running external tools, some automation...etc.

IDEs usually have higher learning curve (vs. a normal text editor), but make it up with the features that they provide.

Autocompletion is only possible in languages that are excessively verbose. In a good language, the next token requires thought to produce.

There are different kinds of IDE autocompletion. Sometimes it is for generating the verbose statements in a language like Java. Sometimes it is a way of having API documentation integrated into the editor.

so its still vi + copy/paste into the top level? (or have you given in to the dark seductions of vim)? ;)

Basically, except that on OSX you can just drag stuff from one terminal window to another.

What was it Guy Steele said in a video "my stone tools don't run out of batteries". So true.

Autocompletion of long variable names allows for easy use of very descriptive names. Something similar to tab-completion in a CLI is very useful.

Vim does this (control-N control-P)

I should really learn more Vim.

So you create a new function with every token?

Autocompletion is also for finishing a single token. If you have tokens more than four letters long, it's worthwhile.

It can also be great for exploring new libraries.

There you go, dissing IDEs again. A lot of us like emacs!

I think they are also for fixing other people's bad code.

If you diligently refactor as you go, by replacing repeated code with functions or macros, you don't need a complicated tool to do it.

However, if you have inherited some code where the preferred reuse method is copy paste, this is much more risky. You need to be sure that you got all of the cases and that you don't inadvertently break anything. This is yet another reason to start a startup instead of getting a "real job" :).

Eclipse does more than just autocompletions. It also helps you navigate your code for example.

Nevertheless, I think programming without completions sucks. I think most non-IDE editors also try to offer completions, though. It's one reason I can't stand Rails: all that passing around of parameters in Hashes is fundamentally not autocompletable.

In MS Visual studio, for C#, with a plugin called resharper, macros can be astonishingly effective. For programming competitions I developed a fairly extensive set of macros, and they've been pretty good to me. Unfortunately, they can't quite do everything I want them to, and that has me looking at Lisp.

An area where I suspect IDEs could be helpful even in higher-level languages would be for TDD. In my limited experience, I have found TDD to involve a lot of "plumbing" that a computer could easily do for me. It would be nice to write a test that uses an undefined function, press the run key, and then have my cursor blinking next to a generated function definition ready to go.

This of course begs the question of how applicable TDD is to high-level languages (or even in general... I have my reservations). Time for me to stop pondering and get down and dirty :-).

http://steve.yegge.googlepages.com/transformation

Skip to the bottom section if you're in a hurry.

Spot on. It would seem Tools are critical to a software factory, Languages to software innovators.

Noting the the reference to Lazlo: http://www.openlaszlo.org/ "OpenLaszlo is "write once, run everywhere." An OpenLaszlo application developed on one machine will run on all leading Web browsers on all leading desktop operating systems." Heard this before?

Reply on news.ycombinator.com