

Making good programmers feel like bad programmers - mwsherman
http://clipperhouse.com/blog/post/Making-good-programmers-feel-like-bad-programmers.aspx

======
wglb
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.

~~~
jacquesm
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.

~~~
barrkel
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.

~~~
jacquesm
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.

------
tarkin2
This pretty much sums up why I'm sometimes hesitant to use frameworks: should
my problem evolve past the boundaries of the framework it can become more of a
pain to use the framework than the raw constructs.

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.

~~~
LargeWu
The real problem with ASP.NET is that the abstraction it provides is
completely divorced from the way the web actually works. It tries to provide a
stateful way to program, and it is completely driven by events. Sure it
exposes the response and request, but trying to use those in anything but the
most trivial ways is a complete mess

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.

~~~
cartano
You should check out ASP.NET MVC. No postback, viewstate, and other junk, just
request and response.

------
mgrouchy
Around 2 years ago I started a job as an asp.net developer and this was
exactly how I felt. It felt like everything I wanted to do and every problem I
wanted to solve had a solution that just didn't quite fit.

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.

------
tvon
Abstraction and convenience layers still need to be learned to be used
properly. If you're used to doing things yourself and you shift to using
helper tools, there is going to be a learning curve. The idea is that it pays
off in the long run so it's worth learning.

------
jff
Remember, the solution is _always_ to add another layer of abstraction!

~~~
DougBTX
"You can solve any problem by adding another level of abstraction, except
having too many levels of abstraction"

