[Haskell-cafe] Re: Libraries for Commercial Users

Curt Sampson cjs at starling-software.com
Sun Oct 25 11:51:36 EDT 2009


On 2009-10-25 14:48 +0000 (Sun), Iain Barnett wrote:

> On 25 Oct 2009, at 08:31, Magnus Therning wrote:
>
>> Also, as I'm sure you've found out re libraries, more isn't
>> necessarily better.
>
> Definitely. Choice can become a real pain, especially in the face of  
> lacking documentation.

Or if the choices are from a set of bad things. Being a guy who
understands the point of RDBMSes, Hibernate is near the top of my hit
list.

But way back in my Java days (i.e., the days when I was converting
people from Python to Java--I am ashamed of this[^1]) even I had my
doubts about Struts, and and so I had our team's greatest promoter of
Struts grab his favourite other developers and put together a Struts
prototype of the system we were about to build, while I did a home-grown
"framework." Struts came out at three times the amount of code, and was
more confusing.

Now, putting my manager hat on, if I'd decided I wasn't going to program
any more and had a gang of six Struts-experienced people, I might well
say that Struts would be the way to go anwyay. Chosing the Ford model of
software production, making sure that every programmer is a replacable
cog, and knowing you're going to have to hire a lot of them, is actually
a reasonable business approach in many situations. 

But in others, such as the Viaweb one, you'll lose, as we've seen.

Consider your original proposition:

> That means that a language with a stable code base, good/many
> libraries, and a large pool of developers is a good choice. 

Let's compare with what Paul Graham contemplates in "Beating the
Averages" (http://www.paulgraham.com/avg.html):

] During the years we worked on Viaweb I read a lot of job descriptions.
] ... After a couple years of this I could tell which companies to
] worry about and which not to. The more of an IT flavor the job
] descriptions had, the less dangerous the company was. The safest kind
] were the ones that wanted Oracle experience. You never had to worry
] about those. You were also safe if they said they wanted C++ or Java
] developers. If they wanted Perl or Python programmers, that would be
] a bit frightening [keep in mind this is the late '90s --cjs]--that's
] starting to sound like a company where the technical side, at least,
] is run by real hackers. If I had ever seen a job posting looking for
] Lisp hackers, I would have been really worried.

So where do you fall here, Iain?


>>   I'd argue that many, if not most, commonly used libraries are
>> excellent for "common" tasks, but as soon as you go into a niche many
>> fall short of your requirements for scalability, speed, resource
>> usage, etc. In the end you're likely to have to put considerable work
>> into writing your own or modifying others'.
>
> But if someone has already done some of the work, or an app or language 
> is known to have been (at least) partially successful in an area, then 
> this makes it a lot more likely to be picked, right?

Not really. If they've picked a bad interface, or written it badly, or
worse yet, both, it's often a lot faster to just start again than to
try and deal with fixing the crap you've been given. This is especially
true if you don't need full library functionality, but just need a
relatively small part of it. There have been plenty of occasions for me
where it's been faster to write a small, incomplete "library" that works
properly for what I need than to use something existing. (This is not
at all Haskell-specific, by the way, it's just why I don't worry about
libraries in Haskell any more than I do about not using Rails when I use
Ruby.)

> You could make the case, but are you saying that programmers of
> major languages like Java, Perl, Ruby, PHP, C#, C++... aren't
> self-motivated, don't enjoy their language, and aren't clever?

Well, I'll say that anybody who's using one of those (possibly excepting
C#, much as I hate to say it, because there's some awfully good stuff
creeping into that) is indeed behind the curve.

But on that note, I think I'll give this up. If somebody wants to tell
me that I'm going wrong because Clean is really what I should be using,
or because I'm not doing enough proofs in Agda before I translate into
Haskell, I'm willing to listen to that. And hell, you're probably right.

I'm willing to admit I'm wrong about Haskell in the same way that I was
wrong about Ruby, and wrong about Java before that, and wrong about C
even before that, and wrong about...well, we won't go in to what I was
programming in before that. Haskell, for me, is just the next step up on
the road to learning about what it takes to get an idea into a computer,
which turns out to be a lot harder than I thought it was twenty-five
years ago.

On 2009-10-25 14:59 +0000 (Sun), Iain Barnett wrote:

> Then again, I really prefer the Fall over any  Manc band.

Funny, I do too. Still, when Luxuria opened for them in Vancouver in the
'90s, I started to think about what Howard Devoto was doing....

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

[1]: Actually, this may be a key point. A lot of the stuff I advocate
now, I advocate because I did it the other way several times in several
ways. I do it differently know because of that experience. In other
words, "I fucked up."


More information about the Haskell-Cafe mailing list