| |
Todd Lehman wrote in message ...
> I'm talkin' about really actually poor programmers -- people who are no good
> at it now and never will be, for whatever reason, no matter how hard they try.
> Usually, they're not trying, but that's another story.
OK, I'd class those as incompetent rather than poor. Not that I'm pedantic at
all.
> Heck, who would? :-) I don't know if you misunderstood what you thought I
> meant I said to write, or if I misspoke, but I never meant to imply that Perl
> was the right tool for every job. Certainly not.
Most likely, as I'm good at misunderstanding things like that. It sounded to
me as though you were tending towards saying not-Perl is bad, which is not
cool <tm>.
> up of both experienced Cobol programmers and recent graduates, and Cobol wasn't
> really the right tool for the job (let's say it was *significantly* not the
> right tool) then you've got the wrong people.
I guess my point is that a lot of the time I have little control over the
team members, and what control I have seen is more of the "who does what"
than the "out, out, damned spot" type. Similarly, it's not often I've
been involved in a project where we have free choice of tools. Sure, we
can pick between the two or three packages that the company already uses,
but it would be very rare to have the project owner willing to buy a
completely new toolset unless the existing ones were incapable. Look
at the number of sites where COBOL is still the best choice, simply because
of the skills within the company and the need to integrate and maintain
the code.
I mean, yes, I'd love to work somewhere where I was with a bunch of competent,
enthusiastic team players with great management backing (but they turned me
down :) Being able to buy a new enterprise development toolset for each
project would also be neat, but I think that last is strictly fantasy.
> If a different tool is much more appropriate, then you find different people
> who can work with that tool (or retrain your current people...)
I find that hard to grok from a business perspective. I guess because I've
mostly worked on projects that last less than 12 months, so 6 months at the
start to learn the details of a new language has always seemed quite steep.
Then again, the shifts I've made have been quite large - C to Delphi to Jade
to Forte, each one a bit of a leap in paradigm as well as syntax. So a
shift from, say, Delphi to C++ Builder like I've just done is something I'd
feel happy doing in a couple of weeks.
> I was thinking more of assembly with pre-existing libraries. Not too difficult
> to do OOP in assembly either, but it takes a lot more discipline and doesn't
> come out very readable.
I guess you're more of a code purist than I am - I get tangled up in the
software life cycle thing which says "not very readable" is identically
equal to "bad code". I suppose because I've maintained so much of it :(
> The poor programmer may get a nice head-start by using built-in stuff, but
> will quickly be crushed under the weight of his/her own disciplinary and
> attitude shortcomings, producing code that either doesn't work or works poorly.
Sure, give anyone a project they're not competent to complete and they'll
stuff it up. Some people just have very low levels of competence :) But
I guess I associate your attitude towards assembly with other attitudes
that make their holders often very hard to work with. The "every clock
is sacred" one, and "memory costs a million dollars a meg" also. What
costs money these days is people. An hour of my time is currently worth
about 32MB of DRAM, if you want to look at it that way.
> To me, spaghetti code goes far beyond a 50-line procedure which just happens
> not to have gotos all over it. Spaghetti code can be a poorly designed API
> strewn about across 20 modules, with poorly lain out layers and functions that
> leapfrog the layers to take shortcuts because of the original poor design.
Yeah, but that's bad design, which for most programmers means they've either
been taught badly (or not at all), or they're not being supervised properly.
Even the worst people I've worked with have been able to do "fill in the
blanks" programming adequately. And I know that some people, no matter how
they try, just can't seem to grasp the basis of software design (how to do
it, that is). But then, even *I* struggle at times :)
> I agree that procedural languages (Pascal, etc.) make the traditional kind of
> spaghetti code (as seen in BASIC and FORTRAN) harder to write. But at the
> next layer up, they don't do much to help avoid spaghetti code there.
That's where some of the more integrated toolsets have tried to go, with the
"code wizards" and drag'n'drop features. And to some extent they work - even
a moron learns quickly that they will be penalised for attempting to redo
somewhat that's built in to the language. So the design layer is where more
poor programmers get to express themselves these days. Unusable GUI's,
command line utilities that make C compilers look simple, client-side data
filtering, you name it.
> Heh heh, OK, maybe that's not good advice for most shops. It *is*
> extremely difficult to hire bright and talented people.
Tell me about it :) It's why even idiots like me are working as overpriced
"consultants" instead of permanent jobs. You get the competent programmers
in to keep the job on track, and use what you can get for the bulk of the
project. Same things as Larry did.
> I think there are plenty of (too many :-) places out there which aren't on
> the leading edge of things and where it's OK to just slog along like it's
> any other 9-5 job and quality isn't critical. That's where the average
> programmers belong, IMHO.
Hate to say this, but most places are like that. Not only do they reward
that behavior, they punish anything else. One of the reasons for the high
mobility of geeks, IMO.
> I think bad programmers are worse than no programmers.
Aha. That's probably the root of our disagreement. I think that software
is more reliable than people in many jobs, even badly written software.
At least software tends towards systematic errors, where people make
random ones. And face it, who really wants a job carrying sales slips
round a department store?
> Bad programmers don't do anything but *slow down* progress. (Maybe that's
> my working definition of a bad programmer.)
Maybe you've seen worse programmers than I have. Even **** eventually produced
something that worked, albeit slowly and with way too code. But it meant we
could leave him doing his small bit, and write the rest of the programs. It
meant we got the overall job done a little faster than otherwise, even if when
he left I simplified his code by an order of magnitude.
> > [...] The unfortunate result is the necessity of choosing either to
> > be widely read, or to be widely unintelligible. [...] The correlation
> > between this and computer language is presumably self-evident. [...]
> The saddest thing may be that some don't even make the choice consciously or
> realize that they have a choice.
It's actually quite scary when I think about it like that. Although you do get
the damnedest people who do know they've made that choice. I met a career
corporal last night who said essentially the same thing. In much shorter words :)
> I had to read it once first to parse it, then a second time to comprehend it,
> and a third and fourth time to grok it. I looked up 3 words.
Thank you for making the effort.
> All too many times. It's been *quite* enjoyable in the cases of people who
> I considered mentors, but I didn't always inherit good code.
<g> And, as you say, the worst thing is when you inherit crappy code from yourself.
> I believe that perfection (or perfectibility) is an illusion, but that it's
> worth it to know the difference between bad and good and great, and use some
> of each with moderation, as appropriate.
Ideal is great, strive for good, accept bad when it's the only option?
Moz
|
|
Message is in Reply To:
 | | Re: Perl rules!
|
| (...) (heh heh) I think I'm more grossed-out than amused. I'm already grossed out enough that there are a couple ports of perl to MS platforms. IMHO, Perl belongs in Unix (and offshots like OSX) and Microshaft OS's should die horrible deaths. The (...) (25 years ago, 17-Jul-99, to lugnet.off-topic.debate, lugnet.off-topic.geek)
|
433 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
