| |
In lugnet.off-topic.debate, Chris Moseley writes:
> It's a bigger gun, letting you shoot bigger things or alternatively make a
> larger whole where your foot used to be. I too like Perl, also C++. But
> my preference is for things like Delphi, Jade or Forte when I can use them,
> especially for larger projects. Perl is very cool, and in its domain is
> very, very hard to beat. You'll be amused I'm sure to hear that it's now
> included with NT, for some versions at least.
(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 Perl advocates are funny folks -- they all hate MS
(basically) but they're happy seeing Perl ported to MS platforms because they
see it as good for Perl. And maybe it is good for Perl. The problem is that
it's also good for MS. I don't know if the Perl advocates realize how bad this
is for Perl in the long run, even if it's good in the short run. Of course,
it's perfectly within the license of Perl to port it, but it's really been sad
to see it start getting gunked up with OS checks and things. I'll really vomit
if I ever see a standard-distribution module accepting a backslash as a
directory character, even via some option. Why it hasn't completely split into
two camps yet is beyond me.
> > But poor programmers should be expunged anyway.
>
> Us mediocre programmers feel ever so much better now.
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.
> And those of
> us burdened by labels like "enterprise" and "highly available" in
> corporate environments feel envious of you. Given a team of 20 people
> made up of both experienced Cobol programmers and recent graduates,
> I personally would be reluctant to recommend Perl for the new insurance
> package even though I'm sure much of the programming could be done in
> it.
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. The point I was trying to
make was, (let's extend your hypothetical) if you had a team of 20 people made
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. Cobol should be used to solve
problems that Cobol as is best at, and the same with Perl. Sometimes they
even overlap so that it doesn't matter which one you choose. But when it does
matter, it's foolish to do it using the tool that people are most familiar
with just for that reason. If a different tool is much more appropriate, then
you find different people who can work with that tool (or retrain your current
people, if that makes more sense). Just a philosophy. All depends on the
scope and size of the project, of course.
> > > > You can write garbage in any language.
> > > Some just make it harder than others.
> > I don't think so. I'm talking about algorithms and fundamentals. Languages
> > that make it easy for programmers to catch their careless off-by-one errors,
> > memory leaks, null-pointer bugs, etc. are just giving band-aids.
>
> Yes and no. What good language design does is lower the bar for production
> of a usable system of a given complexity.
OK.
> > 20 years ago a good programmer writing a complex project in assembler
> > could whomp the butt (in time-to-completion and in correctness) of a
> > poor programmer writing the same project in Pascal or any other high-
> > level language, and that's still true today.
>
> Not even close, I'm afraid. The size of projects has generally increased
> over time, and the density of language has also increased. High level is
> no longer a term most of us associate with Pascal, a better example
> would be Delphi, C++ or Java. And when we start talking about rewriting
> Java in assembly language, things get very silly indeed. Either you
> hand-code Java bytecode (not asm by any stretch), or you produce 10 or
> more assembly language versions of your code for the most common
> environments.
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. At any rate, I still believe that a good (not a bad)
assembly programmer could kick the living daylights out of a poor (not a good)
programmer on just about anything. 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.
> A recent graduate on minimum pass grades can put together a basic multi-
> user address/phone/contacts type database in about a week using Forte,
> and it will accommodate 100's of users on a variety of hardware platforms
> and millions of records.
But that project will not work correctly if the programmer doesn't know
what he/she is doing. A week of work from a bad programmer is worse than
nothing, IMHO. (I mean really bad programmers, that is. I've worked with
at least 6 in the past 10 years.)
> The same system in assembly could not be produced in less than a year by
> any assembly programmer, simply because of the huge number of library
> units they would need to produce, test and inter-relate. I mean, you
> tell me how you'd assembly language code a link from Oracle running
> on an HP-UX box to a Win95 PC client. Even if you're allowed to use the
> comms and database drivers written in a high level language, it's not
> trivial. Then add a couple of distributed database servers, a WAN, a
> few more client architectures and just for luck a couple of different
> networking protocols. With Forte you just tick a couple of checkboxes
> at build time, with assembly you, um, go back to square one pretty much.
> The Forte part of this, BTW, is a real example. It's currently being tested
> on site...
I'm sorry, you are right; in terms of speed of implementation, no assembly
programmer in the world could probably do that sort of thing quickly. I'll
concede that point and leave it at just correctness and robustness.
> > You believe that it is harder to write spaghetti code in procedural or
> > functional languages?
>
> Yes. It takes a certain level of talent to bypass the natural flow of a
> language. While it can be done, even minimal supervision is enough to
> stop most people going too far wrong in most GUI languages. While in
> assembly it takes that long just to have a vague idea where someone is
> in the schedule, let alone what their code quality is.
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.
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. Java
is certainly far better than C++ or Perl in this regard (for the undisciplined
programmer) in that it's harder to do stupid things, and much of the popular
literature focuses on designing things in smart ways.
> > Some people see that as a major plus. Again, the most important thing is
> > to choose the right tool for the job and hire bright, talented, and motivated
>
> Todd, you need to get out more. I believe there are currently something like
> quarter of a million jobs for anyone who can recognise a computer in the
> USA alone? Telling those employers that they shouldn't accept any but the
> best is not really a rational option, IMO.
Heh heh, OK, maybe that's not good advice for most shops. I come from a brutal
and ultra-competitive background at my last couple of jobs. Everyone was open
and willing to spend gobs and gobs of time helping one another as long as they
weren't an idiot and deserved help. But if they were just dragging things down
they didn't last very long. It *is* extremely difficult to hire bright and
talented people.
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.
> > > The problem is that you do _not_ want bad programmers writing stuff
> > > you might have to maintain in perl.
> >
> > I do not want bad programmers programming at *all*.
>
> You'd rather stop the world while we work out how to get more good
> programmers?
I think bad programmers are worse than no programmers. If the world is filled
with bad programmers, then yes, I'd rather the world stopped until it figured
out how to get more good programmers. Bad programmers don't do anything but
*slow down* progress. (Maybe that's my working definition of a bad
programmer.) 100,000 bad programmers can do 100 times as much damage to the
world as 1,000 bad programmers.
> [...] 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.
> <ok, how many times did you have to read that, and how many words did you
> look up?>
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.
> > Hey, there's a winning attitude: It's gonna suck anyway when we're
> > finished, so why should we bother trying to make it any good? ;-)
>
> Depends whether you've ever been involved in testing and maintaining someone
> else's code, I suspect.
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.
I've also been involved in testing and maintaining my own code months or years
after the fact, and I've cursed my own name several times (when something was
a hack that was supposed to be temporary and then later was really needed).
Whenever possible, I throw out the hack completely (after coming to grips with
it inside and out) rather than put another hack layer on top of it.
> And in whether you accept the doctrine of perfectibility,
> or submit to the universality of Murphy (all hail Murphy, for he is
> ubiquitous).
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 apporpriate.
--Todd
|
|
Message has 2 Replies:
 | | Re: Perl rules!
|
| (...) I take it you have little respect for people who develop on MS platforms for a living...? I'm not sure I should be offended. It can also be argued that Perl on a Mac is equally evil: the OS doesn't even offer a shell, and its file system is (...) (25 years ago, 17-Jul-99, to lugnet.off-topic.debate, lugnet.off-topic.geek)
| | | Re: Perl rules!
|
| Todd Lehman wrote in message ... (...) OK, I'd class those as incompetent rather than poor. Not that I'm pedantic at all. (...) Most likely, as I'm good at misunderstanding things like that. It sounded to me as though you were tending towards saying (...) (25 years ago, 19-Jul-99, to lugnet.off-topic.debate, lugnet.off-topic.geek)
|
Message is in Reply To:
| | Re: Perl rules!
|
| Todd Lehman wrote in message ... (...) It's a bigger gun, letting you shoot bigger things or alternatively make a larger whole where your foot used to be. I too like Perl, also C++. But my preference is for things like Delphi, Jade or Forte when I (...) (25 years ago, 16-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
