[Haskell-cafe] Channel9 Interview: Software Composability and theFu ture of Languages

[Chris Kuklewicz]

Hi,

  As I am taking a break from writing code and doing laundry, here are my thoughts.

Restating the obvious: I agree with you that it is amazing how use of the word
"Monad" has brought out so many people's feeling towards math.

Obligatory disclaimer: Like many people, I have learned to write code in Haskell
and I never took a course in Category theory. Nor do I have a CS degree.  My
math and physics degrees were not applicable to learning Haskell.

I had never use a similar type system or type inferencing.  The combination of
the new type system and the new approach to IO took a little while to sink in.
(I had learned BASIC, Pascal, Turbo Pascal with Objects, C, some Fortran, C++,
Scheme, Java)

But I think the biggest advance in Haskell is the explicit separation of IO
operations enforced by the type system / compiler.  Other languages may get type
inference and may get closer to parametric polymorphism (java generics) and they
may even get STM but they are unlikely to be able to evolve this IO separation
and maintain much backward compatibility.

Michael T. Richter wrote:
> On Fri, 2007-26-01 at 22:01 -0600, Collin Winter wrote:
>> I find it incredibly insulting for you to assert that people who
>> complain about Haskell's difficulty are too lazy and aren't really
>> interested in a better solution. Maybe they just don't want to have to
>> take graduate-level classes in category theory to get their job done.

It is probably true that having such a course would let you directly understand
the mathematical structure.  But such understanding is different from knowing
how to read and write Haskell programs.

> That would be a good way to think, yes.  I look for practical solutions
> to real problems in my work.  Haskell looks like it has these solutions,
> but extracting them from the noise level of ivory tower debates is a
> real problem.

There are CS PhD people who publish papers and who talk about Haskell.  These
are largely irrelevant to reading and writing Haskell.  Some papers are relevant
to designing extensions to Haskell, but unless you are trying to build a new
Haskell compiler extension these are not needed.

> I think many of the users of Haskell forget that there are a lot of
> people out there who are not career academics working with pure
> mathematics day-in and day-out. 

GHC seems to be developed by several people at Microsoft Research.  They are not
career academics.  I am less familiar with the other compilers.

For example: The latest extension proposal on haskell-cafe mailing list is about
View patterns.  This is all about making the code easier and clearer to write
and to encourage interfaces that hide implementation details.  That is about
practical changes to help people and not about academics.

> My last math class?  Was over fifteen
> years ago.  And in, you know, the real world of programming you don't
> face mathematical problems as your bread and butter.

If you have already created the algorithm or data structure then you are right.
If you can simply reuse existing libraries and solutions you are right.

But creating algorithms is a type of math.  And Haskell exposes this better than
most languages.

> You face problems
> in a messy world of too-short deadlines, too-few resources,
> too-poorly-communicated requirements and too-many-hours work.

The bottom line: Learning Haskell without a background in similar languages
takes time.  If you cannot take that time from the world, then Haskell will be
very hard to acquire.  The previous post about educating the next generation at
Universities makes the same point.

Aside: One could make a good case that there there is a synergy between learning
Haskell and learning the use the up and coming features of Visual Basic (LINQ)
and C# (STM) and Java (Generics vs Type Classes and Parametric Polymorphism) and
even Perl 6 (since it is taking so many ideas from Haskell).  And thus taking
the time to learn Haskell is useful.

Haskell is not the one and only cutting edge source of such language features,
but it does let you use many of them simultaneously and has good compilers
available today.  Note that I have not mentioned laziness.  This is because it
only helps to solve problems more elegantly -- other languages can model
infinite computations / data structures when it is useful to do so.

> I would like to see a guide to Haskell that shows Haskell's place in
> those problems, not in Yet Another Elegant Mathematical Proof of the
> utterly useless in real life.

Perhaps: http://haskell.org/haskellwiki/Why_Haskell_Matters

There are many learning links at hakell.org, though many resources may be newer
than when you learned Haskell:

http://haskell.org/haskellwiki/Haskell_in_5_steps

http://haskell.org/haskellwiki/Learning_Haskell
  (such as "Haskell Tutorial for C Programmers")

http://haskell.org/haskellwiki/Books_and_tutorials
  (such as "Programming in Haskell" published January 31, 2007)
  (such as http://haskell.org/haskellwiki/Hitchhikers_Guide_to_the_Haskell )

The ivory tower stuff you want to avoid is at:
  http://haskell.org/haskellwiki/Research_papers

Aside on utterly useful proofs: When you write concurrent programs you want an
API with strong and useful guarantees so you can avoid deadlocks and starvation
and conflicting data read/writes.  Designing an using such an API is a reasoning
exercise identical to creating proofs.  Some systems makes this possible and
even easy (such as using STM).

> Now given my privileged position of having escaped that ghetto of "toos"
> five years ago, I actually have the time and the energy to work this
> stuff out on my own.  But your average working programmer?  Just doesn't
> have the damned time to decode the arcane and obtuse wording and
> mathematics to get to what in the end turns out to be concepts verging
> on the trivial.  (I'm looking at monads here....)

Right.  If it had been called the "Binding Chain Design Pattern" then no one
would have gone nuts over the fact it had anything to do with advanced math.

But this design pattern was not trivial: it took years to standardize on using a
Monad for IO in Haskell.  This may have been a result of too small a community
of users.

> Maybe I'm the one that has to write the book "Haskell for the Working
> Programmer" sometime.  You know.  When I understand the language enough
> to write it.

You could start small by adding sections to the learning and tutorial pages at
the wiki...

-- 
Chris