Registered: Sep, 2005
Re: Programming as Typing
Posted: Jul 9, 2006 1:02 PM
> Another example of noise vs. reality: people are always
> saying that there are still more COBOL and FORTRAN
> programmers out there than any other kind. But when was
> the last time you saw one, much less talked to one? By
> that metric, they don't exist. But apparently there are
> tons of them.
Well ... I used to use FORTRAN and I'm still a programmer, so I suppose that makes me a "FORTRAN programmer". :) But seriously, folks, I wrote my last significant piece of FORTRAN in early 1990. My current languages are Perl and R, and I'm in the process of learning Ruby.
> I think the problem is that while many programmers
> understand that programming happens in the mind, and the
> code itself is just an artifact of the process, outside
> the field, the code looks like it's what you're doing. (An
> understandable perception, since the code is the core
> deliverable). So if it's about the code and not the mental
> process behind the code, it makes sense that you would do
> whatever you can to produce the code as fast and as
> cheaply as possible, and to discard anything that appears
> to hinder the creation of code. From this follows the
> logical ideas that coding is typing, so you want to see
> people typing all the time, and that 10 people can type
> faster than one person so if you can hire ten Indians
> cheaper than one US programmer, you're going to get a lot
> more typing done, so you'll get big economic leverage.
> In reality, study after study indicates that success
> comes from who you hire. This suggests that programming is
> not a mass-production activity where programmers are
> replaceable components.
You're using the kind of "noise" arguments you've decried earlier in your post. "Study after study indicates that ...", etc. So ... I showed you a "FORTRAN programmer", you show me the "study after study". :)
> This is probably why I keep fighting with the
> static-dynamic language debate, because it has the same
> feel to me. You can come up with all kinds of reasons that
> static checking is a good thing, until you have an
> experience programming in a dynamic language where you are
> vastly more productive than with a static language. But
> that experience defies the logic used to back up the
> reasoning behind static languages.
That depends on how you measure productivity. I've been programming a long time, and the two main factors in my productivity have always been familiarity with the application domain and familiarity with the programming environment. Throw in a new domain or a new language/OS/IDE/whatever and I slow down to the level of "average programmer" very quickly. But I'm equally productive in a static or dynamic language, other factors being equal.
> Here's another one. I believe that "details matter,"
> and that noise really does wear you down (studies show
> that noise makes you tired). What I'm talking about here
> is visual and complexity noise. So I was disappointed
> when, for example, Ruby turned out to have begin and end
> statements, and that it uses "new" to create objects.
> These are all noise artifacts from previous languages,
> required to support their compilers. If your language
> creates all objects on the heap, you don't need to say
> "new" to distinguish between heap and stack objects (like
> you do in C++, which was mindlessly mimicked by Java). And
> everyone always indents their code, so you can use
> indentation to establish scope. Besides the fact that I'm
> justifying the design minimalism of Python here, when I
> put these ideas out I will probably get a lot of perfectly
> reasonable rationalizations about why this is the best way
> of doing things. And without questioning the fundamental
> principles upon which those arguments are founded, those
> arguments will be pretty airtight, even if they really
> come down to "I'm used to that and I don't want to think
> differently about it."
I think once any programmer has learned macro assembly language, Lisp and Forth, he or she will always be disappointed in any other language. At least that's the way it has been for me. I started programming with a fairly decent macro assembler. But until you made this comment, I never really understood *why* I prefer macro assembler, Lisp and Forth.