| |
Todd Lehman wrote in message ...
> I simply wanted to say that it was the first language I'd ever written code
> in that I didn't get mad at for being crippled in ten different ways.
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.
> [imagine if...] instead of reading a book to learn the syntax, semantics,
> and idioms, you heard people talking it all day long...
We call that maintenance. And it is in fact a good way to learn a new
language. I'm not sure how useful it is for learning to prgram in the
first place as I've never seen it happen or tried.
> But poor programmers should be expunged anyway.
Us mediocre programmers feel ever so much better now. 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.
> > > 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.
> 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.
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.
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...
> 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.
> 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.
> > 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?
> > > You make that sound like a bad thing. Perl is like English. It's not
> > > pretty, but it does everything you want it to if you're willing to
> > > invest the time learning it.
And unfortunately most users of the language are unwilling or unable to do so,
resulting in a lot of sub-optimal usage, and often in complete failure to
understand even the simplest sentences if they describe concepts not already
familiar to the reader, and we have not even begun at this point to discuss
the lamentably limited vocabulary possessed by most people or the even more
restricted working set they use in daily discourse. As a result most writers
aiming for a widespread audience choose to pitch their usage at the lowest
common denominator, or at least some simulacrum thereof, resulting in further
depredations of the lingua franca and continual threnodic wailings from the self-
appointed equivalent of the Bureau de Francious regarding the ongoing decline
in standards. 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.
Despite selecting for the intelligentsia in the educative process the graduands
in most countries are typically unwilling to invest the considerable time
required in acquiring pedantic knowledge of arcane syntax simply to become mildly
proficient in a powerful but primitive language, when for the same relative
effort they could become substantially more valuable experts in a more refined
or perhaps even sophisticated[1] development toolset, thus gaining substantially
higher remuneration and generally also increased appreciation from their peers.
<ok, how many times did you have to read that, and how many words did you look up?>
> 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. And in whether you accept the doctrine of perfectibility,
or submit to the universality of Murphy (all hail Murphy, for he is ubiquitous).
Moz
[1] intended here both in its modern and archaic forms.
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: Perl rules!
|
| (...) I'd put correctness above maintainability, in the sense that, although maintainable code needs to be able to stay correct, code ought to be correct in the first place. And above correctness, the code ought to be solving the right problems (...) (25 years ago, 13-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
|
|
|
|
