Re: Strong Typing, Dynamic Languages, What to do?

[Jerzy Karczmarczuk <karczma@info.unicaen.fr>]

Matthias Felleisen makes some important comments on the efficiency issues
and asks some questions:


> 1. How it can possibly matter to beginners (<= 2 years of training)?
>    They don't even know how to write a correct program.

RRright. And this is one of the most frustrating things in my everyday
experience. I see it also on newsgroups, and having many friends and
colleagues whose children are entering the adult age, I have also many
personal observations. "Don't learn Java, 'cause C++ is much FASTER!"
"How to make extrusion surfaces? Give the code in "C", it must be fast".
"I don't know yet how to program, do you think that C is a good starting
 point, or should I begin already with assembler, as professionals do?"

"Hey, this hypnotic example in Squeak you recommended: you are cheating,
it cannot be written in Smalltalk, but probably in C, everybody knows
that Smalltalk is interpreted, so it must be very slow".

Bad myths reach youngsters at the age of 13, when they stop to see
computers just as collections of resources, and they begin to see them as
problem solvers.

> 2. In most software ... there are many different criteria:
>    Correctness, Reliability, ... Reusability, Utility, Performance
>    If we don't teach about these and why they matter, we neglect important
>    things

Absolutely. And I would add to it such things as elegance. And reasonable
learning curves, and self-documentation. But *HERE* the beginners are
usually even weaker and less motivated than in the efficiency issues.
What do young people think about cars? Reliability? Reusability? Bof! as 
a genuine French Frog would say...

 
> 3. Whatever we do, we should not teach full Scheme, full Haskell, or full
>    ML in a university course. The emphasis should be to show how one can
>    build programs that measure well according to the above.

This might be discussed, the time is always limited, and things must be 
sacrified. What I do? I decided to teach *concrete* applications. Graphics
and visualization (and some simulations): Scheme. We introduce the MrEd
toolbox "adiabatically", programming and HelpDesk simultaneously in action,
learning at the same time the basics of Object-orientation and some notions
of event-driven programming.
Compilation: Haskell, introducing it in parallel (only this year a colleague 
started to teach a *real* functional programming before the compilation course,
next year my life will be much sweeter... Or sweater?, who knows...)
Image synthesis: everything. Matlab examples written in declarative style.
Parametric surfaces designed functionally. Procedural textures constructed
in Clean.
So, we introduce the notions we need, and all the gymnastics needed in order
to make it in an orderly manner is quite involved and non-trivial. But it
seems to work, at least I won't leave the students with the illusion that
the world is split into the part which runs fast and does useful things, and
the academics, which bother them with their methodology for the sake of
methodology, without providing concrete application examples.


> 5. Once you have market share, you have demand and resources to spend on
>    making your languages efficient. Otherwise it's premature. We just don't
>    have the manpower that is behind Fortran or C compilers. Considering
>    that it is absolutely amazing how well FP languages do.

>    -- Matthias

I sign that with all my four hands, and the tail as well. Thank you.


Jerzy Karczmarczuk
Caen, France