[Haskell-cafe] Channel9 Interview: Software Composability and
theFu ture of Languages
p.f.moore at gmail.com
Mon Jan 29 09:06:42 EST 2007
On 29/01/07, Michael T. Richter <ttmrichter at gmail.com> wrote:
> I started, given that I could actually have the free time now, looking at
> Haskell again about a year ago. (It's a major point in Haskell's favour
> that it always stuck around in my mind after first encountering and
> rejecting it, incidentally!) The documentation situation is better now,
> yes. Far better. But still not useful for people who are actively
> developing software in the C++/Java/C#/crap-"solution"-of-the-day daily
> grind. Now, at least, there actually *is* useful information. Finding
> it, however, takes up valuable time when you've got Yet Another Laughable
> Deadline ahead of you from your boss who is still unfamiliar with the
> Triangle of Quality (Fast <=> Cheap <=> Good : pick any two) and who has no
> patience for your strange ideas which you can't explain *because you
> yourself aren't sure of the ideas yet*. And I'm positive that this drives
> people off. I'm positive because it drove me off and I'm far more prone to
> experimentation with oddball technologies than most of the people I've ever
> worked with.
Agreed. I'm in the same boat. I can't realistically use Haskell at work
until I can pull together the building blocks *fast*. That means, half an
hour grabbing a reference and fiddling a bit to get a trivial database query
working. Another half hour checking up on how I bolt together the
boilerplate needed to add logging to a server. Etc.
It *has* to be possible to do this - I can do it in Python, or Perl, or even
Java. So if I can't do it in Haskell, then I'm back stuck with one of those
languages. I may not like it, but it's a practical reality in my job.
I can try to learn at home (and I do!) but I don't have the same sort of
issues at home, or the resources to simulate them (100+ databases running
over a WAN that I need to query simultaneously, in parallel, just to provide
viable response times, for example :-)). So home problems end up being "toy"
problems, and I'm only learning for the intellectual exercise (a good
reason, but not helping with work).
I'm very serious about the need for a "Haskell for the Working Programmer"
> book. And by this I mean a book and not a tutorial on some part of Haskell
> which proves difficult.
Agreed. Something I can keep on my desk for reference, as well as browsing.
... and closing with a cookbook of Haskell solutions to real-world problems
> (networking, database, general I/O, common algorithms, etc.) featuring Best
> Known Approaches (which remain, nonetheless approachable) to them.
Yes, a cookbook approach is an excellent resource. It doesn't have to cover
everything, but it needs to focus on practical problems, and "just do this,
and you're started" solutions.
The other thing that is needed, IMHO - and this is visibly improving, but
can still get better - is availability and ease of use of libraries. I'd
like to be able to "just download" a Windows binary for libraries I need -
logging, DB access, HTTP, client access to Windows COM objects, a GUI
framework, sending emails, etc ... Again, it's the "I need it now" issue - I
can spend time searching out or even developing such things, but when I
don't even have the time to write the code I need for my job (hence wanting
a high-level language like Haskell to speed up development :-)) what chance
do I have if I have to spend time locating libraries as well? Python does
well here with its "batteries included" approach, and the cheeseshop package
index. Perl has CPAN, but quality and ease of installation issues have hit
me there in the past. Haskell seems to be getting there, but it feels to me
like there's a "critical mass" point it still has to get over. But there's
clearly an interest in the community for this type of thing, so I suspect
it's only a matter of time.
I'll stop rambling now.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe