Making good programmers feel like bad programmers
clipperhouse.com
clipperhouse.com
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.
Of course I pretty much grew up in C but the difference feels larger than can be explained by that fact.
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.
The java stuff is web applications.
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.
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 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 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.
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.
When it's no big deal to stick to the framework's boundaries, or the framework interoperates well, clearly and easily with custom lower-level code, then it seems wise to use such a framework.
The latter--interoperability with lower level code--does not seem to be true for ASP.NET based on my brief experience.
It was great when I was just starting out as a web programmer and I didn't understand how the web worked. Now that I do get it, ASP.NET Webforms is a hassle at best and maddening at worst.
It was the whole square peg, round hole scenario. I would need to do something that I knew I could easily do in another language and the asp.NET solution was almost the solution I needed except to get it to work right I had to spend as much time modifying and extending it as I would have spent on a much more elegant solution in another language.