Why FP will take over the world and C will die.
Joe Armstrong
- Companies using FPLs will have shorter time to market than companies
using C.
- Systems written in FPLs will be cheaper to maintain and have fewer
errors than systems using C.
- Companies using FPLs will have higher profits than companies using
C.
- Programmers using FPLs will be a lot more productive than
programmers using C.
- Managers only care about the bottom line (i.e. $$ and not
technologies) and will choose the technologies that deliver
fastest - they don't care about FPLs LPLs OOLs etc.
These are the same reasons why C/Fortran etc. displaced assemblers -
the reasons are primarily economic, not technical.
/Joe
--
Joe Armstrong,
Bluetail AB, tel: +46 8-545 550 00
S:t Eriksgatan 44, fax: +46 8-545 550 50
SE-112 32 Stockholm, Sweden info: www.bluetail.com
melen...@my-deja.com
Joe Armstrong <j...@bluetail.com> wrote:
>
> - Companies using FPLs will have shorter time to market than companies
> using C.
>
> - Systems written in FPLs will be cheaper to maintain and have fewer
> errors than systems using C.
>
> - Companies using FPLs will have higher profits than companies using
> C.
>
> - Programmers using FPLs will be a lot more productive than
> programmers using C.
>
> - Managers only care about the bottom line (i.e. $$ and not
> technologies) and will choose the technologies that deliver
> fastest - they don't care about FPLs LPLs OOLs etc.
>
> These are the same reasons why C/Fortran etc. displaced assemblers -
> the reasons are primarily economic, not technical.
>
The same was said about LISP 20+ years ago. So what happened?
"Where have all the Little Lispers gone, long time passing
Where have all the Little Lispers gone, long time ago
Gone to Little Schemers every one"?
They now write books about the lingering industrial <death> of LISP. See
"Patterns of Software, tales from the software community", R. P. Gabriel
(founder of Lucid). A rather morbid funeral dirge, but slightly
instructive.
Most business managers know nothing about the mathematical relation
between technologies and profits.
It is all a complete mystery to them; besides they are too busy with more
important things like IPO's, selling their millions of shares, political
power struggles and looking for the next company to jump to. If a project
fails they just find someone else to blame, fire people and still have
no idea why it failed, much less care. So another project is buried in
the IT project graveyard, "well that's just IT isn't it. We all know how
risky IT is, 80% of IT projects fail don't they? It can't be my fault.
..."
If business managers did understand the relation between technology and
profits C++ would have been strangled at birth. It wasn't so they don't (
modus tollens). QED. I doubt they ever will (modus cynic)
I believe that you are making an erroneous assumption that many
<technologists|scientists|mathematicians> make :
"business managers are rational decision makers".
In my experience (> 20 years in IT) most business managers are not
rational decision makers. They follow the sheep principle: Follow the
other sheep, even if it's over the cliff. That is exactly why they are so
easily manipulated into stupid (uneconomic) technical decisions by
marketing forces completely out of their control.
Most business mangers are usually not very analytical, they use their
"gut", which means their herd instinct, to make "decisions". In some
stable business contexts this can work but with technology|science|
mathemetics it often fails and they do not understand why because they
have no analytical understanding of technology|science|mathematics.
Most business managers have no control over technology at all they are
just swept along in its chaotic turbulence and hope they don't drown
before the next shareholders meeting; or the share price has dropped too
low for them to sell their shares and jump ship before it sinks.
So politely ignore the business managers and just proceed to create
better technology to drive them, as has always been done from the
invention of the plough, to the science of Gallileo, to the visions of
Babbage, Turing, Von Neumann, ...
In the case of Gallileo The Church|Inquisition|Powers that be|Business
Managers were somewhat wrong. "Still, it moves". It only took them about
400 years to admit it.
So don't bother to wait for the business managers. They will, eventually,
follow like the good sheep they are, and they still won't understand but
that doesn't really matter.
Cynicus Maximus
Sent via Deja.com http://www.deja.com/
Before you buy.
graham
> using C.
>
> - Systems written in FPLs will be cheaper to maintain and have fewer
> errors than systems using C.
>
> - Companies using FPLs will have higher profits than companies using
> C.
>
> - Programmers using FPLs will be a lot more productive than
> programmers using C.
>
> - Managers only care about the bottom line (i.e. $$ and not
> technologies) and will choose the technologies that deliver
> fastest - they don't care about FPLs LPLs OOLs etc.
>
> These are the same reasons why C/Fortran etc. displaced assemblers -
> the reasons are primarily economic, not technical.
While I agree with your points above I don't think they necessarily
imply that FPLs will take over from C. Why? Well C took over from
assembler for all the above reasons AND because C was a lot like
assembler. Teaching C to assembler programmers was easy. Calling
assembler from C was easy. Grokking the C-way was easy. Hence
the cost of migration from assembler to C was small. Now FPLs may
have similar advantages over C that C had over assembler, but it's
not clear to me that it has low migration costs. Training C programmers
to program in FPLs is a lot harder. FPLs don't call C so easily (that's
improving). Grokking the functional way appears to be hard. Note also
that the migration from C to C++ and now Java had fairly low
migration costs to for similar sorts of reasons.
graham
Mike Williams
melen...@my-deja.com writes:
|> Most business managers know nothing about the mathematical relation
|> between technologies and profits.
I object most strongly. I am a business manager. I am in charge of
an organisation comprising about 140 people. I am also one of the
minor players in the birth of Erlang (Joe Armstrong was the main
progenitor) as well as being a co-author of the Erlang book.
|> If business managers did understand the relation between technology and
|> profits C++ would have been strangled at birth. It wasn't so they don't (
|> modus tollens). QED. I doubt they ever will (modus cynic)
It is this sort of attitude which makes business managers not listen!
I don't think that C++ is the best language in the world, but there
are good reasons why it spread the way it did. We need a far less
religious attitude to technology, Assembly, C, C++, VB, Java, ML,
Erlang, Clean all have their places. The trick is using the right
language, OS, method etc for the application at hand. Most probably in
a large system different parts will be written in different
technologies. It isn't just a question of technology, there are
personnel / competence / maintability aspects etc which often are equally
important.
|> I believe that you are making an erroneous assumption that many
|> <technologists|scientists|mathematicians> make :
|> "business managers are rational decision makers".
And you assume that <technologists|scientists|mathematicians> are
rational decision makers?
Looking at it from both sides, (I hope I still can be considered a
reasonable technologist despite besing a business manager :-), there are
two problems:
1) Business managers with an insufficient knowledge of technology
2) Technologists with an insufficient knowledge of business and how
to manage people.
Most of the articles in the group clearly demonstrate problem 2).
If you want to see examples of problem 1) you have to look no
further than comp.software-eng.
The projects / companies which really succeed are those where
business managers and technologist manage to establish working
communication and resepct for each other.
Grrrrrrr,
/Mike
Joachim Durchholz
No, managers aren't dumb. They just have different goals. Programmers
want the technologically best solution, managers want the solution that
gets them best success (where "success" may be a noble or not so noble
goal, i.e. any of "commercial success", "a demonstration that our
department is better than the one of my personal enemy", or simply "a
software that's good enough so that we can move on to the *really*
interesting projects").
Besides, the goals of programmers aren't always noble. I've seen
programmers shoot down new technology because they didn't want to learn.
I've seen programmers shoot down existing software because they wanted
to promote their personal toy, or didn't want to learn how the existing
software worked ("rip it down and build something *really* shiny"). I've
seen programmers who were intent on shooting down their superior, or a
colleague, for personal reasons. Is this better than buzzword-compliance
on the side of managers?
(I'm a programmer myself.)
Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
dto
> it. There's an insistence on the productivity boost provided by static
> not the means. It is hard to listen to armchair advocacy in general.
Hear, hear.... this doesn't apply to just c.l.f. but to comp.object and to
many other groups. If people would realize that niche/minority things
*don't need enemies* then things would be a lot more civil, I suspect.
On comp.object the enemy is not just "procedural programming" but
also people who take a pragmatic view toward objects, and use it
only when it seems prudent. Notice how some folks get offended
when you say that FP is great for writing symbolic computation systems
and compilers---you're not supposed to be evaluating it, you're
just supposed to worship it.
graham
Notice how some folks get offended
> when you say that FP is great for writing symbolic computation systems
> and compilers---you're not supposed to be evaluating it, you're
> just supposed to worship it.
FP is not necessarily good for writing symbolic computation systems
either. Speed is critical in such systems, and sometimes FPs just
don't cut the mustard.
graham
PS: the commercial junk like Maple and Mathematica don't cut the
mustard either, but for different reasons.
Hartmann Schaffer
> - Managers only care about the bottom line (i.e. $$ and not
> technologies) and will choose the technologies that deliver
> fastest - they don't care about FPLs LPLs OOLs etc.
unless they are preoccupied with empire building, on power trips, or
want to stay technically up to date by making sure that all this
newfangled stuff they never heard of doesn't come close to the area
they control
> ...
hs
Hartmann Schaffer
Mike Williams <mi...@erix.ericsson.se> wrote:
>In article <8q7k6i$8ah$1...@nnrp1.deja.com>,
> melen...@my-deja.com writes:
>
>|> Most business managers know nothing about the mathematical relation
>|> between technologies and profits.
>
>I object most strongly. I am a business manager. I am in charge of
>an organisation comprising about 140 people. I am also one of the
>minor players in the birth of Erlang (Joe Armstrong was the main
>progenitor) as well as being a co-author of the Erlang book.
well, in this case you are not the only manager who knows what he is
doing, but most likely melenakenny is right for a vast majority.
> ...
>Looking at it from both sides, (I hope I still can be considered a
>reasonable technologist despite besing a business manager :-), there are
>two problems:
>
>1) Business managers with an insufficient knowledge of technology
and still insisting on interfering in the technical decision making
(sorry, but i have observed a couple of hair raising incidents over
the years)
>2) Technologists with an insufficient knowledge of business and how
>to manage people.
if they nevertheless decide to tell the business how to run the
business or how to manage people that's as bad. in my experience they
are less likely to
there is also the problem that can arise when technical compromises
are made with explicite reference to business needs and the technical
people then get blamed when the product doesn't quite live up to
expectations, even when they pointed out the potential in advance.
> ...
hs
Christian Stapfer
> Amen.
>
> No, managers aren't dumb. They just have different goals.
>
> (I'm a programmer myself.)
So filling *any* role slot in the work process introduces
counter productive biases?
For managers they seem to be, among others, a
simple-minded preference for "the bottom line",
a falling for the "mythical man-month" (remember Brooks?),
and a somewhat "cover your ass" approach.
For programmers they seem to be, again among others,
"not wanting to learn", "falling in love with the latest
fad", "shooting others down", and "gadget worship".
Perhaps it is only natural that spotting such biases
on the *other* side of the management / worker split
should be easier than spotting them on one's own?
Though it must be admitted that, capitalism being what it
is, Management's biases are in great danger of colonizing
the whole company (to the detrimant of the overall work
process): The dominant ideology is the ideology of the
dominant class:
»Gramsci supplied three broad planks of the dominant
ideology thesis - the conviction that hegemony was
a matter of Socio-Cultural engineering, a specification
of where it was engineered and an identification of who
the engineers were.«
- Margaret S. Archer: 'Culture and Agency'
What would be totally wrong, I believe, is to look for
the *causes* of such biases mainly in individuals.
If, for example, someone shoots another down for what
you call "personal reasons", such behavior just might be
the outcome of a competitive rat race within hierarchical
structures. (Come to think of it: would wanting to grab
as much money as possible count as "personal reason"?
At first blush, such a tendency might appear to be a
character trait of individuals, but, clearly, it is of
the very essence of the overall ideology of capitalism.)
Being a great admirer of Freud's writings, I wish
someone would write the definitive manual on "The
Sociopathology of Everyday Life in Software Development"
(note, that I wrote "Sociopatholoy" not "Psychopathology"
to compensate for one or Freud's own biases..).
Gerald M. Weinberg's "The Psychology of Computer
Programming" was a nice try, of course, but something
clearly better is needed.
Christian Stapfer
-----------------
»Mead's concept of the generalized other, and Freud's
super-ego - their closest point of contact - enable us
to link the private and the public, the innermost acts
of the individual with the widest kinds of social-historical
phenomena.«
- Hans Gerth & C.Wright Mills: 'Character and Social Structure'
Yiorgos Adamopoulos
crashed! ]
In article <8q7k6i$8ah$1...@nnrp1.deja.com>, melen...@my-deja.com wrote:
>Most business managers know nothing about the mathematical relation
>between technologies and profits.
No. There are two kinds of managers:
- Good managers
- Bad managers
The rest of your post focuses mainly on bad managers.
>It is all a complete mystery to them; besides they are too busy with more
It is not their job to know the ins and outs of our craft. If they do,
it is a GoodThing(tm) but it is not a necessity.
>important things like IPO's, selling their millions of shares, political
This is their job.
>power struggles and looking for the next company to jump to. If a project
Ambition. But then again those who want to become / are managers are
supposed to be engaged in "dirty politics". They are supposed and
expected to be leaders and the above comes with the territory.
>fails they just find someone else to blame, fire people and still have
>no idea why it failed, much less care. So another project is buried in
>the IT project graveyard, "well that's just IT isn't it. We all know how
>risky IT is, 80% of IT projects fail don't they? It can't be my fault.
>..."
No. There are two issues here:
A bad manager will try to cover up his responsibilities and pass these
to the programming team. If the programming team cannot protect itself
from the libel, this is not the fault of the manager. He already is a
bad person, why should he care for the others?
OTOH, a good manager would use the negative results generated from the
burried project to learn what went wrong. And always the manager does
this in collaboration with the programmers.
>If business managers did understand the relation between technology and
>profits C++ would have been strangled at birth. It wasn't so they don't (
>modus tollens). QED. I doubt they ever will (modus cynic)
Is it only their fault that they do not understand? Think again.
>I believe that you are making an erroneous assumption that many
><technologists|scientists|mathematicians> make :
> "business managers are rational decision makers".
No. IMO, the right phrase is:
- Good business managers are rational decision makers.
- Bad business managers are based in luck.
>In my experience (> 20 years in IT) most business managers are not
>rational decision makers. They follow the sheep principle: Follow the
>other sheep, even if it's over the cliff. That is exactly why they are so
>easily manipulated into stupid (uneconomic) technical decisions by
>marketing forces completely out of their control.
No true. Managers are humans just like all others. They simply are
not programmers. Managers have their own API just as programmers have
their own. So, whenever you want to make *your* point understood by
a manager you have to use *his* API to talk to him, just as you use
sockets to make your application talk over TCP/IP with another machine's
application. Likewise, when he wants to make *his* point understood by
*you* he has to use *your* API.
Managers simply follow the advice of the one who knows how to offer it
to them. Here is a hint for the manager API:
- Flashy Power Point Presentation
- Excell pie charts
- Talk about minimazing cost
- You have to talk to them in numbers and these are not where the next
JMP will go. It has to be about $.
Now why does it bother you that marketing people know how to talk the
talk?
>Most business mangers are usually not very analytical, they use their
>"gut", which means their herd instinct, to make "decisions". In some
This is done by bad managers. If bad managers are the majority, then
the above statement stands. Then again if you can afford it, why stay
and work with such a manager? Why not quit and move on? This is not
easy in small countries like Greece (small place, few managers) but it
is easier in other countries who have employed IT more than mine.
>stable business contexts this can work but with technology|science|
>mathemetics it often fails and they do not understand why because they
>have no analytical understanding of technology|science|mathematics.
And once again: They do not have to. They pay you to understand this.
In fact not only do they pay you to understand this, but they pay you to
explain it to them. It is the feedback they get that they do not
understand and they proceed with what they understand / know (.ppt
presentations).
>Most business managers have no control over technology at all they are
>just swept along in its chaotic turbulence and hope they don't drown
>before the next shareholders meeting; or the share price has dropped too
>low for them to sell their shares and jump ship before it sinks.
And most (bad) programmers blame fellow programmers, the incompetent
parteners from company X in the joined project Y, the operating system
and even the compiler when they fail the deadlines.
>So politely ignore the business managers and just proceed to create
Ignoring them leads to them ignoring you. And since they are the powers
that be, guess whose ass gets burned.
>better technology to drive them, as has always been done from the
>invention of the plough, to the science of Gallileo, to the visions of
>Babbage, Turing, Von Neumann, ...
We are not all as bright as they were.
>In the case of Gallileo The Church|Inquisition|Powers that be|Business
>Managers were somewhat wrong. "Still, it moves". It only took them about
>400 years to admit it.
Gallileo failed to make his point though the very time that he wanted to.
Businesswise or not, getting people to think that you are right with 400
years delay is not very helpful.
>So don't bother to wait for the business managers. They will, eventually,
>follow like the good sheep they are, and they still won't understand but
>that doesn't really matter.
>
>
>Cynicus Maximus
It is my understainding that in your 20+ professional years all the
managers that you have met were bad ones. If this is the case did it
ever occur to you that it could be you that might be wrong? What ways
have you used to make your points? Was it the elitistic style of ``I am
the one who knows tech stuff here, so just shut up and listen!''?
Once in comp.lang.scheme I got (heavily) flamed by a very bright person.
This person's signature was:
"If this is not what you expected, alter your expectations"
Could it be that you expect from managers different things than the ones
they are supposed to do? Why not describe what the ideal manager would
be like? And how you would try to make him consider an FPL for a
project?
--
Yiorgos Adamopoulos -- #include <std/disclaimer.h>
ad...@dblab.ece.ntua.gr -- Knowledge and Data Base Systems Laboratory, NTUA
Joachim Durchholz
>
> The trouble in c.l.f. is that there's adovacy without substance behind
> it.
Hmm... I'll try to give my position. I'm not a functional programmer
(yet), so this is just a personal position, but anyway.
> There's an insistence on the productivity boost provided by
> static type systems.
There's a productivity boost when reading programs. I.e. static typing
slows writing programs, but it makes reading them much easier because
the type annotations radically restrict the domain of possibilities that
must be considered.
As an extreme example, I found Smalltalk code nearly unreadable due to
missing type annotations. (I'm sure that part of this was because I was
uncomfortable with the Smalltalk environment, but type annotations would
have helped me a lot to get over this.)
> There's a belief that what programmers really
> crave are mechanical ways of proving programs correct.
This is something that I'm not too intent about at the moment. It seems
to me that proving the consistency of an implementation with a
specification is as difficult as just translating the specification to
something executable.
A concrete example: Take Eiffel (which is a purely imperative language).
In Eiffel, you can write postconditions on routines; Eiffel programmers
would like to have a tool that verifies that the imperative
implementations are consistent with the postconditions.
In an FP language, you just write down the postconditions and let the
compiler infer any imperative code that's required to implement that
postcondition.
> There's
> misplaced enthusiasm in preaching the beauty of the lambda calculus
I don't know enough about lambda calculus to comment on that.
I had some exposure to lambda forms in Lisp, and the concept didn't
strike me as particularly difficult - it's essentially function
application without bothering to give the function a name. Big deal.
> and the goal of complete referential transparency. Do we have any
> real evidence for any of this?
Yes. I have been bitten by lack of referential transparency more than
once. In fact I think that the majority of bugs that I've written in my
life is due to sequencing errors.
Another point is referential opaqueness in libraries. When I look at GUI
libraries, I see a host of poorly-documented dependencies between calls
(and it's no wonder that they are poorly documented: it's a *lot* of
dependencies, many of them relevant only under very specific
circumstances, so they tend get overlooked by the documentation team).
Make the language referentially transparent, with a mechanism to express
the imperative parts of the interface (as any library must have that
manipulates real devices), plus a mechanism that allows me to have
imperative code for the implementation of a referentially transparent
interface, and I'll sing praises to the language all day. (Does such a
language exist?)
> I also think that trying to write killer apps just
> for the sake of furthering the cause of FP is a mistake. There is no
> "cause," other than to solve the problems you need to be solving.
Agreed.
> I think a lot of smaller language communities (Forth, Smalltalk,
> Oberon, Eiffel, APL) have the same misunderstanding that languages
> are the end, not the means.
Coming from one of these communities myself, I don't think that they
consider the language the end. They think that their language is simply
the best available tool to solve real problems, and despair because the
rest of the world simply doesn't get it.
They also see that languages like C++ and Java take the world by a
flurry of marketing, so they begin to wonder whether they shouldn't
themselves engage more in marketing activity.
> It is hard to listen to armchair advocacy in general. Contest
> entries, textbook examples and simple utilities are not
> counterexamples.
Oh, the ICFP contest results were interesting enough to make me curious.
After all, the FP code performed roughly as well at that of the
imperative entries, while imperative code generally had less
functionality. Obviously, you can get much more functionality up and
running in 72 hour if it's a functional language.
This doesn't say much about the viability of functional languages for
large projects, but it was enough to make me rethink my previous stance
of "functional languages have nice concepts but aren't ready for the
real world yet" - obviously they had evolved past the state that I was
remembering.
Textbook examples and utilities have their place as well. Not compelling
on their own; they are needed to illustrate fine points. But to get
people interested, the ICFP contest is more useful, and to convince them
it's real, you need a diverse set of large applications.
But even that has changed since Ericsson released a large set of
functional code to the public. Once projects that sit on top of the
Ericsson code are released, you can expect some pretty good press
(provided that the Ericsson code is suitable for building stuff on top
of it, without the help of the Ericsson organization).
The Bluetail people are also a case for FP in Real Life. The Bluetail
people claim real, commercial advantages from their use of Erlang.
Assuming that the Bluetail people are, well, probably biased (nothing
wrong with *that*), I'd like to hear some independent confirmation - but
if Erlang keeps this growth speed, we can expect some really good press
for functional programming soon.
Joachim Durchholz
> Perhaps it is only natural that spotting such biases
> on the *other* side of the management / worker split
> should be easier than spotting them on one's own?
Yes. It's always easier to see the splinter in your neighbour's eye than
the log in your own.
> What would be totally wrong, I believe, is to look for
> the *causes* of such biases mainly in individuals.
> If, for example, someone shoots another down for what
> you call "personal reasons", such behavior just might be
> the outcome of a competitive rat race within hierarchical
> structures.
I think that personal reasons are a question of whether your goals
conflict with the other person's goals. These conflicts may arise from
the organizational structure, but I don't think it's capitalism at work.
I've seen this sort of conflicts in large companies, in small companies,
and in communities, and I can easily envision them in German Democratic
Republic Produktionsgenossenschaften, third-world tribes, or kibbuzes -
wherever there are more than a few dozen people supposed to work
together for a common goal, there will inevitably conflicts, and as soon
as the people have the freedom to go away they can afford attempts to
kick out the opponents. (Usenet newsgroups aren't *that* different. It's
a lot less acidic than in companies because the assets at stake are much
less valuable, but sometimes they become as poisonous as those in the
commercial world. It's all a question of what's important.)
> (Come to think of it: would wanting to grab
> as much money as possible count as "personal reason"?
> At first blush, such a tendency might appear to be a
> character trait of individuals, but, clearly, it is of
> the very essence of the overall ideology of capitalism.)
Money in capitalism. Scientific renown (citations, authorship,
positions) in the scientific world. Fame in the Open-Source world; or
social agendas (such as the anti-patent movement, or some more political
proponents of Open Source).
The only way to make this type of personal conflict disappear is to make
sure that at most a single person in the social group has something
serious at stake.
Not that I think that this is a likely or even desirable state of
affairs.
Andreas Eder
> In article <8q7k6i$8ah$1...@nnrp1.deja.com>, melen...@my-deja.com wrote:
> >Most business managers know nothing about the mathematical relation
> >between technologies and profits.
>
> No. There are two kinds of managers:
>
> - Good managers
> - Bad managers
Right! But the set of 'Good Managers' is almost empty :-).
>
> The rest of your post focuses mainly on bad managers.
>
> >It is all a complete mystery to them; besides they are too busy with more
>
> It is not their job to know the ins and outs of our craft. If they do,
> it is a GoodThing(tm) but it is not a necessity.
Right, not the ins and outs, but a sound grasp of the basics. Just as
in the other direction.
>
> >important things like IPO's, selling their millions of shares, political
>
> This is their job.
>
> >power struggles and looking for the next company to jump to. If a project
>
> Ambition. But then again those who want to become / are managers are
> supposed to be engaged in "dirty politics". They are supposed and
> expected to be leaders and the above comes with the territory.
>
> >fails they just find someone else to blame, fire people and still have
> >no idea why it failed, much less care. So another project is buried in
> >the IT project graveyard, "well that's just IT isn't it. We all know how
> >risky IT is, 80% of IT projects fail don't they? It can't be my fault.
> >..."
>
> No. There are two issues here:
>
> A bad manager will try to cover up his responsibilities and pass these
> to the programming team. If the programming team cannot protect itself
> from the libel, this is not the fault of the manager. He already is a
> bad person, why should he care for the others?
>
> OTOH, a good manager would use the negative results generated from the
> burried project to learn what went wrong. And always the manager does
> this in collaboration with the programmers.
>
> >If business managers did understand the relation between technology and
> >profits C++ would have been strangled at birth. It wasn't so they don't (
> >modus tollens). QED. I doubt they ever will (modus cynic)
>
> Is it only their fault that they do not understand? Think again.
The problem is, that most of them are not interested at all in
understanding the issues, because understand is hard, and anyway
understanding is none of their business. If it were, they wouldn#t
have become managers. It's the bucks they 're interested in.
But look, what did you describe here? A rational being? I wouldn#t say
so. He who is being impressed by what you describe and not by
reasonable arguments is just that - sheep!
>
> Now why does it bother you that marketing people know how to talk the
> talk?
>
> >Most business mangers are usually not very analytical, they use their
> >"gut", which means their herd instinct, to make "decisions". In some
>
> This is done by bad managers. If bad managers are the majority, then
> the above statement stands. Then again if you can afford it, why stay
> and work with such a manager? Why not quit and move on? This is not
> easy in small countries like Greece (small place, few managers) but it
> is easier in other countries who have employed IT more than mine.
No, because the very few "Good Managers" (tm) are really hard to find
amongst the others. Beleive me, I speak from experience.
>
> >stable business contexts this can work but with technology|science|
> >mathemetics it often fails and they do not understand why because they
> >have no analytical understanding of technology|science|mathematics.
>
> And once again: They do not have to. They pay you to understand this.
> In fact not only do they pay you to understand this, but they pay you to
> explain it to them. It is the feedback they get that they do not
> understand and they proceed with what they understand / know (.ppt
> presentations).
The problem is, that they do not listen. They do not want to
understand. They are not able to follow a chain of logical
arguments. (If they would, they wouldn#t have become managers in the
first place).
>
> >Most business managers have no control over technology at all they are
> >just swept along in its chaotic turbulence and hope they don't drown
> >before the next shareholders meeting; or the share price has dropped too
> >low for them to sell their shares and jump ship before it sinks.
>
> And most (bad) programmers blame fellow programmers, the incompetent
> parteners from company X in the joined project Y, the operating system
> and even the compiler when they fail the deadlines.
>
> >So politely ignore the business managers and just proceed to create
>
> Ignoring them leads to them ignoring you. And since they are the powers
> that be, guess whose ass gets burned.
That is unfortunately very much the truth.
>
> >better technology to drive them, as has always been done from the
> >invention of the plough, to the science of Gallileo, to the visions of
> >Babbage, Turing, Von Neumann, ...
>
> We are not all as bright as they were.
>
> >In the case of Gallileo The Church|Inquisition|Powers that be|Business
> >Managers were somewhat wrong. "Still, it moves". It only took them about
> >400 years to admit it.
>
> Gallileo failed to make his point though the very time that he wanted to.
> Businesswise or not, getting people to think that you are right with 400
> years delay is not very helpful.
But the truth is the truth is the truth.
>
> >So don't bother to wait for the business managers. They will, eventually,
> >follow like the good sheep they are, and they still won't understand but
> >that doesn't really matter.
> >
> >
> >Cynicus Maximus
>
> It is my understainding that in your 20+ professional years all the
> managers that you have met were bad ones. If this is the case did it
> ever occur to you that it could be you that might be wrong? What ways
> have you used to make your points? Was it the elitistic style of ``I am
> the one who knows tech stuff here, so just shut up and listen!''?
No ,that would be just the managers way. I have found out, that most
managers are not willing to foolow a logical chain of reasoning,
because is is perceived as something nerdy, mathematical and
definitely not cool. Thinking hard is not cool and doesn't make you
sexy!
>
> Once in comp.lang.scheme I got (heavily) flamed by a very bright person.
> This person's signature was:
>
> "If this is not what you expected, alter your expectations"
Ask him, how many god managers there are. Not very many.
And by the way, there aren't that many good programmers either.
But the percentage here on c.l.f should be distinctly higher than
elsewhere.
>
> Could it be that you expect from managers different things than the ones
> they are supposed to do? Why not describe what the ideal manager would
> be like? And how you would try to make him consider an FPL for a
> project?
>
> --
> Yiorgos Adamopoulos -- #include <std/disclaimer.h>
> ad...@dblab.ece.ntua.gr -- Knowledge and Data Base Systems Laboratory, NTUA
>
Andreas
(let's see, who is cynicus maximus here)
--
Wherever I lay my .emacs, there愀 my $HOME.
Bruce Hoult
ad...@ieee.org wrote:
> Once in comp.lang.scheme I got (heavily) flamed by a very bright person.
> This person's signature was:
>
> "If this is not what you expected, alter your expectations"
Only once? You're lucky.
-- Bruce
Yiorgos Adamopoulos
>In article <slrn8shm39...@city.dbnet.ece.ntua.gr>,
>ad...@ieee.org wrote:
>
>> This person's signature was:
>>
>> "If this is not what you expected, alter your expectations"
>
[ Forgive the off-topic ]
"Once" summs it up to ``one week in a row'' because I erroneously
replied to him on the same level :-)
melen...@my-deja.com
>
> |> Most business managers know nothing about the mathematical relation
> |> between technologies and profits.
>
> an organisation comprising about 140 people. I am also one of the
> minor players in the birth of Erlang (Joe Armstrong was the main
> progenitor) as well as being a co-author of the Erlang book.
>
> |> profits C++ would have been strangled at birth. It wasn't so they don't (
> |> modus tollens). QED. I doubt they ever will (modus cynic)
>
> I don't think that C++ is the best language in the world, but there
> are good reasons why it spread the way it did. We need a far less
> religious attitude to technology, Assembly, C, C++, VB, Java, ML,
> Erlang, Clean all have their places. The trick is using the right
> language, OS, method etc for the application at hand. Most probably in
> a large system different parts will be written in different
> technologies. It isn't just a question of technology, there are
> personnel / competence / maintability aspects etc which often are equally
> important.
>
> |> <technologists|scientists|mathematicians> make :
> |> "business managers are rational decision makers".
>
> rational decision makers?
>
> reasonable technologist despite besing a business manager :-), there are
> two problems:
>
> 1) Business managers with an insufficient knowledge of technology
>
> to manage people.
>
> If you want to see examples of problem 1) you have to look no
> further than comp.software-eng.
>
> The projects / companies which really succeed are those where
> business managers and technologist manage to establish working
> communication and resepct for each other.
"Methinks he doth protest too much".
Maybe you are "the exception that proves the rule"?
From my IT experience, > 20 years, statistically you appear to be way
outside 3 standard deviations of the mean.
I have also managed large national IT projects in large corporations.
I am also "business manager", at times, depending on market conditions.
IT history is littered with the herd like choices of business managers|IT
managers technical choices. It has become a classic saying "You can't go
wrong if you choose x" . Where x = the most popular vendor of the era.
x is in { IBM, Oracle, Microsoft, Cisco, SAP, ...} . market dominance
rules not technical excellence because such managers create a positive
feedback loop leading to semi-exponential growth. Pareto's principle
patterns soon appear in any new market. It happens in most industries
because most managers want to play it safe by hiding in the middle of the
herd. It's human nature|evolution, maybe even sensible in some cases?
Exceptions are rare.
Marketers understand this human behaviour very well, and of course
manipulate the manager herd to increase sales, which pumps the feedback
loop even more ...
So congratulations, you are a rare breed!
Woof
Ulf Wiger
m> mi...@erix.ericsson.se (Mike Williams) wrote:
>> I object most strongly. I am a business manager. I am in charge
>> of an organisation comprising about 140 people. I am also one of
>> the minor players in the birth of Erlang (Joe Armstrong was the
>> main progenitor) as well as being a co-author of the Erlang book.
m> "Methinks he doth protest too much".
m> Maybe you are "the exception that proves the rule"?
It is indeed unusual to find people who were part of inventing a
new technology, succeeded in moving it into industrial use, and then
became a manager himself. There are some; there should be more.
We can't just blame our current management for this. Mike's been
put in charge of several development projects (including C++ and
Java projects) because he's learned how to lead and communicate
with other managers. As far as I can tell, even the C++ and Java
programmers under Mike who couldn't care less about Erlang, are
happy with his management -- presumably because he is pragmatic
and responsive to their needs.
It's OK to have religion; you can even be proud of it, as long as
you demonstrate that you understand what it takes to run a business.
This is key if you want to move your religion into the mainstream.
/Uffe
--
Ulf Wiger tfn: +46 8 719 81 95
Network Architecture & Product Strategies mob: +46 70 519 81 95
Ericsson Telecom AB, Datacom Networks and IP Services
Varuvägen 9, Älvsjö, S-126 25 Stockholm, Sweden
Adrian May
is still too difficult. Theres masses of work to do and not enough people
who know how to do it. My old managers used to say to me:
"We'd love to do it all in C++, but then you would be all on your own
(unless you know another decent programmer). So the other half of your
project is going to be done in VB."
That manager wasn't dumb, he had his hands tied behind his back. I didnt
mention Haskell.
FP is extremely hard to learn for the average mortal, even more so than OO
(which they seem to have enough difficulty with), and easy to screw up
through not understanding subtleties like tail recursion. Another example
is that Java expected more success in the web, but it seems that people just
one clunk-clunk languages like Perl.
Adrian.
Kragen Sitaker
Adrian May <adria...@t-online.de> wrote:
>FP is extremely hard to learn for the average mortal, even more so than OO
>(which they seem to have enough difficulty with), and easy to screw up
>through not understanding subtleties like tail recursion. Another example
>is that Java expected more success in the web, but it seems that people just
>one clunk-clunk languages like Perl.
Perl has dynamic typing, first-class closures, map, filter (called
'grep'), built-in backtracking regular expressions, aggregate
operations like array assignment, run-time namespace modification,
dynamically resizing deques for arrays, built-in associative arrays,
multiple inheritance, and variadic functions, and supports the
tail-call optimization (although you have to do it by hand).
Java doesn't. It doesn't even have function pointers. You have to
abuse dynamic method dispatch to fake them.
Java has some advantages over C: dynamic method dispatch, type-safety,
bounds-checking, garbage collection, inheritance, dynamic class
loading, a module system, a decent way of doing 'import', reflection,
and interpreter-sandboxed execution. Perl has all these advantages,
too, and most of them are better than Java's equivalents, with the
exception that Perl's garbage collection is slow and broken.
There is a reason people use Perl instead of Java. Perl is a
higher-level language. They get their work done faster in Perl than in
Java.
Perl is also, like the steps of a Classical Greek temple, worn down to
fit the soles of people's feet. Common things are easy in Perl. Java
prides itself on its orthogonal design, not its convenience in use.
--
<kra...@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we ourselves
possess.
-- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]
FM
>If anything wipes out C++ it'll be Visual Basic. Why? Because programming
>is still too difficult. Theres masses of work to do and not enough people
>who know how to do it.
How? VB won't make those who can't program in other
languages good programmers. And often, bad programmers
are worse than no programmer. Of course there often is
some tedious work that requires quantity rather than
quality and isn't meant to be used long-term and that's
where VB and other scripting languages kick in. I'm not
saying those languages aren't useful for any application
but they simply *cannot* be used to replace many of the
applications that C++ is currently being used for and
even where they could, they won't result in much better
productivity, if at all. FPLs, however, can and will
improve productivity.
>FP is extremely hard to learn for the average mortal, even more so than OO
>(which they seem to have enough difficulty with),
I'd disagree. I don't think FP is more difficult than
imperative/procedural programming, if it is taught first.
>and easy to screw up
>through not understanding subtleties like tail recursion. Another example
>is that Java expected more success in the web, but it seems that people just
>one clunk-clunk languages like Perl.
Those who don't understand tail-recursion probably don't
understand iteration either.* They are equivalent and I
would say for simple iteration, tail-recursion is easier
to understand than loops simply because it makes the
process of conditional iteration more explicit.
while(continue?(state))
state = next(state);
return state;
=>
fun do-tail(state)
if (continue?(state)
do-tail(next(state));
else
state;
Is there really any difference between the above two, in
terms of what they represent and how you'd go about
explaining what they do? I don't think there's really any
more one needs to teach about tail-recursion, once they
grasp that it's more or less equivalent to iteration via
loops.
* My observation is that MANY students who don't initially
seem to have trouble with the concept of loops are completely
unable to follow code that has loops with arbitrary exit
conditions. This implies that their understanding of loops is
mostly idiomatic - which means idiomatic use of tail-recursion
for simple iterations can be taught just as easily.
Dan.
Bruce Hoult
kra...@dnaco.net (Kragen Sitaker) wrote:
> Perl [...] supports the tail-call optimization (although you
> have to do it by hand).
Could you possibly demonstrate that for me? I thought I knew Perl (I
use it all the time), but I didn't know about that.
-- Bruce
Matthias Blume
> Perl has dynamic typing, first-class closures, map, filter (called
> 'grep'), built-in backtracking regular expressions, aggregate
> operations like array assignment, run-time namespace modification,
> dynamically resizing deques for arrays, built-in associative arrays,
> multiple inheritance, and variadic functions, and supports the
> tail-call optimization (although you have to do it by hand).
This reminds me of on old koan:
Q: Does Perl have Buddha nature?
A: Why not. It has everything else.
Matthias
--
Matthias Blume <blume@k_u_r_i_m_s.k_y_o_t_o-u.a_c.j_p>
Kyoto University, Research Institute for Mathematical Sciences
(remove those spam-preventing underscores from mail address)
Matthias Blume
Well, I don't know either, but maybe it has loops. :)
(Tail-call optimization "by hand" == write an explicit loop, no?)
Bruce Hoult
<s...@my.sig> wrote:
> Bruce Hoult <br...@hoult.org> writes:
>
> > In article <mccA5.24104$ve5.1...@news-east.usenetserver.com>,
> > kra...@dnaco.net (Kragen Sitaker) wrote:
> >
> > > Perl [...] supports the tail-call optimization (although you
> > > have to do it by hand).
> >
> > Could you possibly demonstrate that for me? I thought I knew Perl (I
> > use it all the time), but I didn't know about that.
>
> Well, I don't know either, but maybe it has loops. :)
> (Tail-call optimization "by hand" == write an explicit loop, no?)
Um. No. Simple tail-recursion can be fairly easily turned into a loop,
but general tail-calls to other functions are not so easy. I suppose
you could explicitly set @_ and use a goto, but ... ick.
-- Bruce
Kragen Sitaker
# some nonsense code
sub foo {
my ($x, $y) = @_;
if ($x > 3) {
$y *= 2;
$x--;
} else {
$y++;
$x *= 2;
}
return $x if $y > 200;
@_ = ($x, $y);
goto &bar;
}
sub bar {
my ($x, $y) = @_;
$x++;
@_ = ($x, $y);
goto &foo;
}
print "@{[map {foo $_, 1} (0..10)]}\n";
This produces:
6 6 4 6 3 4 5 6 7 8 9
Here's the non-tail-call version:
# some nonsense code
sub foo {
my ($x, $y) = @_;
if ($x > 3) {
$y *= 2;
$x--;
} else {
$y++;
$x *= 2;
}
return $x if $y > 200;
return bar($x, $y);
}
sub bar {
my ($x, $y) = @_;
$x++;
return foo($x, $y);
}
print "@{[map {foo $_, 1} (0..10)]}\n";
Perl has more features than any of its users know about. Just to keep
it that way, they're trying to add features to it faster than anyone
can learn about them. :)
Bruce Hoult
kra...@dnaco.net (Kragen Sitaker) wrote:
OH MY GOD. And it's even documented in the Camel book ... how'd I miss
the significance of that when I read it? [1]
Quote:
goto &NAME is highly magical, substituting a call to the named
subroutine for the currently running subroutine. This is used by
AUTOLOAD subroutines that wish to load another subroutine and then
pretend that this subroutine -- and not the original one -- had been
called in the first place ([...]). After the goto, not even caller will
be able to tell that the original routine was called first.
Unquote.
Oh my god.
I think I'm going to send a message to the Perl porters suggesting that
they allow the syntax "goto &foo(a, b, c)" to mean the same as "@_ = (a,
b); goto &foo". And if they accept that I'll suggest that if there are
dynamically no more statements in the function that the "goto" be
optional.
Oh my god.
-- Bruce
[1] probable answer: I completely skipped the section on goto, thinking
"I'll never use goto anyway".
Bruce Hoult
kra...@dnaco.net (Kragen Sitaker) wrote:
Actually, that doesn't work all that well. Try this:
sub count {
my $i = shift;
if ($i > 100000){
print "about to return\n";
<>;
return "ok";
} else {
return count($i+1);
#@_ = ($i+1);
#goto &count;
}
}
print count(0),"\n";
On my system (RedHat 6.1, Perl 5.6.0), this sits there with 46 megabytes
of RAM used. If I comment out the "return" line and uncomment the other
two then it sits there with 13 megabytes used instead. That's an
improvement, but it's not what I'd call proper tail-call optimization.
Even this ...
sub count1 {
start: my $i = shift;
if ($i > 100000){
print "about to return\n";
<>;
return "ok";
} else {
@_ = ($i+1);
goto start;
}
}
... uses 1946 KB, which is 8 bytes per iteration more than the 1148 KB
used if the termination test is 1 instead of 100000. (And it uses 40 MB
if I make the termination test 5000000, so there's a leak even with
simple iteration)
-- Bruce
Kragen Sitaker
Bruce Hoult <br...@hoult.org> wrote:
>On my system (RedHat 6.1, Perl 5.6.0), this sits there with 46 megabytes
>of RAM used. If I comment out the "return" line and uncomment the other
>two then it sits there with 13 megabytes used instead. That's an
>improvement, but it's not what I'd call proper tail-call optimization.
>
>if I make the termination test 5000000, so there's a leak even with
>simple iteration)
Sounds like you've found a bug in the garbage-collection of something
fairly fundamental in perl, and that it afflicts the tail-recursive
version more than the iterative version. Perhaps fixing it in the
iterative case would make the tail-recursive case work correctly.
There's a quote in my quotes file (http://pobox.com/~kragen/quotes.txt)
on this topic:
As I've gained more experience with Perl it strikes me that it
resembles Lisp in many ways, albeit Lisp as channeled by an awk
script on acid.
-- Tim Moore <mo...@herschel.bricoworks.com>, on comp.lang.lisp,
in Usenet article <8btgtf$lnr$0...@216.39.145.192>, on 2000-03-29
Mark-Jason Dominus <m...@plover.com> is writing a book mostly about how
to do functional programming in Perl, intended mostly for people who
aren't familiar with functional programming but are familiar with
Perl.
Ulf Wiger
Adrian> If anything wipes out C++ it'll be Visual Basic. Why?
Adrian> Because programming is still too difficult. Theres masses
Adrian> of work to do and not enough people who know how to do it.
Well, many managers have this recurring wet dream that you could
treat software development much like you'd send a rocket to the moon:
you take great care in pointing the rocket and calculating the right
amount of fuel, and then you just press the button (apologies to all
rocket scientists out there who feel that I don't do justice to your
particular art.)
There will be a place for programming tools for the non-programmer.
I'm a great fan of FileMaker, which pioneered the point-and-click
style of building database applications, for example.
But there is a clear move towards more and more sophisticated
programs, which must be developed in shorter time and with higher
quality than previously. "Be first, Be best, Be cost-efficient", is
what our management tells us...
Right -- this type of programming *is* hard, and there is no
getting around the fact that you need some extremely clever people
to pull it off. This is dawning on management in many companies,
even though it will take a long time for it to permeate large
corporations.
I know that managers are often rightfully scared of becoming
dependent on unpredictable hackers. This has been a strong
driving force behind the efforts to "rationalize" the development
process. This is certainly justified as long as programming is
low-level enough to border on "black art". Our FP programming is
high-level enough that we can (and constantly do) bring in new
programmers to maintain and improve code that others have written.
Basically, you need world-class programmers to design a complex
system, but if you're dependent on the same world-class people
to maintain it for you, you're in a world of hurt, because they
won't, unless you give them offers they can't refuse.
Adrian> FP is extremely hard to learn for the average mortal, even
Adrian> more so than OO (which they seem to have enough difficulty
Adrian> with), and easy to screw up through not understanding
Adrian> subtleties like tail recursion.
I beg your pardon, but Erlang, for example, is a lot easier to
learn and become productive with than e.g. C++.
At Ericsson, we've trained people of all backgrounds in Erlang,
and can say from experience that it *is* easy to learn.
Even more importantly, it gives us a head start on our competition.
Matthias Blume
> Um. No. Simple tail-recursion can be fairly easily turned into a loop,
> but general tail-calls to other functions are not so easy. I suppose
> you could explicitly set @_ and use a goto, but ... ick.
I know. I was just trying to poke fun at the very concept of "doing
tail-recursion optimization by hand".
Michael Schuerig
> I'd disagree. I don't think FP is more difficult than
> imperative/procedural programming, if it is taught first.
This sounds too good to be true. There's quite a large number of people
who got introduced to programming through SICP. When these people will
have occupied lots of tech management positions one day, may we then
expect FPLs to be widely used in industry projects?
I'm not holding my breath. From my experience most people quickly
regress to "more traditional approaches" as soon as they can.
Michael
--
Michael Schuerig
mailto:schu...@acm.org
http://www.schuerig.de/michael/
FM
>FM <da...@dartmouth.edu> wrote:
>> I'd disagree. I don't think FP is more difficult than
>> imperative/procedural programming, if it is taught first.
>This sounds too good to be true. There's quite a large number of people
>who got introduced to programming through SICP.
Frankly, I don't think there are that many. SICP is
usually not the first CS course in most colleges,
and even where it is, I'd expect that most students
already have a preconceived notion of what
programming is, if not substantial experience in
imperative programming before.
Dan.
Adrian May
Ulf Wiger <Ulf.Wiger.c...@ericsson.com> wrote in message
news:xczem26...@etxb.ericsson.se...
> >>>>> "Adrian" == Adrian May <adria...@t-online.de> writes:
>
> Adrian> If anything wipes out C++ it'll be Visual Basic. Why?
> Adrian> Because programming is still too difficult. Theres masses
> Adrian> of work to do and not enough people who know how to do it.
>
> Well, many managers have this recurring wet dream that you could
> treat software development much like you'd send a rocket to the moon:
> you take great care in pointing the rocket and calculating the right
> amount of fuel, and then you just press the button (apologies to all
> rocket scientists out there who feel that I don't do justice to your
> particular art.)
Im not quite sure what you are getting at here.
> But there is a clear move towards more and more sophisticated
> programs, which must be developed in shorter time and with higher
> quality than previously. "Be first, Be best, Be cost-efficient", is
> what our management tells us...
> Right -- this type of programming *is* hard, and there is no
> getting around the fact that you need some extremely clever people
> to pull it off. This is dawning on management in many companies,
> even though it will take a long time for it to permeate large
> corporations.
I think this is the old way of thinking that caused programming languages to
spend several decades improving in expressiveness. Nowadays though I think
they are more interested in getting easier. The main cause for that is lack
of staff.
> I know that managers are often rightfully scared of becoming
> dependent on unpredictable hackers.
Is that the dumb variety or the ones who are too good?
> Our FP programming is
> high-level enough that we can (and constantly do) bring in new
> programmers to maintain and improve code that others have written.
>
> Basically, you need world-class programmers to design a complex
> system, but if you're dependent on the same world-class people
> to maintain it for you, you're in a world of hurt, because they
> won't, unless you give them offers they can't refuse.
This would be music to any manager's ears.
> I beg your pardon, but Erlang, for example, is a lot easier to
> learn and become productive with than e.g. C++.
>
> At Ericsson, we've trained people of all backgrounds in Erlang,
> and can say from experience that it *is* easy to learn.
> Even more importantly, it gives us a head start on our competition.
I hear a lot about how cool Ericsson is, and was quite excited to have the
opportunity of working there once. I turned the job down when I heard that
it was pure C, (without even the ++). And in any case, why does my mobile
phone keep crashing.
Adrian.
Adrian May
FM <da...@dartmouth.edu> wrote in message
news:slrn8t2m0...@hinman-bp-117.dartmouth.edu...
> Adrian May <adria...@t-online.de> wrote:
> >If anything wipes out C++ it'll be Visual Basic. Why? Because
programming
> >is still too difficult. Theres masses of work to do and not enough
people
> >who know how to do it.
I forgot to point out that I personally hate VB.
> How? VB won't make those who can't program in other
> languages good programmers. And often, bad programmers
> are worse than no programmer.
But thats the whole point, they're not. A middle manager doesnt tell a top
manager that the project isnt going to happen at all for lack of
programmers. Instead he hires the first punk who doesnt ask whether the box
takes four star or two.
> Of course there often is
> some tedious work that requires quantity rather than
> quality and isn't meant to be used long-term and that's
> where VB and other scripting languages kick in. I'm not
> saying those languages aren't useful for any application
> but they simply *cannot* be used to replace many of the
> applications that C++ is currently being used for and
> even where they could, they won't result in much better
> productivity, if at all. FPLs, however, can and will
> improve productivity.
Little projects have a habit of growing into big ones. VB falls over after
about 5000 lines. I agree with you that its crap, but I can see whats going
on all around me.
> I don't think FP is more difficult than
> imperative/procedural programming, if it is taught first.
I'll go along with that, but thats one hell of an if.
> Those who don't understand tail-recursion probably don't
> understand iteration either.* I don't think there's really any
> more one needs to teach about tail-recursion, once they
> grasp that it's more or less equivalent to iteration via
> loops.
I also understand it in the abstract, but I still dont know why my
Franimations get slower the longer you run them.
Adrian.
Ulf Wiger
Adrian> Ulf Wiger <Ulf.Wiger.c...@ericsson.com> wrote in
>> Well, many managers have this recurring wet dream that you could
>> treat software development much like you'd send a rocket to the
>> moon: you take great care in pointing the rocket and calculating
>> the right amount of fuel, and then you just press the button
>> (apologies to all rocket scientists out there who feel that I
>> don't do justice to your particular art.)
Adrian> Im not quite sure what you are getting at here.
Perhaps a bit off topic, but I was referring to the notion that
successful development is a result of strong top-down management
and foresight -- and that a project such as the AXD 301, for
example, would have been equally successful using any other
programming language (Java, C++, or perhaps even VB!)
Believe me, I've heard this claim from fairly high up in the
management chain.
>> But there is a clear move towards more and more sophisticated
>> programs, which must be developed in shorter time and with higher
>> quality than previously. "Be first, Be best, Be cost-efficient",
>> is what our management tells us... Right -- this type of
>> programming *is* hard, and there is no getting around the fact
>> that you need some extremely clever people to pull it off. This
>> is dawning on management in many companies, even though it will
>> take a long time for it to permeate large corporations.
Adrian> I think this is the old way of thinking that caused
Adrian> programming languages to spend several decades improving in
Adrian> expressiveness. Nowadays though I think they are more
Adrian> interested in getting easier. The main cause for that is
Adrian> lack of staff.
...with the clear risk that lack of staff becomes a powerful
argument for choosing the programming language known by the most
people. This is not really an irrational ambition, but it's
misguided. I'd be looking for people with a slew of languages and
environments on their resume, assuming that they will be less
religious about sticking to a particular tool, no matter what the
cost.
>> I know that managers are often rightfully scared of becoming
>> dependent on unpredictable hackers.
Adrian> Is that the dumb variety or the ones who are too good?
That would be the "too good" variety -- basically anyone with the
power to become indispensible, and the ambition to get there.
Adrian> I hear a lot about how cool Ericsson is, and was quite
Adrian> excited to have the opportunity of working there once. I
Adrian> turned the job down when I heard that it was pure C,
Adrian> (without even the ++). And in any case, why does my mobile
Adrian> phone keep crashing.
Oh, that one is easy: the mobile phones are not running Erlang. ;)
Anyway, Ericsson is a *large* company. You need to figure out what
the cool spots are and apply for a job in one of them.
Friedrich Dominicus
>
> Perhaps a bit off topic, but I was referring to the notion that
> successful development is a result of strong top-down management
> and foresight -- and that a project such as the AXD 301, for
> example, would have been equally successful using any other
> programming language (Java, C++, or perhaps even VB!)
exists. And you'll never know under what circumstances your software
will be used. So foresight or top-down are just one part of the work.
Regards
Friedrich
--
for e-mail reply remove all after .com
Yiorgos Adamopoulos
>Adrian May <adria...@t-online.de> wrote:
>>If anything wipes out C++ it'll be Visual Basic. Why? Because programming
>>is still too difficult. Theres masses of work to do and not enough people
>>who know how to do it.
>
>How? VB won't make those who can't program in other
>languages good programmers. And often, bad programmers
>are worse than no programmer.
This is how, at least for this corner of the planet:
At first (80s) there were few *ignorant* on CS people who owned a
computer. These people used dBASE and Clipper. They sold their
``databases'' and became the local market leaders.
Then came Windows and Access. With these, came Microsoft marketing.
And the above people (now local companies) had trouble "upgrading" their
programs, since they were not willing to pay ``someone with a degree''
for ``something easy''.
Then came VB and later versions of Access.
Then everybody thought that knew databases.
"I do not understand how the search engines are so fast. I tried
storing 20K records in Access and it boomed" said to me once one of the
above genre.
This is what VB does. It makes people belive they know how to program
because it gives them an easy head start for what they want.
(Then I made some money :-)
Yiorgos Adamopoulos
>and even where it is, I'd expect that most students
>already have a preconceived notion of what
>programming is, if not substantial experience in
Yes. That is because most CS students start programming alone when they
get their first computer and get tired of playing games.
-Y.
Yiorgos Adamopoulos
>The problem is, that most of them are not interested at all in
>understanding the issues, because understand is hard, and anyway
>understanding is none of their business. If it were, they wouldn#t
>have become managers. It's the bucks they 're interested in.
They are interested in making money. Making maney requires one basic
understanding: To understand how to make money. Judging from the
managers' paychecks, they do understand this particular issue well
enough.
>> Managers simply follow the advice of the one who knows how to offer it
>> to them. Here is a hint for the manager API:
>>
>> - Flashy Power Point Presentation
>> - Excell pie charts
>> - Talk about minimazing cost
>> - You have to talk to them in numbers and these are not where the next
>> JMP will go. It has to be about $.
>
>But look, what did you describe here? A rational being? I wouldn#t say
>so. He who is being impressed by what you describe and not by
>reasonable arguments is just that - sheep!
When I am working with a bad manager and I cannot afford it to quit, I
prefer it to be I who is "manipulating" the manager and not the
marketing hype. If I make the sheep walk my way, I can work with my
terms, not somebody else's from out of town.
>No, because the very few "Good Managers" (tm) are really hard to find
>amongst the others. Beleive me, I speak from experience.
Experience is what we get when we do not get what we want :-) I believe
you.
>The problem is, that they do not listen. They do not want to
>understand. They are not able to follow a chain of logical
>arguments. (If they would, they wouldn#t have become managers in the
>first place).
They employ different "logic". For us there is an axiom that says
"1 + 1 == 2". For them "1 + 1" sometimes is "2", sometimes "3" and
sometimes "-10". To understand why, we need to put more variables in
the problem they (the managers) are facing. Then some (not all) of
their decisions make sense.
>> Gallileo failed to make his point though the very time that he wanted to.
>> Businesswise or not, getting people to think that you are right with 400
>> years delay is not very helpful.
>
>But the truth is the truth is the truth.
The truth is one thing. Presenting the truth is another. My people
have a saying ``when not presenting arguments the right way you make
what seems just; unjust'' (my English does not quite help me here).
>No ,that would be just the managers way. I have found out, that most
>managers are not willing to foolow a logical chain of reasoning,
>because is is perceived as something nerdy, mathematical and
>definitely not cool. Thinking hard is not cool and doesn't make you
>sexy!
Looking sexy has nothing to do with thinking hard. Money is sexy for
some people. For others it is power or sense of security that they are
drowned to. Others are drawn by the looks and others by the way of
thinking.
>> This person's signature was:
>>
>> "If this is not what you expected, alter your expectations"
>
>Ask him, how many god managers there are. Not very many.
That particular person I do not want to ask nothing from. We have
incompatible APIs to make any rational conversation.
I also asked:
> Could it be that you expect from managers different things than the ones
> they are supposed to do? Why not describe what the ideal manager would
> be like? And how you would try to make him consider an FPL for a
> project?
Andreas, please describe to me what the perfect manager would be for
you.
>Andreas
>(let's see, who is cynicus maximus here)
Joachim Durchholz
>
> >FP is extremely hard to learn for the average mortal, even more so
> >than OO (which they seem to have enough difficulty with),
>
> I'd disagree. I don't think FP is more difficult than
> imperative/procedural programming, if it is taught first.
Teaching FP first is not an option. Even if all students in the world
would now be taught functional languages, it would still take twenty
years until they arrived at position where they can decide about what
language to use in a project.
At that point, we'll sit in comp.lang.aop (or whatever the "best"
paradigm at that time will be) and moan "all these functional programmer
simply don't get it, but teaching to unspoiled kids would work"... :)
BTW this has been claimed for every single paradigm that was introduced.
Structured programming, OO, logic programming, and now functional
programming. It's conspicuous that the best evidence for such claims was
never more than anecdotal. Where are the studies that checked how
students fared in the years after?
> * My observation is that MANY students who don't initially
> seem to have trouble with the concept of loops are completely
> unable to follow code that has loops with arbitrary exit
> conditions. This implies that their understanding of loops is
> mostly idiomatic - which means idiomatic use of tail-recursion
> for simple iterations can be taught just as easily.
Actually both loops and tail recursion have such a complicated semantics
that people try to avoid both if they can (assuring that the darn thing
terminates at the exact right point, and making sure that the code works
at the first, intermediate, and last time through is an opportunity for
more bugs than one would like).
That's also the reason why all functional languages have mapping
functions, I'd think.
Regards,
Joachim
--
This is not an official statement from my employer or from NICE.
FM
>ad...@ieee.org wrote:
>In my day, son, you couldn't play games on your computer until you wrote
>them.
Hmm I guess those people have a considerably different
approach towards programming than, say, someone like
myself, whose first computer, a Pentium, came bundled
with a bunch of commercial softwares. But then, I read
about computers before I really had one and thanks to
the archaic nature of the literature I had access to,
I somehow thought you had to know how to program to use
a computer. Ah, good old days :)
Dan.
Hartmann Schaffer
in the days of batch systems, they wouldn't let you near a computer
if you could program (unless you worked on the os or for a system
where the os wasn't ready yet.
hs
Bruce Hoult
ad...@ieee.org wrote:
> In article <slrn8t4u17...@hinman-bp-117.dartmouth.edu>, FM wrote:
> >and even where it is, I'd expect that most students
> >already have a preconceived notion of what
> >programming is, if not substantial experience in
>
> Yes. That is because most CS students start programming alone when they
> get their first computer and get tired of playing games.
In my day, son, you couldn't play games on your computer until you wrote
them.
-- Bruce
FM
>FM <da...@dartmouth.edu> wrote:
>>
>> >FP is extremely hard to learn for the average mortal, even more so
>> >than OO (which they seem to have enough difficulty with),
>>
>> I'd disagree. I don't think FP is more difficult than
>> imperative/procedural programming, if it is taught first.
>
>would now be taught functional languages, it would still take twenty
>years until they arrived at position where they can decide about what
>language to use in a project.
>At that point, we'll sit in comp.lang.aop (or whatever the "best"
>paradigm at that time will be) and moan "all these functional programmer
>simply don't get it, but teaching to unspoiled kids would work"... :)
True. I think, then, the best bet is to reinforce good
abstract thinking ability. That brings us all the way
back to fundamental elements of math.
>> * My observation is that MANY students who don't initially
>> seem to have trouble with the concept of loops are completely
>> unable to follow code that has loops with arbitrary exit
>> conditions. This implies that their understanding of loops is
>> mostly idiomatic - which means idiomatic use of tail-recursion
>> for simple iterations can be taught just as easily.
>Actually both loops and tail recursion have such a complicated semantics
>that people try to avoid both if they can (assuring that the darn thing
>terminates at the exact right point, and making sure that the code works
>at the first, intermediate, and last time through is an opportunity for
>more bugs than one would like).
>That's also the reason why all functional languages have mapping
>functions, I'd think.
Well, exactly. My point was that you don't have to
teach tail-recursion any more rigorously than loops
are currently being taught, and I think it's easier
to convince yourself that a tail-recursive routine
is correct than it is to convince yourself that a
loop is correct.
Dan.
FM
>>Hmm I guess those people have a considerably different
>>approach towards programming than, say, someone like
>>myself, whose first computer, a Pentium, came bundled
>>with a bunch of commercial softwares. But then, I read
>>about computers before I really had one and thanks to
>>the archaic nature of the literature I had access to,
>>I somehow thought you had to know how to program to use
>>a computer. Ah, good old days :)
>in the days of batch systems, they wouldn't let you near a computer
>if you could program (unless you worked on the os or for a system
>where the os wasn't ready yet.
I'm not sure if I understand. What's bad about letting
a programmer near a batch system?
Dan.
Robert Virding
jam...@volition-inc.com (James Hague) writes:
> Joe Armstrong <j...@bluetail.com> wrote:
>
>> - Systems written in FPLs will be cheaper to maintain and have fewer
>> errors than systems using C.
>>
>> - Companies using FPLs will have higher profits than companies using
>> C.
>>
>> - Programmers using FPLs will be a lot more productive than
>> programmers using C.
>
>I think the key word in your post is "using." If FPLs allow you to
>be more productive, write better code, and tackle more complex
>problems, then those are great reasons to be using such languages.
>
>The trouble in c.l.f. is that there's adovacy without substance behind
>it. There's an insistence on the productivity boost provided by
>static type systems. There's a belief that what programmers really
>crave are mechanical ways of proving programs correct. There's
>misplaced enthusiasm in preaching the beauty of the lambda calculus
>and the goal of complete referential transparency. Do we have any
>real evidence for any of this? Advocating something that you do not
>use is a mistake. I also think that trying to write killer apps just
>for the sake of furthering the cause of FP is a mistake. There is no
>"cause," other than to solve the problems you need to be solving. I
>think a lot of smaller language communities (Forth, Smalltalk, Oberon,
>Eiffel, APL) have the same misunderstanding that languages are the
>end, not the means. It is hard to listen to armchair advocacy in
>general. Contest entries, textbook examples and simple utilities are
>not counterexamples.
I think you have really (REALLY) missed the point here. When talking
about Erlang and extolling its virtues we are talking from experience.
We use the language in our products, Ericsson has used it in products
and we have practical experience to back up our claims.
There is no advocacy without substance here. The problem in spreading
functional languages is not technical, the benefits are real. The
problem is winning the hype war.
--
Robert Virding Tel: +46 (0)8 545 55 017
Bluetail AB Email: r...@bluetail.com
S:t Eriksgatan 44 WWW: http://www.bluetail.com/~rv
SE-112 32 Stockholm, SWEDEN
"Folk säger att jag inte bryr mig om någonting, men det skiter jag i".
Michael Feathers
If you get a chance, take a look at
Richard Gabriel's essay "The End of History
and the Last Programming Language"
in his book Patterns of Software.
He makes the case that to become dominant,
a general purpose language must have a simple
performance model and not require mathematical
sophistication for use.
Interesting quote:
"One of the things that I learned by watching
people try to learn LISP is that they could
write programs that worked pretty well
but they could not write fast programs.
The reason was that they did not know how
things were implemented and assumed that
anything in the language manual took a small
constant time."
While I think FP languages can make inroads,
but I don't think that they could become
dominant unless several things happen:
1) a severe fall off in demand for software,
so much so that only employers could staff
sufficiently with only those few who are able
to work in an FP, and
2) clear and convincing evidence that FPs
are cost effective and suitable for large scale
software development where requirements
flux over time.
I want to find out more about the probability
of (2), but I think that (1) will hold it at bay
for a while.
Michael
---------------------------------------------------
Michael Feathers mfea...@objectmentor.com
Object Mentor Inc. www.objectmentor.com
XP & OO Training/Mentoring/Development
www.xprogramming.com / www.junit.org
---------------------------------------------------
"You just keep going all the way, as deep as
you can. You keep trying to get right down
to the crux." -- John Coltrane
Garry Hodgson
in my day, son, you couldn't write programs for your computer until
you built it :-)
--
Garry Hodgson Once in a while
Senior Hacker you can get shown the light
Software Innovation Services in the strangest of places
AT&T Labs if you look at it right
Rainer Joswig
<mfea...@objectmentor.com> wrote:
> He makes the case that to become dominant,
> a general purpose language must have a simple
> performance model and not require mathematical
> sophistication for use.
But sorry, neither Java, VB nor C++ have
a simple performance model.
Not even have the implementations of those
a simple performance model (other than
everything is slow), not their libraries
or the platforms they are running on.
The "performance model" also crucially depends on
the data structures and algorithms used.
CS students are learning this very early.
> Interesting quote:
> "One of the things that I learned by watching
> people try to learn LISP is that they could
> write programs that worked pretty well
> but they could not write fast programs.
> The reason was that they did not know how
> things were implemented and assumed that
> anything in the language manual took a small
> constant time."
One thing that people learn in CS lectures
very early is to care about these things.
> 2) clear and convincing evidence that FPs
> are cost effective and suitable for large scale
> software development where requirements
> flux over time.
Just look on the site of Franz inc. for a description
of some of their customer's projects. There are quite a few
people who are using Lisp for applications.
Lisp is still the most widely used language with
good support for FP.
--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Craig Brozefsky
> in my day, son, you couldn't write programs for your computer until
> you built it :-)
In my day you couldn't write programs until your mother took you to
the department store and mistakenly left you alone for a few minutes
near the Electronics department with the Commie64 display units. Then
all you could write was:
10 PRINT "I ROCK!"
20 GOTO 10
I ROCK!
I ROCK!
I ROCK!
I ROCK!
I ROCK!
I ROCK!
...
--
Craig Brozefsky <cr...@red-bean.com>
LispWeb -- Mailing list for Lisp Based Web Development
Homepage: http://www.red-bean.com/lispweb
Yiorgos Adamopoulos
>near the Electronics department with the Commie64 display units. Then
>all you could write was:
>
>10 PRINT "I ROCK!"
>20 GOTO 10
My version was
10 PRINT "C64 RULES!"
20 GOTO 10
Bruce Hoult
<ga...@sage.att.com> wrote:
> in my day, son, you couldn't write programs for your computer until
> you built it :-)
Ah well I'm a young 'un -- the TRS-80, Pet and Apple ][ were available
by the time I was in late highschool. And I had access to a B1700 as
well.
-- Bruce
Hartmann Schaffer
FM <da...@dartmouth.edu> wrote:
>Hartmann Schaffer <h...@paradise.nirvananet> wrote:
>
>>>Hmm I guess those people have a considerably different
>>>approach towards programming than, say, someone like
>>>myself, whose first computer, a Pentium, came bundled
>>>with a bunch of commercial softwares. But then, I read
>>>about computers before I really had one and thanks to
>>>the archaic nature of the literature I had access to,
>>>I somehow thought you had to know how to program to use
>>>a computer. Ah, good old days :)
>
>>in the days of batch systems, they wouldn't let you near a computer
>>if you could program (unless you worked on the os or for a system
>
>I'm not sure if I understand. What's bad about letting
>a programmer near a batch system?
you better ask the people who set up the system ;-). typically on
those systems was that the programmers wrote there code on form
sheets, the it was handed over to the punching department, and with
some luck you got back a card deck whose contents resembled what you
had written down. you attached a couple of job control cards to it,
handed the whole thing over to an input desk, and some time later it
came back together with a printout. after studying the printout you
did whatever modifications were needed to your card deck and went back
to the input desk. i went through that for a while before the
hardware for our new system was ready and everything was run on a
simulator on the predecessor hardware. things became better when the
first hardware arrived.
i suspect the reason behind that setup was that machine time was
incredibly expensive. with this setup you maximized the use of the
cpu. obviously, it wasn't very good for the development process,
sothis setup wasn't very long lived (at least in my experience)
hs
Kragen Sitaker
My version was:
TO EAT:
PRINT [OM]
EAT2
TO EAT2:
PRINT [NOM]
EAT2
Logo doesn't really qualify as on-topic here, does it? But at least
I'm demonstrating tail-recursion ;)
--
<kra...@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we ourselves
possess.
-- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"]
Joachim Durchholz
>
> True. I think, then, the best bet is to reinforce good
> abstract thinking ability. That brings us all the way
> back to fundamental elements of math.
I don't think that teaching fundamental elements of math is going to
help. It isn't even know which fundamental elements of math are relevant
to programming: arithmetics? set theory? intuition for creating proofs?
enough general mathematical knowledge so that it all "just sticks
together"? analysis? I've seen *all* of these claimed to be essential
for programmers. The problem is, it's clearly too much to teach
everybody in the hopes of creating enough students who are fit for IT -
society needs carpenters, metal workers, secretaries, etc. etc. -
teaching everybody enough to become fit for programming would be a waste
of ressources.
I think a different approach is going to work better. Write a few books
that can be read by the average student, explaining higher-order
functions, monads and recursion in friendly terms, and include a few
simple(!) examples that show how these are useful.
Imperative languages have exactly the same difficult concepts. They're
just hidden better.
What's a higher-order function? A routine that takes a function pointer
as an argument.
What's a monad? A list of function pointers, plus parameters, ready to
be fired off somewhere in the course of system execution.
What's recursion? A function that calls itself (and make sure that the
parameters of the recursive call are guaranteed to be "nearer" towards
the nonrecursive case so that the darn thing will terminate).
What's a loop, and why is it difficult to get it right? Because you must
get the loop invariant right (and avoiding the invariant by not writing
it down just makes matters more difficult).
> >> * My observation is that MANY students who don't initially
> >> seem to have trouble with the concept of loops are completely
> >> unable to follow code that has loops with arbitrary exit
> >> conditions. This implies that their understanding of loops is
> >> mostly idiomatic - which means idiomatic use of tail-recursion
> >> for simple iterations can be taught just as easily.
>
> >Actually both loops and tail recursion have such a complicated
> >semantics that people try to avoid both if they can (assuring
> >that the darn thing terminates at the exact right point, and
> >making sure that the code works at the first, intermediate, and
> >last time through is an opportunity for more bugs than one would
> >like).
> >That's also the reason why all functional languages have mapping
> >functions, I'd think.
>
> Well, exactly. My point was that you don't have to
> teach tail-recursion any more rigorously than loops
> are currently being taught, and I think it's easier
> to convince yourself that a tail-recursive routine
> is correct than it is to convince yourself that a
> loop is correct.
Agreed.
I just wanted to point out that all newer languages try to get around
loops/recursion as much as possible. They use iterators, mapping
functions, or whatever to do that. I'm speculating, but it might be
possible to entirely avoid teaching loops in undergraduate courses.
FM
>> True. I think, then, the best bet is to reinforce good
>> abstract thinking ability. That brings us all the way
>> back to fundamental elements of math.
>I don't think that teaching fundamental elements of math is going to
>help. It isn't even know which fundamental elements of math are relevant
>to programming: arithmetics? set theory? intuition for creating proofs?
>enough general mathematical knowledge so that it all "just sticks
>together"? analysis? I've seen *all* of these claimed to be essential
>for programmers.
Well it's really understanding of all these beyond the bare
surface. Ability to understand the abstract that can't always
be explained in relation to the concrete. I don't think it
has much to do with "knowledge" as much as it has to do with
ability to deal with given knowledge. That's what really math
is all about, and I think teaching not math, but rather
practical applications of math in ways that are so removed
from fundamentals, is a problem. Another, of course, is that
math is simply not taught as much as it should.
>The problem is, it's clearly too much to teach
>everybody in the hopes of creating enough students who are fit for IT -
>society needs carpenters, metal workers, secretaries, etc. etc. -
>teaching everybody enough to become fit for programming would be a waste
>of ressources.
Actually, no, I think fundamental math is important for most
high-paying jobs and many medium-paying jobs. I get extremely
frustrated when a clerk goes looking for a calculator because
he can't subtract 15 cents from five dollars and ten cents.
The society doesn't need carpenters or metal workers more than
they need good programmers; otherwise, they'd get paid more
than programmers.
>I think a different approach is going to work better. Write a few books
>that can be read by the average student, explaining higher-order
>functions, monads and recursion in friendly terms, and include a few
>simple(!) examples that show how these are useful.
I'd say that if a student is dependent on "simple" examples
and friendly terms (analogies), then he/she lacks ability to
think abstractly. It is possible to get difficult concepts
across this way, but it's hard to come up with explanations
that will work for all (or even most) such students.
>Imperative languages have exactly the same difficult concepts. They're
>just hidden better.
Well, yeah, I think for the non-mathematically inclined,
the idea of giving the machine a series of instructions is
an easier analogy to grasp at first, then the idea of
functional abstraction. Of course, functional abstraction
should be understood very well at some point, if one was
to be a good programmer, regardless of the language.
Dan.
Matthias Blume
> FM <da...@dartmouth.edu> wrote:
> >
> > True. I think, then, the best bet is to reinforce good
> > abstract thinking ability. That brings us all the way
> > back to fundamental elements of math.
>
> I don't think that teaching fundamental elements of math is going to
> help. It isn't even know which fundamental elements of math are relevant
> to programming: arithmetics? set theory? intuition for creating proofs?
logic.
> enough general mathematical knowledge so that it all "just sticks
> together"? analysis? I've seen *all* of these claimed to be essential
> for programmers. The problem is, it's clearly too much to teach
> everybody in the hopes of creating enough students who are fit for IT -
> society needs carpenters, metal workers, secretaries, etc. etc. -
> teaching everybody enough to become fit for programming would be a waste
> of ressources.
>
> I think a different approach is going to work better. Write a few books
> that can be read by the average student, explaining higher-order
> functions, monads and recursion in friendly terms, and include a few
> simple(!) examples that show how these are useful.
>
> Imperative languages have exactly the same difficult concepts. They're
> just hidden better.
> What's a higher-order function? A routine that takes a function pointer
> as an argument.
> What's a monad? A list of function pointers, plus parameters, ready to
> be fired off somewhere in the course of system execution.
> What's recursion? A function that calls itself (and make sure that the
> parameters of the recursive call are guaranteed to be "nearer" towards
> the nonrecursive case so that the darn thing will terminate).
> What's a loop, and why is it difficult to get it right? Because you must
> get the loop invariant right (and avoiding the invariant by not writing
> it down just makes matters more difficult).
>
> > >> * My observation is that MANY students who don't initially
> > >> seem to have trouble with the concept of loops are completely
> > >> unable to follow code that has loops with arbitrary exit
> > >> conditions. This implies that their understanding of loops is
> > >> mostly idiomatic - which means idiomatic use of tail-recursion
> > >> for simple iterations can be taught just as easily.
> >
> > >Actually both loops and tail recursion have such a complicated
> > >semantics that people try to avoid both if they can (assuring
> > >that the darn thing terminates at the exact right point, and
> > >making sure that the code works at the first, intermediate, and
> > >last time through is an opportunity for more bugs than one would
> > >like).
> > >That's also the reason why all functional languages have mapping
> > >functions, I'd think.
> >
> > Well, exactly. My point was that you don't have to
> > teach tail-recursion any more rigorously than loops
> > are currently being taught, and I think it's easier
> > to convince yourself that a tail-recursive routine
> > is correct than it is to convince yourself that a
> > loop is correct.
>
> Agreed.
> I just wanted to point out that all newer languages try to get around
> loops/recursion as much as possible. They use iterators, mapping
> functions, or whatever to do that. I'm speculating, but it might be
> possible to entirely avoid teaching loops in undergraduate courses.
>
> Regards,
> Joachim
> --
> This is not an official statement from my employer or from NICE.
>
>
--
Matthias
--
Matthias Blume <blume@k_u_r_i_m_s.k_y_o_t_o-u.a_c.j_p>
Kyoto University, Research Institute for Mathematical Sciences
(remove those spam-preventing underscores from mail address)
Christian Stapfer
...
> Actually, no, I think fundamental math is important for most
> high-paying jobs and many medium-paying jobs. I get extremely
> frustrated when a clerk goes looking for a calculator because
> he can't subtract 15 cents from five dollars and ten cents.
Funny, this reminds me of a quite famous mathematician,
Henri Poincaré, who wrote that he could hardly add two
numbers without making a mistake:
»C'est Gauss, au contraire, qui était une exception.
Quant à moi, je suis obligé de l'avouer, je suis
absolument incapable de faire une addition sans faute.«
- Henri Poincaré: 'Science et Méthode'
So mere calculation is really a rather bad example for
what math is all about...
As regards an overly hasty use of abstraction in
mathematics (aka "soft" mathematics), there are other
well-known mathematicians who think *concrete* examples
to be very important for how their minds work:
»Where do the good questions, the research problems,
come from? .. One thing is sure: they do *not* come
from a vague desire to generalize. Almost the
opposite is true: the source of all great mathematics
is the special case, the *concrete example*.«
...
»A good stock of examples, as large as possible, is
indispensable for a *thorough* understanding of *any*
concept, and when I want to *learn* something new,
I make it my first job to build one.«
- Paul R. Halmos: 'I Want to be a Mathematician'
(my emphasis *..*)
So there is a lurking suspicion that people who denigrate
the use of concrete examples in math are simply hiding
(from others, and maybe even from themselves) where their
own intuition as regards wonderfully abstract math came
from.
On the other hand, I would certainly agree that what
has been called 'mathematical maturity' would be a good
thing for a programmer to have - though I have no idea
whether this would make him get a job, much less a well-paid
one.
.. Hmm, maybe as long as the economy is still booming.
But then, if the economy is booming, anyone can get a job.
If, however, the economy is *not* booming, then carpenters
might conceivably get a job while many programmers won't
get one anymore (not even one to develop "e-commerce crap") ...
> The society doesn't need carpenters or metal workers
> more than they need good programmers; otherwise,
> they'd get paid more than programmers.
Maybe you just haven't figured yet that there are a
few *other* mechanisms at work, besides The Market,
as regards the level of payment? There is rampant
credentialism, there is the sinecure system, ...
»An open, unhypocritical recognition of the sinecure
component in our society would certainly constitute
a cultural revolution in public honesty and would
make it easier to assess and control the effects of
the factors affecting sinecures.«
- Randall Collins: 'The Credential Society'
And certainly, as a rule, even relatively lousy managers
get paid more than their, perhaps quite good programmers
- but is this because "society" *needs* them more? or
because what they do requires a *higher* degree of
mathematical maturity? or because there are too few
applicants for management jobs? - I rather doubt it.
Christian Stapfer
Joachim Durchholz
> Joachim Durchholz <joac...@gmx.de> wrote:
>
> >The problem is, it's clearly too much to teach
> >everybody in the hopes of creating enough students who are fit for
IT -
> >society needs carpenters, metal workers, secretaries, etc. etc. -
> >teaching everybody enough to become fit for programming would be a
waste
> >of ressources.
>
> high-paying jobs and many medium-paying jobs. I get extremely
> frustrated when a clerk goes looking for a calculator because
> he can't subtract 15 cents from five dollars and ten cents.
> they need good programmers; otherwise, they'd get paid more
> than programmers.
Society doesn't need as many programmers as secretaries, so making a
programming-centered education would be more than required.
Of course, if 5.10-0.10 is too much for a clerc, then he's clearly
undereducated, but not in the area of abstraction but in the area of
practical exercize. I had a similar problem, though on a higher level: I
knew all the principles of symbolic equation solving, yet I couldn't
actually go forth and apply these principles to practical problems (and
the same held for most if not all of my peer students). This persisted
for a year or two until we got a physics teacher who simply didn't
accept that, and tortured us with practical exercises for a year. After
that, I was fit - but since that time, I know it's possible to have too
much theory and too little practice. (And I still cannot solve all
integrals that are standard issue, even though I know all the
principles. Again, all theory and no practice.)
> >I think a different approach is going to work better. Write a few
books
> >that can be read by the average student, explaining higher-order
> >functions, monads and recursion in friendly terms, and include a few
> >simple(!) examples that show how these are useful.
>
> I'd say that if a student is dependent on "simple" examples
> and friendly terms (analogies), then he/she lacks ability to
> think abstractly. It is possible to get difficult concepts
> across this way, but it's hard to come up with explanations
> that will work for all (or even most) such students.
I don't think so. Abstractions used in programming are an order of
magnitude simpler to grasp than abstractions like monads, categories,
and higher-order functions plus their implications about what they can
do and what they cannot.
I found this out even in this group. There's that thread about comparing
infinite lists. I've seen a whole host of answers about how to make it
possible, but only one person noted that comparing infinite lists in
general is undecidable. If functional programmers would really work and
think on a high level of abstraction, this would have been the first
reply, not the last one!
> >Imperative languages have exactly the same difficult concepts.
They're
> >just hidden better.
>
> Well, yeah, I think for the non-mathematically inclined,
> the idea of giving the machine a series of instructions is
> an easier analogy to grasp at first, then the idea of
> functional abstraction. Of course, functional abstraction
> should be understood very well at some point, if one was
> to be a good programmer, regardless of the language.
Agreed.
But it's simply not *necessary* to use category theory to explain
monads. It's *not necessary* to explain fixed-point theory to explain
recursion.
Theory comes into play when people want to understand a phenomenon. So,
if they find that loops are difficult to write, and recursion is
difficult to make terminate, *then* is the right moment to explain fixed
points. But programmers should have a firm intuition about how the
concepts behave and interact before delving deeply into theory. People
don't grasp theory unless they want to, and they will (usually) not want
to before they see that it's immediately useful.
Programming is an abstract enough activity to discourage people; insisti
ng on theory before they can make use of it will just drive off even
more of them. End result: theory will be decried as "academic", and
people will program in less powerful but easier-to-understand
languages... er, you say it's already happening and called Java or
(yuck) Visual Basic? ;))
Boris * (1+(is->cic))
>
> Programming is an abstract enough activity to discourage people; insisti
> ng on theory before they can make use of it will just drive off even
> more of them. End result: theory will be decried as "academic", and
> people will program in less powerful but easier-to-understand
> languages... er, you say it's already happening and called Java or
> (yuck) Visual Basic? ;))
Yet I am not convinced that even VB and a fortiori Java attract
not because they are "simple" but on the contrary because they
look complicated enough to impress...
BB
--
"C++ is a contradiction in terms" -- Einstein
FM
>FM wrote:
>> Actually, no, I think fundamental math is important for most
>> high-paying jobs and many medium-paying jobs. I get extremely
>> frustrated when a clerk goes looking for a calculator because
>> he can't subtract 15 cents from five dollars and ten cents.
>Funny, this reminds me of a quite famous mathematician,
>Henri Poincaré, who wrote that he could hardly add two
>numbers without making a mistake:
>
> »C'est Gauss, au contraire, qui était une exception.
> Quant à moi, je suis obligé de l'avouer, je suis
> absolument incapable de faire une addition sans faute.«
> - Henri Poincaré: 'Science et Méthode'
>
>So mere calculation is really a rather bad example for
>what math is all about...
Yeah. I guess that example completely contradicted what I was
actually trying to say.
> As regards an overly hasty use of abstraction in
>mathematics (aka "soft" mathematics), there are other
>well-known mathematicians who think *concrete* examples
>to be very important for how their minds work:
>
> »Where do the good questions, the research problems,
> come from? .. One thing is sure: they do *not* come
> from a vague desire to generalize. Almost the
> opposite is true: the source of all great mathematics
> is the special case, the *concrete example*.«
> ...
Well, but that process of generalization IS the essence of
Mathematics, and *of course* the process begins with a
concrete example.
> »A good stock of examples, as large as possible, is
> indispensable for a *thorough* understanding of *any*
> concept, and when I want to *learn* something new,
> I make it my first job to build one.«
> - Paul R. Halmos: 'I Want to be a Mathematician'
> (my emphasis *..*)
I actually agree with this. What I insinuated in the earlier
post was that one shouldn't count on other people providing
examples, but must be able to come up with his/her own. That
is a large part of what I consider the ability to understand
abstract concepts.
>So there is a lurking suspicion that people who denigrate
>the use of concrete examples in math are simply hiding
>(from others, and maybe even from themselves) where their
>own intuition as regards wonderfully abstract math came
>from.
I gave some thoughts to this concrete-abstract dichotomy in
regards to human understanding of concepts. I don't think
anyone can actually claim to understand an idea that is
completely abstract to him/herself. Understanding of an
abstract idea usually involves the creation of a concrete
referent in one's mind, which in turn involves relation to
other concrete things that one is already familiar with. To
understand an abstract idea well, one must have a rather
thorough mental model of it, which is somewhat concrete. So
this "abstract thinking ability" might just be the ability
to recognize abstract concepts and build concrete models
with them. The ability to of course create abstractions from
the concrete, of course, is another side of that.
> On the other hand, I would certainly agree that what
>has been called 'mathematical maturity' would be a good
>thing for a programmer to have - though I have no idea
>whether this would make him get a job, much less a well-paid
>one.
> .. Hmm, maybe as long as the economy is still booming.
>But then, if the economy is booming, anyone can get a job.
>If, however, the economy is *not* booming, then carpenters
>might conceivably get a job while many programmers won't
>get one anymore (not even one to develop "e-commerce crap") ...
Interesting. But is it easier for a programmer to become a
carpenter or for a carpenter to become a programmer?
>> The society doesn't need carpenters or metal workers
>> more than they need good programmers; otherwise,
>> they'd get paid more than programmers.
>Maybe you just haven't figured yet that there are a
>few *other* mechanisms at work, besides The Market,
>as regards the level of payment? There is rampant
>credentialism, there is the sinecure system, ...
> »An open, unhypocritical recognition of the sinecure
> component in our society would certainly constitute
> a cultural revolution in public honesty and would
> make it easier to assess and control the effects of
> the factors affecting sinecures.«
> - Randall Collins: 'The Credential Society'
>And certainly, as a rule, even relatively lousy managers
>get paid more than their, perhaps quite good programmers
Do they? But many good programmers also don't work under
managers, right?
>- but is this because "society" *needs* them more? or
>because what they do requires a *higher* degree of
>mathematical maturity? or because there are too few
>applicants for management jobs? - I rather doubt it.
Well my logic was far too simplistic, but I'd still argue
that good programming ability is much more desired and
harder to acquire.
Dan.
FM
>> high-paying jobs and many medium-paying jobs. I get extremely
>> frustrated when a clerk goes looking for a calculator because
>> he can't subtract 15 cents from five dollars and ten cents.
>> The society doesn't need carpenters or metal workers more than
>> they need good programmers; otherwise, they'd get paid more
>> than programmers.
>Society doesn't need as many programmers as secretaries, so making a
>programming-centered education would be more than required.
Are you sure about that? And I don't think what I'm arguing
for is really a programming-centered education, but rather
abstract-thinking-centered education, which I believe, should
be helpful in most intellectual endeavors.
>Of course, if 5.10-0.10 is too much for a clerc, then he's clearly
>undereducated, but not in the area of abstraction but in the area of
>practical exercize. I had a similar problem, though on a higher level: I
>knew all the principles of symbolic equation solving, yet I couldn't
>actually go forth and apply these principles to practical problems (and
>the same held for most if not all of my peer students). This persisted
>for a year or two until we got a physics teacher who simply didn't
>accept that, and tortured us with practical exercises for a year. After
>that, I was fit - but since that time, I know it's possible to have too
>much theory and too little practice. (And I still cannot solve all
>integrals that are standard issue, even though I know all the
>principles. Again, all theory and no practice.)
Hmm, one's understanding of abstract concepts is demonstrated
by the ability to apply them to the concrete examples, no? Well
I guess there's also a matter of practice (I, too, am horribly
out of practice for some mathematical concepts that I learned
and used successfully in the past). I don't think you'd have
trouble solving integrals once you learn some techniques and
start practicing a bit. Whether you'd want to, is another
question.
>> >I think a different approach is going to work better. Write a few
>books
>> >that can be read by the average student, explaining higher-order
>> >functions, monads and recursion in friendly terms, and include a few
>> >simple(!) examples that show how these are useful.
>> I'd say that if a student is dependent on "simple" examples
>> and friendly terms (analogies), then he/she lacks ability to
>> think abstractly. It is possible to get difficult concepts
>> across this way, but it's hard to come up with explanations
>> that will work for all (or even most) such students.
>I don't think so. Abstractions used in programming are an order of
>magnitude simpler to grasp than abstractions like monads, categories,
>and higher-order functions plus their implications about what they can
>do and what they cannot.
Well, I'm not sure which part you're disagreeing with, but if
there are explanations that will work for all people, there would
never be any need for teaching (especially small-scale) per se,
since standard explanations can be always published and shared. I
understand that good teaching would involve tailoring the concepts
to relate them to what the students already know, but coming up
with explanations that will work for all or even most students is
extremely difficult and eventually, the best explanation you'll
ever get is the one you come up with yourself. And I believe good
fundamental math education, especially for the young, is important
in developing that ability.
>I found this out even in this group. There's that thread about comparing
>infinite lists. I've seen a whole host of answers about how to make it
>possible, but only one person noted that comparing infinite lists in
>general is undecidable. If functional programmers would really work and
>think on a high level of abstraction, this would have been the first
>reply, not the last one!
Ouch, that's so true. I kinda just skipped over, I guess because
the idea of comparing infinite lists was intuitively silly to me.
I'm sure others have also thought of it, though, they haven't
formalized it to use the notion of undecidability.
>But it's simply not *necessary* to use category theory to explain
>monads. It's *not necessary* to explain fixed-point theory to explain
>recursion.
>Theory comes into play when people want to understand a phenomenon. So,
>if they find that loops are difficult to write, and recursion is
>difficult to make terminate, *then* is the right moment to explain fixed
>points. But programmers should have a firm intuition about how the
>concepts behave and interact before delving deeply into theory. People
>don't grasp theory unless they want to, and they will (usually) not want
>to before they see that it's immediately useful.
>Programming is an abstract enough activity to discourage people; insisti
>ng on theory before they can make use of it will just drive off even
>more of them. End result: theory will be decried as "academic", and
>people will program in less powerful but easier-to-understand
>languages... er, you say it's already happening and called Java or
>(yuck) Visual Basic? ;))
Well, I don't think I was really insisting on theory per se (kind
of hard to do that as I'm not too familiar with many of these
theories myself, though I should be in a few years :), but more
that good fundamental math education emphasizing abstract concepts
and ability to digest them would be helpful, for programming and
for other intellectual fields.
Dan.
Christian Stapfer
...
> There's that thread about comparing infinite lists.
> I've seen a whole host of answers about how to make
> it possible, but only one person noted that comparing
> infinite lists in general is undecidable. If functional
> programmers would really work and think on a high level
> of abstraction, this would have been the first reply,
> not the last one!
You are mistaken: the very *first* answer, by Marcin
'Qrczak' Kowalczyk, was a simple "No" (i.e. there is
*no* way to test equality of infinite lists in the
general case). It seems that he expected other readers
to be able to figure out by themselves why this is so.
That's, at least, how I read his answer - and I suppose
many others did as well.
A tendency *not* to belabor trivialities does *not*
prove one's powers of abstraction to be rather limited...
Christian
Joachim Durchholz
> Joachim Durchholz wrote:
>
> ...
> > There's that thread about comparing infinite lists.
> > I've seen a whole host of answers about how to make
> > it possible, but only one person noted that comparing
> > infinite lists in general is undecidable. If functional
> > programmers would really work and think on a high level
> > of abstraction, this would have been the first reply,
> > not the last one!
>
> 'Qrczak' Kowalczyk, was a simple "No" (i.e. there is
> *no* way to test equality of infinite lists in the
> general case).
Well, this *may* indicate that Marcin indeed knew it's undecidable. Then
again, it may not. A lot of other people supposed be thinking in an
abstract way obviously didn't.
Actually I think it's a positive sign. If people who don't think in the
most abstract ways feel qualified to answer such questions, then this
means that the FP community isn't as "academic" as is commonly assumed.
(Even if that means that this particular question wasn't answered well -
such questions don't come up very often after all!)
peter_d...@my-deja.com
"Adrian May" <adria...@t-online.de> wrote:
> If anything wipes out C++ it'll be Visual Basic. Why? Because
programming
> is still too difficult. Theres masses of work to do and not enough
people
> who know how to do it. My old managers used to say to me:
>
> "We'd love to do it all in C++, but then you would be all on your own
> (unless you know another decent programmer). So the other half of
your
> project is going to be done in VB."
>
> That manager wasn't dumb, he had his hands tied behind his back. I
didnt
> mention Haskell.
>
> FP is extremely hard to learn for the average mortal, even more so
than OO
> through not understanding subtleties like tail recursion. Another
example
> is that Java expected more success in the web, but it seems that
people just
> one clunk-clunk languages like Perl.
>
> Adrian.
>
>
Several things I'd like to say on this thread.
One, having learned OO/C++, I must strongly disagree that FP is more
difficult. Actually I think good OO is beyond the reach of the average
mortal (which is one reason there is so much bad OO code).
Two, this whole thead (not this particular post) is filled with a
Dilbert view of management. However, intelligent managers understand
that C/C++ programmers are to be found everywhere, while FP programmers
are few and far between. Code needs to be maintained. Unless there is
a critical mass of FP programmers around, it is very risky for a
manager to have code developed in a language/style for which she cannot
obtain a ready replacement programmer. Following the crowd makes good
sense on an individual level, even if the crowd as a whole is not
making intelligent choices.
--PeterD
Sent via Deja.com http://www.deja.com/
Before you buy.
Friedrich Dominicus
> >
>
> Several things I'd like to say on this thread.
> One, having learned OO/C++, I must strongly disagree that FP is more
> difficult. Actually I think good OO is beyond the reach of the average
> mortal (which is one reason there is so much bad OO code).
You see how different opinions are. I do think OO is easier to learn
than FP, but both take their time. I do think that OO with C++ is more
difficult as it should be. But there are other languages in which
getting the OO-way is easier among them are
Smalltalk, Python, Ruby, Eiffel, Sather
It may be that even CLOS is easier to grasp but I guess most start
with Lisp from the functional size. And there is Java of course. I do
think that the amazing success story of Java shows that Joe average
can learn it. In short I disagree that learning OO is more difficult
than FP is.
I do think that I'm an average (surely in some parts below average in
some parts above) mortal, and it took me around a year or
a bit more to graps OO. I'm now winding my head around FP and I do
think within a year and a bit I will get the FP-way too.
That does not mean that I will master it completly. But I will feel
comfortable. Just a short remark. It took me one year to learn OO but
it took me at least another year of very intensive work with an OO-language to
understand that language.
Ths problem it how many people can afford to spend up to half of their
time for educating themselves further. It's possibly hard enough to
follow the development and extensions you favourite language, to be
up-to date. So most of the programmers do not find the time trying
someting completly different. And without really working with some
language won't make one usually a good fellow.
Regards
Friedrich
--
for e-mail reply remove all after .com
Clayton Weaver
[snip]
> I think a different approach is going to work better. Write a few books
> that can be read by the average student, explaining higher-order
> functions, monads and recursion in friendly terms, and include a few
> simple(!) examples that show how these are useful.
Detailed, explicit operational explanations are what work. Sure, you need
to explain the set theoretic, categoric, and/or algebraic basis for the
soundness ("works in all cases") of what you are explaining, in notes or
appendices if nothing else, but understanding what happens operationally
for a given functional expression is what sheds light on language
semantics for the beginner, because most programmers at any level
understand that programs perform operations. They intuitively
comprehend "do this next", ie assembler, fortran I, ..., so if you
explain the semantics of a functional language in terms of the implied
operations, they'll get it.
Stepping up to "it does some things in any order or in parallel" is not
that big of a conceptual jump, as long as the beginner is told exactly
what are those things that the program does.
[snip]
Regards,
--
Clayton Weaver
<mailto:cgw...@eskimo.com>
(Seattle)
Michael Schuerig
> And there is Java of course. I do think that the amazing success story of
> Java shows that Joe average can learn it. In short I disagree that
> learning OO is more difficult than FP is.
What most people do with Java hardly resembles OO. And even a year of
using Java and nominally working in an OO-fashion isn't guaranteed to
change this. Doing OO, and in particular doing it right, is very hard. I
don't claim that it's harder than it could or should be. I'm curious to
find out if an FP approach makes life comparatively easier or if the
complexity is somehow inherent in most interesting problems.
Michael
--
Michael Schuerig
mailto:schu...@acm.org
http://www.schuerig.de/michael/
Friedrich Dominicus
> Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
>
> > And there is Java of course. I do think that the amazing success story of
> > Java shows that Joe average can learn it. In short I disagree that
> > learning OO is more difficult than FP is.
>
> What most people do with Java hardly resembles OO. And even a year of
> using Java and nominally working in an OO-fashion isn't guaranteed to
> change this. Doing OO, and in particular doing it right, is very
>hard.
Now I mentioned that mastering is the problem, but the basics are IMHO
equally difficult/easy to get.
> I
> don't claim that it's harder than it could or should be. I'm curious to
> find out if an FP approach makes life comparatively easier or if the
> complexity is somehow inherent in most interesting problems.
I think this is an open question. And we hardly will find out because
it would take really much time and effort to find out. I suggest
lookin into Peter G. Gabriels Patterns of Software in which he stated
this too. Another article was about the end of language development
and that Academia does not dare, have the patience or whatever to look
beyond micro benchmarks. If people in that area don't do it, hardly
anyone will do it, so long all we do and say is more or less personal
opinion. And I mentioned mine, it's one out of some millions, and is
hardly the "rigth" one.
Michael Schuerig
> > I don't claim that it's harder than it could or should be. I'm curious
> > to find out if an FP approach makes life comparatively easier or if the
> > complexity is somehow inherent in most interesting problems.
>
> I think this is an open question. And we hardly will find out because
> it would take really much time and effort to find out. I suggest
> lookin into Peter G. Gabriels Patterns of Software in which he stated
> this too.
I tried to look any of his albums of that name, but was unsuccessful.
Oops ;-)
Anyway, I also tried to look it up in Richard P. Gabriel's book and
didn't find it either. Though I stumbled upon a quote that's so nice
that I just have to tear it utterly out of context:
"Wade [Hennesey's] Maxim: No one ever made money by typing."
(RPG, Patterns of Software, p. 225)
SCNR,
Friedrich Dominicus
>
> I tried to look any of his albums of that name, but was unsuccessful.
> Oops ;-)
>
> Anyway, I also tried to look it up in Richard P. Gabriel's book and
> didn't find it either. Though I stumbled upon a quote that's so nice
> that I just have to tear it utterly out of context:
>
> "Wade [Hennesey's] Maxim: No one ever made money by typing."
>
> (RPG, Patterns of Software, p. 225)
Ok, now give me another try:
Richard P. Gabriel Patterns of Software (Tales from the Software
Community)
p127ff some parts
- We need a reliably measured productivity baseline ...
- We need to study rigorously the effects of programming language
choice on productivity; that is, we need numbers from controlled
experiments ....
a lot of other things Academia ought to do but seems to refuse to
do. The closest I got to this was done by NASA and someone in Germany
about one problem about encoding Telephon Numbers. That's not all too
much, but the data were quite interesting. Probably ICFP is another
good try.
On of the things he concluded on page 121.
"Right now the history of programming languages is at an end, and the
last programming language is C."
So why bother about OO and FP ;-)
I wonder what he would say about Java.
Daniel C. Wang
schu...@acm.org (Michael Schuerig) writes:
{stuff deleted{
> Well, after the recent contest someone in this group suggested that the
> people on the leading teams would probably perform almost equally well
> in other languages.
>
> I'm no social scientist and I have no real idea how to get significant
> empirical results concerning the influences of programming language
> choice. I do see significant difficulties:
I've thought about this... and have some small background in social science
so I'll play pundent for now...
> - It's no use comparing toy programs. Results need to be based on
> real-world systems.
This is an unrealistic requirment. It's like saying it's no use to build a
rocket that just orbits the earth we've got to build a rocket that goes to
the moon today right now....
Another way to say it is that a real controlled experiment on real world
systems is an amazingly complex thing to do. So complex, the only resonable
way to do it "right" is to take several partial steps that aren't really
what you want, but make significant progress in the right direction and
validate important assumptions.
I think the PL community must be willing to do limited "toy experiments" and
accept the fact that even "toy" experiments are important. People, just need
to be clear about not making unresonable claims or extrapolations from
them.
> - It's hard to ensure that teams are comparably competent. I don't even
> know how to operationalize th`is.
There are techniques that let you avoid having to have to equally competent
teams. One simple way is just to have all teams do both problems. You have
to be careful to vary the order in which the teams solve the problems. So
that half the teams do it the problem in language A first then the same
problem in language B second the other half does the problem in reverse. If
you do this with enough teams you have enough data to look at and make some
conclusions.
The first thing you do is see if the order in which the teams did the
problem effects the results. Since both teams solved the same problem twice
only with different programming languages you expect to see a 'learning
effect' i.e. the second time around should be easier than the first.
What is interesting to look at is if the "learning effect" for those who did
problem in language A is significantly different from those who did the
problem in langauge B first. If the learning effect is the same across both
groups then you know that any learning effect is generic. If they are not
the same you can conclude that one langauge "warps the minds of the
programmers" more or less than the other.
After correcting for the learning effect you can then see if those who
solved problem with langauge A did better than those who solved problem with
language B. Since the average competence of those who did A and those who
did B is the same, one can reasonably conclude that all differences are
based on the progamming language.
This is a pretty common well understood technique in experimental
psychology. A discipline where the majority of peer reviewed articles are
about experiments with samples of between 20 - 30 colleage age
students. Psychologists aren't afraid to make *limited* claims based on
these small experiments.
Michael Schuerig
[summarizing Richard Gabriel]
> - We need to study rigorously the effects of programming language
> choice on productivity; that is, we need numbers from controlled
> experiments ....
> a lot of other things Academia ought to do but seems to refuse to
> do.
If there were scientific renown to be won. I fear, there is not. At
least not in computer science.
> Probably ICFP is another good try.
Well, after the recent contest someone in this group suggested that the
people on the leading teams would probably perform almost equally well
in other languages.
I'm no social scientist and I have no real idea how to get significant
empirical results concerning the influences of programming language
choice. I do see significant difficulties:
- It's no use comparing toy programs. Results need to be based on
real-world systems.
- It's hard to ensure that teams are comparably competent. I don't even
know how to operationalize this.
Christian Stapfer
..
> Anyway, I also tried to look it up in Richard P. Gabriel's book
> and didn't find it either. Though I stumbled upon a quote that's
> so nice that I just have to tear it utterly out of context:
>
> "Wade [Hennesey's] Maxim: No one ever made money by typing."
>
> (RPG, Patterns of Software, p. 225)
>
But if making *money* is the object, why go into programming
at all? Even Bill Gates, who wasn't particularly shy when
it came to making money, knew, to contribute another quote:
»No great programmer is sitting there saying,
"I'm going to make a bunch of money," or,
"I'm going to sell a hundred thousand copies."
Because that kind of thought gives you no
guidance about the problems.«
- Bill Gates (in "Programmers at Work" by Susan Lammers)
Remember the maxim:
If it talks like a Manager and walks like a Manager
it *is* (or, at the very least, *wants to be*) a Manager.
Nothing wrong with being a manager either. Though I tend
to perceive them as a kind of janitor (to follow Gerald
M. Weinberg's advice) that, hopefully, will not get into
the way when it comes to doing technical work. Thus, for
me, but perhaps not for many others, for a programmer to
become a Manager would not be a real advance - except,
of course, in money terms (they get what they want most).
If I were a manager, I would want my programmers to
be interested in software development, ideas and problems
- not at all in making money...
Christian Stapfer
------------------
»A virtue is an acquired human quality the possession
and exercise of which tends to enable us to achieve
those goods which are internal to practices and the
lack of which effectively prevents us from achieving
any such goods.«
»Virtues then stand in a different relationship to
external and to internal goods. The possession of the
virtues - and not only of their semblance and simulacra
- is necessary to achieve the latter; yet the possession
of the virtues may perfectly well hinder us in achieving
external goods.« ["external goods": read "money"]
»We should therefore expect that, if in a particular society
the pursuit of external goods were to become dominant, the
concept of the virtues might suffer first attrition and then
perhaps something near total effacement, although simulacra
might abound.« - Alasdair MacIntyre: 'After Virtue'
Christian Stapfer
...
> Two, this whole thead (not this particular post) is
> filled with a Dilbert view of management. However,
> intelligent managers understand that C/C++ programmers
> are to be found everywhere, while FP programmers are
> few and far between.
Well, it doesn't take such a terrible amount of
intelligence to figure that out ... so, presumably,
even your average manager can do it.
> Code needs to be maintained. Unless there is a
> critical mass of FP programmers around, it is very
> risky for a manager to have code developed in a
> language/style for which she cannot obtain a ready
> replacement programmer.
There never are "ready replacements" for truly
competent and truly motivated programmers. There
only ever are "ready replacements" for people who
aspire no higher than being easily exchangeable cogs
in management's profit making machine. Remember
Peter Naur?
»The death of a program happens when the programming
team possessing its theory is dissolved. .. The actual
state of death becomes visible when demands for
modifications of the program cannot be intelligently
answered.
...
It follows that in describing the state of the program
it is important to indicate the extent to which
programmers having its theory remain in charge of it.«
- Peter Naur: 'Programming as Theory Building'
He didn't think it necessary to talk about either
programming languages or programming paradigms here,
since programmers are not usually just coders (not
speaking of mere cogs in the profit-making machine now).
> Following the crowd makes good sense on an individual
> level, even if the crowd as a whole is not making
> intelligent choices.
Talk of lemmings!
But if such a prescription for "success" is to be
followed by *everyone* (even programmers, who don't
want to invest the time learning a better programming
language and paradigm since they must assume that
"intelligent" managers invariably want to play it safe)
then *no* progress will be possible: we would still be
coding the whole thing in assembler had it not been
for some rather "unintelligent" (if not simply "dumb")
managers (and programmers).
BTW: I am not taking a stand now as regards the
particular question of C vs. FP, I am just answering
you as regards the "intelligence" of a "cover your ass"
approach to the selection of programming languages on
the same level of abstraction that your own argument
proceeds.
Christian Stapfer
-----------------
»The wise man is he who seeks to adapt himself to the world;
the fool is he who seeks to adapt the world to himself;
thus all progress depends on fools.« - George Bernard Shaw
Friedrich Dominicus
> After correcting for the learning effect you can then see if those who
> solved problem with langauge A did better than those who solved problem with
> language B. Since the average competence of those who did A and those who
> did B is the same, one can reasonably conclude that all differences are
> based on the progamming language.
I do think you can't conclude it that way. The problem might be that
the teams are "more" fluent either in A or B and it might be even
possible that they are masters on A but beginners on B or vice
versa. So at least some sort of "adjustment" of how knowledgable they
are should take place first. Anyway, I do think this is off-topic. So
I better shut up ;-)
Joachim Durchholz
>
> Detailed, explicit operational explanations are what work.
Oops - I overlooked that one. Yes, that's the most important thing to
do: first explain *how* it works, then *why* it works.
This must be repeated on more than one level for functional languages:
* What the language itself does (i.e. explain how functional application
works).
* How to use the language for common tasks (i.e. explain in what way
recursion, higher-order functions, monads, arrows etc. can be used to
apply recurrent problems).
Actually this two-step process is necessary for any programming
paradigm. The second level is called "Tips and Tricks" in Smalltalk,
"subroutine library design" in structured programming, "Design Patterns"
in OO.
I think one important difference is that you need a second-level trick
(recursion) to express something that's a first-level thing in
imperative languages (loops). It means that novices get into contact
with the more advanced concepts while they're still grappling the
language mechanics. (Does this ring true?)
Michael Schuerig
> Michael Schuerig wrote:
> ..
> > Anyway, I also tried to look it up in Richard P. Gabriel's book
> > and didn't find it either. Though I stumbled upon a quote that's
> > so nice that I just have to tear it utterly out of context:
> >
> > "Wade [Hennesey's] Maxim: No one ever made money by typing."
> >
> > (RPG, Patterns of Software, p. 225)
> >
>
> But if making *money* is the object, why go into programming
> at all?
Oops! Sorry, but I didn't expect anyone to take this even half
seriously.
Michael Zawrotny
My background: Lots of programming in various imperative/OO
languages; some work in lisp/scheme. Because of the latter,
basic principles of FP are not totally foreign.
My status: Currently struggling to learn SML and/or OCaml.
"Joachim Durchholz" <joac...@gmx.de> writes:
>Oops - I overlooked that one. Yes, that's the most important thing to
>do: first explain *how* it works, then *why* it works.
Given my background (above), I would add one more step.
1. What it does.
2. How it works.
3. Why it works.
>This must be repeated on more than one level for functional languages:
>* What the language itself does (i.e. explain how functional application
>works).
>* How to use the language for common tasks (i.e. explain in what way
>recursion, higher-order functions, monads, arrows etc. can be used to
>apply recurrent problems).
The "how to" aspect is critical to me. The problem I have had is that
much of the documentation (books and online tutorials) on the above FPLs
use examples that are too abstract for my taste. E.g. when talking
about higher order functions, the examples are about how to construct
a set datatype using higher order functions. It would have been more
useful to me to have the idea of passing a functional parameter to
a function shown by passing a compare function as a parameter to a
sorting function.
I think the key in Joachim's idea is the notion of *common* tasks.
Sure, I know and understand about set union, intersection, etc., but
it isn't something I commonly use. Some of the other examples are
even worse to me. Examples drawn from the areas of formal syntax,
deduction and inferencing may make sense to experienced FP programmers
and are what some FPLs were originally designed for, but I think
that people from imperative backgrounds who are investigating FP
are likely to be put off by such. That is the "FP is only good for
theorem provers, and I'm not working on one of those" response.
I think that FPLs may be good for many other tasks. A lot of programs
(at least the kind I write) can be broken down into: read some data,
do some "stuff" to it, then write the transformed data out. It would
seem to me that FPLs are well suited to this "pipeline" style of
program. The problem is that I/O is generally state dependent and
most of the documentation I've seen is so focused on the purely
functional parts of the languages that all of that "nasty, imperative
I/O stuff" is given little coverage.
Ok, I know that I/O can be done functionally with e.g. monads, but
when I looked some docs on those, I ran screaming away from them
(and consequently haskell).
>Actually this two-step process is necessary for any programming
>paradigm. The second level is called "Tips and Tricks" in Smalltalk,
>"subroutine library design" in structured programming, "Design Patterns"
>in OO.
>I think one important difference is that you need a second-level trick
>(recursion) to express something that's a first-level thing in
>imperative languages (loops). It means that novices get into contact
>with the more advanced concepts while they're still grappling the
>language mechanics. (Does this ring true?)
It does to me.
Just my two cents, and I'll go back to lurking.
Mike
--
Michael Zawrotny
411 Molecular Biophysics Building
Florida State University | email: zawr...@sb.fsu.edu
Tallahassee, FL 32306-4380 | phone: (850) 644-0069
Sven Eric Panitz
zawr...@gecko.sb.fsu.edu (Michael Zawrotny) writes:
> My background: Lots of programming in various imperative/OO
> languages; some work in lisp/scheme. Because of the latter,
> basic principles of FP are not totally foreign.
>
> My status: Currently struggling to learn SML and/or OCaml.
>
...
>
> I think that FPLs may be good for many other tasks. A lot of programs
> (at least the kind I write) can be broken down into: read some data,
> do some "stuff" to it, then write the transformed data out. It would
> seem to me that FPLs are well suited to this "pipeline" style of
> program. The problem is that I/O is generally state dependent and
> most of the documentation I've seen is so focused on the purely
> functional parts of the languages that all of that "nasty, imperative
> I/O stuff" is given little coverage.
>
> Ok, I know that I/O can be done functionally with e.g. monads, but
> when I looked some docs on those, I ran screaming away from them
> (and consequently haskell).
>
...
Hm, that is a shame.
I think that in Haskell is very easily done:
main
= do
content <- readFile "myInputFile"
writeFile "myOutputFile" (doSomeStuff content)
doSomeStuff content = content
But I do admit, it took me some time to realize how easy it is...
I do not know, how todays Haskell tutorials look like, but given
the few lines above in the first chapter without any mention
of monads should not scare anyone? Maybe you will give Haskell a
second chance?
sven eric
--
______________________________________________________________
Sven Eric Panitz Uhlandstr. 12
Software AG s...@softwareag.com D-64297 Darmstadt
(+49)6151-92-1426 __________ half of what I say is meaningless
Michael Zawrotny
>zawr...@gecko.sb.fsu.edu (Michael Zawrotny) writes:
>> Ok, I know that I/O can be done functionally with e.g. monads, but
>> when I looked some docs on those, I ran screaming away from them
>> (and consequently haskell).
>Hm, that is a shame.
>I think that in Haskell is very easily done:
>main
> = do
> content <- readFile "myInputFile"
> writeFile "myOutputFile" (doSomeStuff content)
>doSomeStuff content = content
>But I do admit, it took me some time to realize how easy it is...
>I do not know, how todays Haskell tutorials look like, but given
>the few lines above in the first chapter without any mention
>of monads should not scare anyone? Maybe you will give Haskell a
>second chance?
Ok. That is far easier than anything I ran across in my previous
look at haskell. I might just have to give it another chance.
Thanks,
peter_d...@my-deja.com
"Christian Stapfer" <chst...@nospam.bluewin.ch> wrote:
> <peter_d...@my-deja.com> wrote:
> > Following the crowd makes good sense on an individual
> > level, even if the crowd as a whole is not making
> > intelligent choices.
>
> But if such a prescription for "success" is to be
> followed by *everyone* (even programmers, who don't
> want to invest the time learning a better programming
> language and paradigm since they must assume that
> "intelligent" managers invariably want to play it safe)
> then *no* progress will be possible: we would still be
> coding the whole thing in assembler had it not been
> for some rather "unintelligent" (if not simply "dumb")
> managers (and programmers).
>
> BTW: I am not taking a stand now as regards the
> particular question of C vs. FP, I am just answering
> you as regards the "intelligence" of a "cover your ass"
> approach to the selection of programming languages on
> the same level of abstraction that your own argument
> proceeds.
>
> Christian Stapfer
be aware of the productivity benefits associated with functional
programming, but still have sound business reasons for opting for C++.
Blaming the failure of FP to catch on faster to the ignorance of
managers doesn't tell the whole story. Educating them may not help, at
least not in the short run.
John Heron
>
> >I do not know, how todays Haskell tutorials look like, but given
> >the few lines above in the first chapter without any mention
> >of monads should not scare anyone? Maybe you will give Haskell a
> >second chance?
>
> Ok. That is far easier than anything I ran across in my previous
> look at haskell. I might just have to give it another chance.
>
Simon Peyton-Jones recently wrote a nice tutorial, "Tackling
the awkward squad: monadic input/output, concurrency,
exceptions, and foreign-language calls in Haskell"
available at:
http://research.microsoft.com/Users/simonpj/papers/marktoberdorf.ps.gz
which also provides an outline of an operational semantics for
Haskell IO. There's some other interesting stuff relating
to their approach to concurrency as well. The part on IO is very
clear and doesn't bog down too much into monads and such.
There's also a companion paper by Simon Marlow on his Haskell web
server, which fills out the discussion:
"Writing High-Performance Server Applications in Haskell, Case Study:
A Haskell Web Server"
available at:
http://www.haskell.org/~simonmar/papers/web-server.ps.gz
I recommend both papers, they got me to thinking about writing
some small network clients and servers in Haskell to try it
out.
Best Regards, John Heron
w...@holomorphy.com
> I wasn't talking about Ericsson or Bluetail at all. I was referring
> to other FL advocates in this group, those who argue the merits of
> different FPLs in a vaccuum. That is, people who haven't used FP for
> real applications, and especially people who don't have experience
> working on large applications in any language, need to be less
> vehement about static vs. dynamic typing and the benfits of laziness
> and why mechanical proofs are so important, and so on.
I have a vague idea I should stay away from the advocacy
issues; I'm one of those people who haven't done it. I think I posted
a couple of times about what works for me on one of those threads and
shut up after reading enough of the group to realize it was a perpetual
flamewar topic.
I wonder why there isn't as much discussion of theory as I
expected there to be on this group. Instead, there is, as you say, a
bunch of people playing the armchair advocate, and arguing design and
language aesthetics. I, for one, have a nice little stockpile of
questions I could use some help with...
James Hague <jam...@volition-inc.com> wrote:
> Anyone who has used FL for real applications has my full attention.
> Right now, Erlangers are at the top of the list.
I think that's as it should be, and it may well be enough to
push me over the edge and actually try to learn Erlang. I hear much
about it on this group, and learning programming languages is something
of a pastime of mine, though perhaps second to chess.
Cheers,
Bill
--
"... the most important thing in the programming language is the name.
A language will not succeed without a good name. I have recently
invented a very good name and now I am looking for a suitable language."
-- D. E. Knuth, 1967
w...@holomorphy.com
> Several things I'd like to say on this thread.
> One, having learned OO/C++, I must strongly disagree that FP is more
> difficult. Actually I think good OO is beyond the reach of the average
> mortal (which is one reason there is so much bad OO code).
> Two, this whole thead (not this particular post) is filled with a
> Dilbert view of management. However, intelligent managers understand
> that C/C++ programmers are to be found everywhere, while FP programmers
> are few and far between. Code needs to be maintained. Unless there is
> a critical mass of FP programmers around, it is very risky for a
> manager to have code developed in a language/style for which she cannot
> obtain a ready replacement programmer. Following the crowd makes good
> sense on an individual level, even if the crowd as a whole is not
> making intelligent choices.
Who is the average mortal, anyway? Is the average mortal even capable of
programming in any paradigm at all? (Who is the average immortal? =) As
far as the Dilbert view of management goes, I work at a fairly large
company (ca. 300K employees) and my boss knows more about the technical
aspects of what I'm doing than I do. As far as replacement programmers
go, I seem to hear fairly often that several projects would die if any
one of several programmers got run over by a bus, regardless of the
fact that other programmers who know the language are readily available.
Knowledge of the codebase and techniques for debugging and testing and
so on in the weird conditions we're dealing with are more important by
a very long longshot than knowledge of the programming language. I'm
assuming this result is safe to extend to almost any project of
significant size and scope. How do you debug code generation in
compilers, image defects in graphics, convergence problems in numerical
analysis? It's almost irrelevant what programming language you're
talking about in these cases, because domain-specific knowledge is far
more important. Programmers are not interchangeable tinkertoys with
which to build software assembly lines, and there are managers out
there who already know that.
Cheers,
Bill
--
"I'll not listen to reason. Reason always means what someone else has
got a say."
-- Elizabeth Gaskell
w...@holomorphy.com
> Ok, now give me another try:
> Richard P. Gabriel Patterns of Software (Tales from the Software
> Community)
> p127ff some parts
> - We need a reliably measured productivity baseline ...
> choice on productivity; that is, we need numbers from controlled
> experiments ....
I'm in agreement with this. I'd like something somewhat stronger than
anecdotal evidence that advanced languages (and I'm not even particularly
picky about which ones) increase productivity. And frankly, this is
something I'd categorize as some kind of psychological sort of HCI, of
which I know very little. It would also be nice to hear of attempts to
discern which features of the advanced languages cause those productivity
increases, or how one would orchestrate experiments to determine them.
Perhaps such discussions would even influence language design.
Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
> a lot of other things Academia ought to do but seems to refuse to
> do. The closest I got to this was done by NASA and someone in Germany
> about one problem about encoding Telephon Numbers. That's not all too
> much, but the data were quite interesting. Probably ICFP is another
> good try.
If the data were interesting, what did they imply? Is it possible that
there could even be unexpected results pursuing this kind of research?
Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
> On of the things he concluded on page 121.
> "Right now the history of programming languages is at an end, and the
> last programming language is C."
There is a point to that statement, and I'm guessing the preceding chapter
established various things like
(1) maintenance on existing software
(2) an absolute need for a language right at that level of
abstraction, with most things machine-independent and
enough machine-dependency to do systems programming
(3) critical masses of programmers
(4) conceptual difficulty tradeoffs
I'm going to say that I disagree with his conclusion, and instead
believe that C is phenomenally useful for systems programming as it has
a very strong affinity to von Neumann architectures. That, and most
machines need operating systems to be useful. On the other hand, aside
from that, I believe that operating on the level of C leaves
programmers to trip over trivial details they shouldn't have to. (Why
manually manage memory? We have machines to do that for us now...)
Friedrich Dominicus <fr...@q-software-solutions.com> wrote:
> So why bother about OO and FP ;-)
> I wonder what he would say about Java.
Even if FP (and OO, to a lesser extent) weren't useful, I'd still find
them quite interesting objects of study. I suppose that would put FP
(and perhaps OO and logic programming) in the math department as
logicians instead of computer scientists, but they'd probably do it
anyway. And I don't care what he has to say about Java. I don't like
Java, and it's fairly obvious that he probably won't like it, either.
Cheers,
Bill
--
"The software industry that Microsoft has been the role model for is
built on the premise that customers are not to be trusted with the
technology that they are building their organizations on."
-- Bob Young
Alex Martelli
news:sumgghg...@corp.supernews.com...
[snip]
> > do. The closest I got to this was done by NASA and someone in Germany
> > about one problem about encoding Telephon Numbers. That's not all too
> > much, but the data were quite interesting. Probably ICFP is another
> > good try.
>
> If the data were interesting, what did they imply? Is it possible that
> there could even be unexpected results pursuing this kind of research?
A report on the German "phone number encoding experiment" is available on
the web and an article on it is in a current computer journal (darn, can't
find either the URL or the journal reference right now...). The study did
NOT include functional programming languages (darn!) but only C, C++,
Java, and scripting languages (Perl, Python, Tcl, Rexx). As far as the
results indicate anything, it's that scripting languages give enormous
boosts in productivity at modest cost in program speed -- about 4/5
times better programmer productivity, equivalent or slightly better
reliability, about 30% cost in runtime (wrt C or C++ -- faster than Java,
at least for Perl and Python). This is the median -- good-to-worse
ratios were huge in each case (best-decile Perl/Python programs far faster
than worst-decile C/C++, best-decile C/C++ programmers more
productive than worst-decile scripting ones), indicating that, at least
for this kind of problem and these kinds of languages, human skill
variation appears to be by far the most significant determinant.
Ah, if the authors of the study had thought to include some FP
languages in it...!-(
Alex
John Atwood
>A report on the German "phone number encoding experiment" is available on
>the web and an article on it is in a current computer journal (darn, can't
>find either the URL or the journal reference right now...). The study did
>NOT include functional programming languages (darn!) but only C, C++,
>Java, and scripting languages (Perl, Python, Tcl, Rexx). As far as the
>results indicate anything, it's that scripting languages give enormous
>boosts in productivity at modest cost in program speed -- about 4/5
>times better programmer productivity, equivalent or slightly better
>reliability, about 30% cost in runtime (wrt C or C++ -- faster than Java,
>at least for Perl and Python). This is the median -- good-to-worse
>ratios were huge in each case (best-decile Perl/Python programs far faster
>than worst-decile C/C++, best-decile C/C++ programmers more
>productive than worst-decile scripting ones), indicating that, at least
>for this kind of problem and these kinds of languages, human skill
>variation appears to be by far the most significant determinant.
>
>Ah, if the authors of the study had thought to include some FP
>languages in it...!-(
If i'm thinking of the same study, here's the orig call for programs:
http://x70.deja.com/[ST_rn=ps]/getdoc.xp?AN=549686087&CONTEXT=971741440.1411317772&hitnum=59
and the paper:
http://wwwipd.ira.uka.de/~prechelt/Biblio/#drafts (#2 in the list).
John Atwood
Friedrich Dominicus
>
> If the data were interesting, what did they imply? Is it possible that
> there could even be unexpected results pursuing this kind of
>research?
Here are some of the results:
http://wwwipd.ira.uka.de/~/prechelt/Biblio/jccpprtTR.ps.gz
There are some other experiments on what influence e.g the PSP might
have. Peter Norvigs implementation can be found here:
http://www.norvig.com/java-lisp.html
other information about that task can be gathered from here
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html
>
> Even if FP (and OO, to a lesser extent) weren't useful, I'd still find
> them quite interesting objects of study.
What would it worth for programmers if it isn't useful? I do think
both are very useful and good help massively to develop software
either faster or of higher quality.
FM
>Who is the average mortal, anyway? Is the average mortal even capable of
>programming in any paradigm at all? (Who is the average immortal? =) As
>far as the Dilbert view of management goes, I work at a fairly large
>company (ca. 300K employees) and my boss knows more about the technical
>aspects of what I'm doing than I do. As far as replacement programmers
>go, I seem to hear fairly often that several projects would die if any
>one of several programmers got run over by a bus, regardless of the
>fact that other programmers who know the language are readily available.
>Knowledge of the codebase and techniques for debugging and testing and
>so on in the weird conditions we're dealing with are more important by
>a very long longshot than knowledge of the programming language. I'm
>assuming this result is safe to extend to almost any project of
>significant size and scope. How do you debug code generation in
>compilers, image defects in graphics, convergence problems in numerical
>analysis? It's almost irrelevant what programming language you're
>talking about in these cases, because domain-specific knowledge is far
>more important. Programmers are not interchangeable tinkertoys with
>which to build software assembly lines, and there are managers out
>there who already know that.
Interesting observation. It's in fact ironic how a huge part
of software engineering deals with how to make programmers
replaceable. I wonder if this is true of other kinds of
engineering. I personally feel that the problem with the
software engineering is that more changes and improvements
are expected of softwares in a short time period than for
any other kinds of products. But I haven't been involved in
any other engineering activities, so I speak from assumptions
rather than experience.
Dan.
Jerzy Karczmarczuk
> ... It's in fact ironic how a huge part
> of software engineering deals with how to make programmers
> replaceable. I wonder if this is true of other kinds of
> engineering. I personally feel that the problem with the
> software engineering is that more changes and improvements
> are expected of softwares in a short time period than for
> any other kinds of products.
I believe that the facility to replace people is the essence of
+ the modern capitalism
+ the communism (is there a modern version of it?)
+ the Army
+ the Church
etc. But not all people and not everywhere...
I dream of a world where it would be easier to replace
a general than a private soldier. And I dream of a French
school where it would be easy to replace a lousy teacher.
Jerzy Karczmarczuk
Caen, Normandy.
Michael Zawrotny
[snip]
>w...@holomorphy.com writes:
>> Even if FP (and OO, to a lesser extent) weren't useful, I'd still find
>> them quite interesting objects of study.
>What would it worth for programmers if it isn't useful?
The worth is in problem solving. One of the reasons I keep trying and
learning new (to me) languages is that each language has its own way
of approaching problems. By learning how to solve problems in language
X, I teach myself new ways to think about solving problems and different
approaches to programming. These may then be used, although often
to a lesser extent, in other languages that are "useful".
For example, if one has learned the "have a function do something to the
head of a list, then recurse on the tail" technique from any of the
functional languages, the same approach can be used in other, non-FP
languages that support a list data structure. Even if the language
doesn't support recursion well (e.g. pass by value that copies the list
on function entry/exit), you can still use the same general idea in an
imperative fashion with explicit looping. It's not as clean as it would
be with recursion (or maybe mapping over the list), but it works.
That's my 2 cents. Others may or may not find other worth in languages
or approaches to programming that are not "practical".
Christian Stapfer
...
> I believe that the facility to replace people is the
> essence of
>
> + the modern capitalism
> + the communism (is there a modern version of it?)
> + the Army
> + the Church
> etc. But not all people and not everywhere...
I believe, or rather hope, that a university is
different: that a university, ideally, would not
want to have easily replaceable students - but,
on the contrary, rather unique, quite exceptional
ones...
On the other hand, it is hard to deny the
evidence that even universities are delivering
(or, at the very least, are ever more urgently
asked to deliver) somewhat standardized graduates
who are expected to fit into easily assignable
slots in "private" industry. (I have put "private"
into quotes here, since, under such circumstances,
it is increasingly difficult to tell where the
educational system ends and where the so called
private sector begins.)
Christian Stapfer
------------------
»Lowering and homogenizing skill levels improved
the bargaining power of management. It engendered
a labor surplus that made workers dependent on
employers and imposed the discipline of the reverse
army of the unemployed.«
- Stephen P. Waring: 'Taylorism Transformed'
Mark-Jason Dominus
Kragen Sitaker <kra...@dnaco.net> wrote:
>In article <bruce-F8EAAE....@news.akl.ihug.co.nz>,
>Bruce Hoult <br...@hoult.org> wrote:
>>In article <mccA5.24104$ve5.1...@news-east.usenetserver.com>,
>>kra...@dnaco.net (Kragen Sitaker) wrote:
>>
>>> Perl [...] supports the tail-call optimization (although you
>>> have to do it by hand).
>>
>>Could you possibly demonstrate that for me? I thought I knew Perl (I
>>use it all the time), but I didn't know about that.
>
># some nonsense code
>sub foo {
> ...
Last time I benchmarked this, it was a pessimization, not an optimization.
(shuffling through old files...)
Ah, here it is. Not so old; only March 30 of this year.
I benchmarked:
# ordinary recursive version
sub gcd_r {
return $_[0] if $_[1] == 0;
return gcd_r($_[1], $_[0]%$_[1]);
}
# tail-recursive 'optimization'
sub gcd_i {
return $_[0] if $_[1] == 0;
@_ = ($_[1], $_[0]%$_[1]);
goto &gcd_i;
}
10000 calls to gcd(40320, 1190) generated the following times:
gcd_r: 0.92 sec
gcd_i: 3.41 sec
I just put the benchmark code at
http://www.plover.com/~mjd/perl/book/tail-recurse.pl
if you want to see it; it's possible that I botched something.