Receptive Tool Vendors (was: Re: [Caml-list] Jihad)

["Eric Newhuis" <enew@bigfoot.com>]

> Have you found tool vendors outside of the USA more receptive /
> perceptive?

Not directly.  However I have, on occasion, encountered people from the UK
who know ML and have preached its virtues.  I only assumed that there must
have been some form of support outside the classrooms and research labs.

Am I wrong?  What is the current state of functional programming language
acceptance?

I used to preach Lisp for no apparent reason.  I know that Lisp has enjoyed
some commercial success, perhaps for those who have refused to relinquish
who now find themselves solving commercial problems.

After learning about ML and Caml I doubt that I will ever preach Lisp again.
I wouldn't have known any better if I hadn't collected years of personal
observations on the (potential) safety provided by languages like C++ and
Caml.

Caml provides a much stronger safety of primitives than C++.  I believe
higher-level safety is also important:  Avoid Primitive Obsession and
construct useful classes that encapsulate basic domain concepts.  This is a
good form of safety that is even possible in weakly typed languages.

Why am I venturing here in response to your question?  Well I think there
are a lot of good techniques that programmers consistently ignore because
they are creatures of habit.  So we don't have a lot of developers screaming
for better type safety here in the USA.  And I'll bet this is true worldwide
since USA tool vendors have an influence on the world, no?

I recall reading "After the Gold Rush" in which the author urges us to move
toward more professional software engineering practices.  I firmly believe
that languages like Caml can play a role in that.

It is precisely the X-behavior of weakly typed languages that leads one to
believe that programming is still more of a "black art" or a .  I say those
developers are simply too lazy or too lame to undertake the higher task that
is deserving of the title of "Professional Engineer".  (This is what I was
referring to in my first email about the "true professional".)

Interviewer:  "Yes Mr. NASA engineer, just how did you get that robot to
land on Mars and take pictures?"
NASA Engineer:  "Oh that?  We don't know.  We have a number of magicians
working for us and they refuse to reveal their secrets."

Hogwash!

True; no language is a silver bullet.  We need a combination of fail-safe
mechanisms, good engineering practices, and technical management and process
optimization.  (I must sound like an SEI pundit.)

I think Caml can be one piece of a much larger puzzle.  Tool vendors who
sell this higher cause and demonstrate how it can save money by producing
more intentionally error-free software will, perhaps, have an edge over the
competition.

But the sales pitch needs to also educate software developers in best
engineering practices.  And I don't necessarily mean UML diagrams, but more
practical things like SOME of those practices suggested by the Extreme
Programming crowd, the Refactoring book, NASA's SEL, and IBM's software
lifecycle management research.

Failure to instruct in all these areas will diminish the understanding that
a language like Ocaml is a good thing.

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr