| |
In lugnet.off-topic.debate, Jasper Janssen writes:
> [...]
> Maintainability is usually more important than efficiency or looking
> pretty. However, to be maintainable, code has to be written in ways
> that can be understood easily. Therefore, they must be pretty (by my
> definition of pretty anyway).
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 (ones that make a difference) rather than the
wrong ones (ones that are just feeping creaturitis).
> > Neither Pascal nor Modula-2 nor Java nor any other of the "pretty"
> > languages
>
> Pascal or Modula-2 "pretty"? First time I've heard anyone claim that.
I've never heard them called exactly "pretty" before either, but I'm
referring to their "simple and clean" syntaxes. That is, the syntaxes of
those languages aren't full of special cases or special-purpose sub-
grammars. But special cases and special-purpose sub-grammars are good
tools for a disciplined programmer (and they -can- be bad tools for poor
programmers). But poor programmers should be expunged anyway.
> > will ever save a fundamentally poor programmer and allow him/her to
> > magically write good code. You can write garbage in any language.
> > Perl, like Lisp and
>
> 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. Much better
to give the programmer higher-level tools which help them avoid these in the
first place, so they're not even at risk of dancing with their own lack of
discipline. Java, Perl, and most other OO languages fit the bill nicely
here but if I still don't know how to write a good sort, and I need a good
sort, and the language I'm using doesn't have it built-in or in a library,
then no high-level language is going to necessarily make my code any better
than assembly language. It just lets me implement a crummy sort easier.
> > most other high-level langauges, makes it easier to write garbage than
> > most languages do, but on the other hand it also makes it easier to
> > write correct code than most languages. It's a double-bladed sword,
> > to be sure.
>
> Perl is a good way to quickly hack up single-usage stuff that's not
> too large, and/or doesn't need to be maintained (by persons other than
> the author, especially).
Perl is also a good way to slowly, carefully, and methodically build a
long-term, highly robust system that's extremely large and does need to be
maintained by multiple persons. Issues like these are not issues of the
language, but rather of the discipline of the programmers. Perl might
require more discipline than Java or Pascal or M2, since it can be
tempting to take unsafe short-cuts. But that doesn't make it any less
appropriate as a language choice for a project unless the programmers on
the project lack self-discipline. 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.
> Many procedural programming languages explicitly force you to think in
> terms of procedures/functions, which makes it harder to write
> spaghetti code.
You believe that it is possible to force someone to think a certain way?
You believe that it is harder to write spaghetti code in procedural or
functional languages?
You need to get out more. :-)
> > > Just like in any other language, of course, but
> > > in perl, "there is always more than one way to fsck up"
> >
> > All languages actually have that property. The others just hide it
> > better.
>
> True. Perl _does_ however have more ways than most, for many things.
Of course it does. It has more ways to do good things, and the flip-side
of that is that it has more ways to abuse the good things. Any good thing
anywhere in the world can be used in a bad way. For better or for worse,
Perl and Lisp and PostScript are not a toy languages for kids or beginning
programmers. 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 people. If you can't hire and keep those kinds of
people, no tool will save you from your own poor management in the long run.
A house today might have 20 light sockets on the walls, 15 sharp knives in
the kitchen drawer, a fireplace, a skil-saw, an electric blender, a couple
ounces of rat poison, a few boxes of matches, a gas lawnmower, a gas grill,
and an electrically heated waterbed. A house 200 years ago probably only
had the knives, the fireplace, and the matches. I guess people today are
in a lot more danger of injuring themselves, huh? :-)
> 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*.
> Sure, _you_ can write good code in
> any language you choose, but does that mean it should be made easier
> for your cow-orkers to write undecipherable stuff?
If your closest co-workers are idiots, you should fire them, get them fired,
or get the heck out of that dead-end job.
If the intellectual capacity of members on your team -- rather than the
criteria of the problem you want to solve -- is what's dictating which
computer language you choose to write code in, then prayer would probably
be a good idea. :-)
> > 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.
>
> Are you saying English as a language is a good thing?
I'm saying that English as a language is a very powerful tool which, like
many very powerful tools, is difficult to master but worth the investment.
> As always, you choose the right tool for the job. In some cases, this
> is perl, in others, it's something else.
Indeed.
> I've seen perl scripts that were literally a few dozen system() calls
> strung together. I've seen C programs that look like perl, I've seen
> perl that looks like FORTRAN...
I don't think it's possible to have seen C programs that look like perl.
Perl doesn't have a "look." Perhaps poorly written Perl code has a look,
or perhaps very well written Perl code has a look, but it's too expressive
of a language to have a single "look." FORTRAN's syntax, being much more
rigid, probably could have a look to it.
> All software sucks, it just does so in subtly different ways.
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? ;-)
> Advocacy is bad.
When I titled the subthread "Perl rules!" I didn't mean to start down a
path of advocacy. 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. Perl's rich syntactic and semantic models let me focus
on writing correct, clear, efficient, and maintainable code, rather than
making me focus on dumb little details all the time, and that makes me very
happy.
--Todd
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
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
|
|
|
|
