[ocaml-biz] academese

[Brian Hurt]

On Sun, 29 Aug 2004, Brandon J. Van Every wrote:

> Brian Hurt wrote:
> > Brandon J. Van Every wrote:
> > > Brian Hurt wrote:
> > > > Brandon J. Van Every wrote:
> > > > >
> > > > > - is baroque and difficult to learn compared to Python
> > > >
> > > > Only if you're comming from imperitive/OO languages.
> > >
> > > Yes, and 'everyone' in the mainstream is, so the point stands.
> >
> > I may be exceptional, but I was reading Ocaml code before I
> > knew Ocaml.
> 
> You are an early adopter.  Need I say more?

My point was that I don't think Ocaml is the unscalable cliff most people 
think it is.

> 
> > What the hey- I'm tired of pussy-footing around the issue.  I
> > think the
> > biggest problem Ocaml has is how it's introduced.  You throw
> > terms like
> > "lambda calculus", "higher order functions", "partial function
> > application", etc.  around up front, and except for a few whakos like
> > yours truely, you're going to scare everyone off.  The one
> > dead-tree book
> > I have on Ocaml uses all three terms in section one of
> > chapter one- and
> > even I considered running to the hills screaming.
> 
> Yes, for a mainstream marketing campaign, the academese has got to go.
> Python wasn't saddled with this nonsense.  It was meant to be practical
> and easy to use.

Oh, the ideas are great.  I like the fact that Ocaml has higher order 
functions and partial function application and all those other fifty cent 
terms.  I think that if you're introducing the language, leave the jargon 
until later- much later.

> 
> > Interpreted is a benefit for scripting languages.  It's not
> > that usefull for doing application work.
> 
> A friend of mine would disagree with you.  Not having to compile seems
> to speed up his productivity.  Realize too that 'productivity' isn't
> necessarily objective time measurements, but also subjective feeling of
> how much of a drag you think a given development environment is.  I
> didn't end up biting on the Python development methodology, things like
> C/C++ FFIs and performance kept getting in my way, so I don't have a
> basis for evaluating his claim.

Ocaml supports this methodology.  We have an interpreter.  And when you 
get the code working, and it needs to be fast, you compile it to native.  
The best of both worlds.

> 
> > The current state of software outrages me.  The vast majority
> > of programs
> > are crap, to put it bluntly.  They leak memory, segfault when
> > you look at
> > them crosseyed, have rampant security holes, are huge,
> > bloated, and slow,
> > and many if not most are impossible to maintain.
> > If you haven't already,
> > take a read of this anatomy of a bug at Microsoft:
> > http://blogs.msdn.com/rick_schaut/archive/2004/05/19/135315.aspx
> 
> See my .sig.  It might amuse you to know that Ed McKenzie is a Microsoft
> employee.

We can't do much about the bad process.  But if the tools can catch the 
simple errors, why not?

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian