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 <c...@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." _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe