Re: Programming Language Productivity: The Stupidity of Programmers
From: Joe \ (joe_at_bftsi0.UUCP)
Date: 11/18/03
- Next message: Sheldon Simms: "Re: Prime number algorithm in C"
- Previous message: Thad Smith: "Re: how can you improve this function?"
- In reply to: Robert STRANDH: "Re: Programming Language Productivity: The Stupidity of Programmers"
- Next in thread: Gerry Quinn: "Re: Programming Language Productivity: The Stupidity of Programmers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 17 Nov 2003 22:42:50 -0800
"Robert STRANDH" <strandh@labri.fr> wrote in message <news:6wd6brml99.fsf@serveur4.labri.fr>...
> "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> writes:
>
> > "Robert STRANDH" <strandh@labri.fr> wrote in message <news:6whe13mt7m.fsf@serveur4.labri.fr>...
> >
> > > I can't agree more. APL seems to be a perfect match for machines with
> > > vector instructions. Instead, they were using parallelizing Fortran
> > > compilers for these machines.
> >
> > How much of this is due to "learning curve" issues?
>
> In this particular case, I do not know, but my experience is that
> people overestimate the importance of these issues. In fact, it is
> rare that anyone even takes the time to make a rough risk analysis,
> i.e., the estimate of potential loss and potential gain. Take a
> simple example: many of my students stick to a very small subset of
> very basic Emacs commands. Observing some random student during a
> three hour session on the computer, I estimate conservatively that
> more than half an hour was wasted due to unnecessary typing.
> Estimating conservatively again that a random student spend 12h per
> week typing, this amounts to a waste of 2h per week, or around a full
> week of work per year. I seriously doubt that it would take more than
> a total of a full-time week to learn enough Emacs to save a week per
> year. Thus, the investment pays off in less than a year. Yet, few
> people even bother making such an estimate.
They're afraid of forgetting it all immediately after finals. =)
(Now was that macro bound to ctrl-alt-shift-compose-home, or...)
> > Also, existing
> > Fortran code would presumably still work with the parallelizing
> > compilers even before tweaking the code to take advantage of the
> > parallelization features, so only the critical loops need to be
> > rewritten.
>
> Yes.
>
> > Meanwhile, converting to APL means a complete re-write!
> > Think of it as boiling a frog -- if the temperature/difficulty
> > gradient is too steep, the frog jumps out.
>
> Re-writing existing code is no doubt too expensive, but new code could
> be written in a better language. The usual objection is that it is
> disadvantageous to have code in several different languages, but
> again, nobody seems to bother estimating this disadvantage compared to
> the benefit of using a more productive language for new code.
>
> Also, old code could be gradually converted to something better as
> part of the normal maintenance process. This requires the possibility
> of mixing different languages in an application, but that is usually
> possible.
Here's the only thing I could find about calling Fortran from APL:
URL:http://groups.google.com/groups?selm=393%40e-street.Morgan.COM
I dunno if there are versions of APL which can prevent their garbage
collectors from moving memory blocks around, to make interoperating
with "foreign" libraries easier.
> > > Many of the religious wars about programming languages have their roots
> > > in ignorance. Compounded with some strong psychological phenomena
> > > (see http://dept-info.labri.fr/~strandh/Essays/psychology.html) this
> > > ignorance is largely responsible for the sad state of our software
> > > industry.
> >
> > The mathematics professors who loved learning mathematics but hated
> > learning word processors probably viewed an hour spent learning the
> > word processor as an hour wasted by not learning more mathematics!
>
> Right. But the hour spent learning the word processor would free up
> many more hours in the future that could be spent on mathematics.
Perhaps he tried it and "bounced off"? Something similar happened
to me when I tried a version of LISP for MS-DOS back around 1990.
However, I'm unafraid to admit it. I did better with Turbo Prolog,
but the cut operator, required in order to keep things out of NP,
was just such a filthy hack...
> > I wonder which language Strandh is talking about in the second to
> > last paragraph. A lot can happen with a language in ten years.
> > Did it just need some time to marinate?
>
> The feature was CLOS (the Common Lisp Object System) and the language
> was Common Lisp. At the time, I was mainly a user of a different
> programming language and found it psychologically convenient not to
> have to learn Common Lisp. My colleague "helped me out" by affirming
> that CLOS was "not the answer". When I finally decided to give it a
> try, I realized I should have given it a try a long time ago.
What was "the question"? So, now we have /three/ languages to
stitch together: dusty Fortran decks, APL, and now CLOS. Holy
impedance mismatch, Batman!
-- Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/> WARNING: I cannot be held responsible for the above They're coming to because my cats have apparently learned to type. take me away, ha ha!
- Next message: Sheldon Simms: "Re: Prime number algorithm in C"
- Previous message: Thad Smith: "Re: how can you improve this function?"
- In reply to: Robert STRANDH: "Re: Programming Language Productivity: The Stupidity of Programmers"
- Next in thread: Gerry Quinn: "Re: Programming Language Productivity: The Stupidity of Programmers"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|