Item — HN Reader

The problem starts before the leaky abstraction. It is putting a bad or mal-fitting model over a problem to make it easier for non-experts to work with the tool.

This is a commonly-made mistake and comes in the form of using a GUI for large documentation project that is really batch underneath, putting a nice GUI on a commercial application that is high-throughput when done on green screen or equivalent, using a big hairy IDE when vi or emacs will be higher throughput, using a mouse when the keyboard is demonstrably faster.

Seems like we need a good treatise on how adding features or layers weakens rather than strengthens a tool. This article shows one of the perils.

1 comments

Second that. I'm absolutely amazed at how in-productive I am in a java/eclipse environment vs straight C, vi and make. It's like I'm continuously scanning either the documentation or some obscure error.

Of course I pretty much grew up in C but the difference feels larger than can be explained by that fact.

Perhaps you are writing different kinds of code in each.

For example, when I'm writing C, I'm usually just using the standard library and maybe a couple of OS routines. It's especially the case because I'm usually writing C in the context of a compiler, which is as close to a pure function of input to output as most programming gets.

On the other hand, when I'm writing in a higher level language, I'm tackling bigger problems and using far, far more third-party code. That's where the occasional documentation lookups and odd errors come in.

You are absolutely right, when I'm writing in C I write dataprocessing code, usually elaborate filters and pipelines of filters.

The java stuff is web applications.

Well, Eclipse's project manager is great for Java. For C I'd much rather use just a straight text editor - IDEs just get in the way.

C + emacs/vi is much faster than C + Eclipse, but C is always going to be faster to write than Java just because Java has so many more layers of abstraction that require so many more lines of code.

I don't understand this one, shouldn't the higher level abstractions require less code, rather then more? If not, why use the abstraction?

It's the difference between optimizing for lines of code written vs. lines of code maintained. Many Java patterns exist so that when you need to make a change, you can change it in one place and have it propagate to every place you've used that abstraction. This often means more lines of code in total, because you effectively have to put hooks into every place you're likely to change.

Whether or not this is a good tradeoff depends on two things:

1.) How much work will be spent in maintenance vs. how much will be spent writing the original program.

2.) How good your guesses are as to how the program will end up changing. It does no good to add lots of hooks and abstractions if those hooks are in the wrong places.

Most of the "Java sucks" vs. "Java is the only sane language" battle comes from people not understanding that their answers to the above two questions are not likely to be the same as someone else's answers to the above two questions. For startups, it's basically a given that your guesses on how the software will change are wrong, and therefore the layers of abstraction that common Java style encourages are just wasted. Java really does suck for startups, unless you're using a platform where it's the only option (eg. mobile or IDE plugins). But for large in-house IT departments, the vast majority of work is maintenance, and it's Somebody Else's Problem if the software doesn't quite fit requirements exactly. Java makes a lot of sense in these environments.

It's the difference between optimizing for lines of code written vs. lines of code maintained.

It seems odd to me to read that. From what I've seen of it, Java seems to be hard to maintain. The capacity for abstraction is limited, leading to repeated or generated code in multiple locations. To make matters worse, hooking in to things requires that they be designed to be hooked in to. Contrast Common Lisp method combination.

I grew up with Java + IDEs and now work primarily with C++ + vim, and my experience is the opposite. I feel that I'm much more productive with an IDE, as long as the computer is fast enough to support it (not always a given; Eclipse/Netbeans/IntelliJ are pigs). I waste far more time switching between vim and xterm to run builds than I did hitting F5 in Netbeans. And I just didn't make syntax errors in Java, because the IDE would instantly flag it when I did and I'd fix it immediately, while they still happen occasionally in C++. I also spend far more time switching between Code Search windows than I did when I had type-aware autocompletion.

I suspect it's more that you'll be most productive in whichever environment you know best. I spent 3 years in Java IDEs; I've spent 2 years doing JavaScript/Python/C++ dev in vim. Given another year, they may reach parity.

You mean you were making syntax errors all the time :)

The IDE fixing it for you made the price of not knowing the syntax of the language you are using small enough for you to not bother learning the language properly.

Once you really grok a language syntax errors are mostly gone, that's for the learning phase not when you start writing serious sized blocks of code. Sure, everybody forgets a quote or a comma every now and then, especially when switching languages. But in a compiled environment without an IDE the cost of a syntax error (one more ect cycle) is too expensive to go through so you really spend time learning the language.

The "I suspect it's more that you'll be most productive in whichever environment you know best." is very true, but once you know then equally well I wonder which will win out.