[Haskell-cafe] Is Haskell a 5GL?

David Curran david.curran at gmail.com
Fri Sep 29 11:25:52 EDT 2006


After some thought on your replies I have realised that I was completely wrong.
1. Software needs to be concurrent
Haskell is doing more towards this goal then any other language I know of
2. Software should be provably correct.
Haskell is doing more towards this goal then any other language I know
of. ML and Haskell do seem to be the only communities really trying to
do this. Current systems do need to be easier to use though.
3. Haskell might be too academic
1 and 2 seem to indicate it is academic in the sense of finding out
useful things that a company might consider too blue sky to invest in.
So it might be too academic for now but for five years time maybe not.
    David

On 29/09/06, Robert Dockins <robdockins at fastmail.fm> wrote:
> On Sep 28, 2006, at 8:47 PM, David Curran wrote:
>
> > Sorry if this comes across as the rant it is. If you are interested in
> > doing useful stuff rather then navel gazing please stop here.
> >
> > Where are compute languages going?
> > I think multi core, distributed, fault tolerant.
> > So you would end up with a computer of the sort envisioned by Hillis
> > in the 80s with his data parallel programs. The only language that
> > seems even close to this model is Erlang. What am I missing about the
> > ability of Haskell to distribute across processors or a network?
> >
> > Say instead of fault tolerant it is fault avoiding.
> > Can proving programs correct (with Haskell) really reduce our
> > workload?
> > http://www.seas.upenn.edu/~sweirich/wmm/03-benton.pdf
>
> I read that paper as saying formal methods have an extremely steep
> learning curve and large initial investment, but that the learning
> and initial investment pay off over time.  The author found that,
> even in the short time he worked with it, formal methods saved time
> when he needed to modify his definitions (third paragraph in the
> second column).  As with many automation tasks, the payoff comes with
> repeated identical or similar iterations.  Furthermore, his acquired
> knowledge transferred well to an unrelated project.  I can personally
> vouch for many of his experiences, having worked some with Coq myself.
>
> > Finally is Haskell a language for programming or a mental gymnasium
> > that might be the proving ground for concepts in the next popular
> > language? To quote from a post on the topic "Old functional
> > programming ideas " on programming.reddit.com
>
> I don't know how much you agree with this quote, but for the purposes
> of discussion I'll assume that you have expressed these views
> personally.  You did, after all, preface your message by saying it
> was a rant so I'm going to assume you're prepared for the flames. ;-)
>
> > "Church-Turing equivalence tells us that all models of recursive
> > computing have the same formal power. But it tells us nothing about
> > which models are the most effective way for humans to understand and
> > express definitions of functions. For some reason I'd expect
> > researchers in programming languages to have a lot of opinions on this
> > subject. But they don't seem to talk about it much.
>
> I think the Haskell community is doing better than many in this
> regard.  There is a concurrent thread on haskell-prime occurring
> _right now_ about whether pattern guards should be in Haskell'.  The
> primary point of disagreement is about whether pattern guards are a
> more effective way for humans to understand and express definitions
> of functions or not!  The ages-old disagreement about top-level state
> is similar, if more heated.  Similar for (n+k) patterns, and a host
> of other issues.  The endless discussions about monads often revolve
> around the goal of achieving new and better ways to express
> complicated function definitions.
>
> I think this is because a fundamental value of the Haskell community
> is flexibility of the language.  Many languages are presented to the
> programmer as a complete package, which doesn't encourage them to
> consider the various possible design decisions that went into
> creating that language.  With Haskell, new users are often quickly
> confronted with various different ways of expressing their goals and
> with extensions they can enable (or not) and are forced to consider
> how best to express their program.  I think this is more good than it
> is bad.
>
> > Instead, a cynical and mean-spirited person might come to the
> > conclusion that PL researchers (such as Wadler) are actually just
> > mathematicians,
>
> You seem to say this like its a bad thing; I completely disagree.  I
> don't think of myself as mean-spirited, and I have no problems
> calling, eg, Wadler a mathematician.  Just as I would call Church and
> Turing and Kleene and Goedel and Milner (etc, etc, etc)
> mathematicians.  If someone were ever to call _me_ a mathematician, I
> would consider it an honor.  Furthermore, if anyone attempted to
> belittle these distinguished persons or their accomplishments by
> calling them "just" mathematicians, I would begin to question his or
> her qualifications to have an opinion on the subject worthy of
> consideration.
>
> The field mathematics has a long and glorious history of helping
> people to solve real problems.  I don't understand this undercurrent
> of antagonism that some people in our field have towards it.  Let's
> be honest: developing correct programs that perform non-trivial tasks
> and reasoning about them is HARD.  The techniques of mathematics and
> its sister discipline formal logic can help us with these tasks.  I
> find it a little strange that this position even requires a defense.
> All of the other scientific and engineering disciplines embrace the
> mathematics that help them do their work.  I don't believe there are
> very many physicists who would call Newton a mathematician and intend
> it to be a derogatory term.
>
> I personally see some of the primary goals of PL research as 1) to
> explore new ideas in PLs (obviously) and 2) to try to close the gap
> between the mathematics underlying computation and the realities of
> programming in the trenches.  I think Haskell has spurred great
> advances toward both of these goals, and has come closer to achieving
> the second than any other language I know of (with the possible
> exception of SML, but *grumble* side-effects *grumble*, etc)
>
> > who happen to have discovered a new name for their
> > specialty which comes with a lot more funding. They certainly seem
> > quite comfortable working in a notation that almost no programmers
> > understand or seem to be learning.
>
> Call me elitist if you want, but I don't want anyone who refuses or
> is unable to learn calculus to be, eg, a civil engineer.  He don't
> have to be an expert in real analysis, but if he don't understand the
> basics, I don't want him building any bridges that I'm going to be
> driving on!
>
> In a similar way, if a someone refuses or is unable to learn the
> mathematical foundations of computation, I don't think I really want
> him programming any systems that I'm going to be relying on.  He
> don't need to be an expert in category theory, but if programmers
> aren't learning the skills they need to understand the basics and
> mathematical notation of PL theory, then something is very, very
> wrong.  (Not to beat you over the head with my point, but what I'm
> saying is that programmers really ought to know this stuff and the
> fact that most do not is a terrible state of affairs).
>
> > If a responsible scientist wanted to counter this cynical,
> > mean-spirited, and generally Luddite and Philistine argument, what
> > would he or she say?"
>
> Mu
>
>
>
>
> Rob Dockins
>
> Speak softly and drive a Sherman tank.
> Laugh hard; it's a long way to the bank.
>            -- TMBG
>
>
>
>


-- 
It chews up lies and spits out the gristle of truth
http://liveatthewitchtrials.blogeasy.com/


More information about the Haskell-Cafe mailing list