[Haskell-cafe] Re: Libraries for Commercial Users

Curt Sampson cjs at starling-software.com
Sat Oct 24 02:47:05 EDT 2009

On 2009-10-11 10:58 -0600 (Sun), John A. De Goes wrote:

> On Oct 9, 2009, at 10:37 PM, Curt Sampson wrote:
>> And if libraries are the issue, why would not just creating a SWIG for
>> GHC make all of these people move to Haskell?
> Making it possible and making it easy are two different things. It's  
> already _possible_ to do Haskell interop with any other language, it's  
> just difficult and cumbersome.

Have you written (non-SWIG) interop code for both Haskell and other
languages? I've done, in the recent past, both Haskell and Ruby, and
while Ruby is one of the easier ones out there, Haskell is even easier
than that. As far as I know, when writing FFI code "by hand," there
is *nothing* out there easier than Haskell. 

(I am happy to be convinced by a counterexample. However, I'd want to
see how other FFIs support not only simple calls into functions written
in other languages, but also how they deal with callbacks [passing
function pointers to foreign-language libraries for them to call],
memory allocated and deallocated by foreign libraries, and so on. If you
want a small example that covers a lot of this, try writing enough of
an interface into the Microsoft DDE library that you can write a simple
DDE server and query it via the standard DDE client used for debugging.
I can provide a Haskell library that does just this; it's less than 500
lines of code.)

>> I agree it's a nich market, too. So I guess our point of disagreement is
>> that you believe that it's lack of libraries keeping it a nich market,
> Haskell will never be "popular", because it's too hard for the masses.  
> But I could see big companies like Yahoo, Facebook, Google, etc., using 
> Haskell extensively to develop web infrastructure -- _if_ there were no 
> longer a significant penalty to doing so. Right now the barrier of entry 
> is too high, because too much infrastructure would have to be developed 
> from scratch, and then maintained at cost.

Well, my experience (three years running a company that wrote a lot of
web applications, and about 12 years total writing web applications
under various circumstances) says otherwise. 

There are two different approaches to writing web applications. The
"we think we're not smart enough to write a web framework" category of
developers use Rails or whatever, and yes, the lack of libraries in
Haskell is likely to hurt them. But then again, they're not likely to
touch anything like Haskell anyway; they'd never use something that
isn't already popular and doesn't cause them to have to change their
mental model too much.

The "we think web frameworks aren't hard to write" category may or
may not use a framework, depending on how suitable it really is. For
large sites that require a distributed system, generally you end up
writing a lot of custom framework-type code. (I don't have experience
with truly huge systems, but I think that a "small" one serving less
than 10,000 requests per second and about 7-8 Gbps continuously during
the peak hours is big enough that I have some understanding of what
goes on there.) For these people, they do have a lot of libraries in C
they can still use, and it's trivial for them to write the interfaces,
and they're highly likely to write their own framework, or customize
so heavily the one they're using that it might as well be a different
framework anyway.

> Well, I don't know much about Rails, but I do know some Rails developers 
> can build a fully-functional, database-backed Web 2.0 site in a matter of 
> hours.[2] That level of productivity is not available in Haskell yet.

Sure. And I can do that with my Ruby web framework, too. If I were doing
web applications in Haskell, I'd write a framework there that would get
me to the same point pretty quickly.

But keep in mind, people who like Rails are very much not the kind of
people who would ever consider Haskell for anything, no matter how
good the libraries. Rails is successful because it's an incremental
improvement on a rather poor way of writing web applications, and so it
doesn't challenge all of those PHP programers who don't want to think
too much.

> Put another way, it would cost me far more to hire you to develop a  
> Haskell site than a good Rails developer....

It depends on the site. For a simple site, yes, you can hire a cheap
Rails developer, a cheap PHP developer, or a cheap almost-anything-else
developer. If you're doing something with any technological difficulty,
however, such as the next Twitter, Rails won't provide much of the help
you really need.

Curt Sampson       <cjs at starling-software.com>        +81 90 7737 2974
           Functional programming in all senses of the word:

More information about the Haskell-Cafe mailing list