
Why isn't Haskell popular in industry? - ab9
http://www.palgorithm.co.uk/2010/05/why-isnt-haskell-popular-in-industry/
======
stephenjudkins
I think there are a couple reason.

Haskell is a significant departure from most other languages commonly used by
industrial programmers. It's a relatively shallow learning curve from Java to
Python to JavaScript, but making the leap to a pure functional language is
very difficult. Path-dependence plays a huge part here. This isn't just a
matter of "people being afraid of what's different" as the article suggests;
there are very rational reasons for a profit-seeking firm to exploit the fact
that their developers (and those available to hire) are already relatively
proficient at writing procedural code.

Another, more important reason, is that Haskell is too intellectually
demanding for most industrial programmers. I consider myself an enthusiast of
functional programming, but achieving anything practical using purely
functional code remains extremely difficult for me, even though I regularly
dabble in it during my free time. The Haskell IRC channel can be helpful, but
it's very difficult to square "Haskell is easy enough for anyone to learn"
with the inevitable "you are too stupid/impatient/incompetent to use Haskell
effectively" taunts you're likely to hear, when you're asking for help to
perform a simple task. Many Haskell evangelists don't understand that most
developers aren't nearly as smart or dedicated as they are.

I'd be curious to know where most Haskell users believe they lie on the
distribution of programming ability. I'd estimate most of them lie at the 99%
percentile, and that any of them arguing otherwise are doing so out of
modesty. (Note that I'd include dedication and curiosity in with intelligence
in this metric.) I believe the most likely explanation for this is that
Haskell is a particularly difficult language to use effectively.

~~~
gaius
_Another, more important reason, is that Haskell is too intellectually
demanding for most industrial programmers. t_

While that's often stated as a reason, I don't believe it myself, simply on
the grounds that anyone smart enough to use C++ "in anger" is smart enough to
learn any language.

The reason that Haskell isn't popular (IMHO) is that a lot of programming
isn't clever algorithms, it's forms (interfaces for getting data into
databases) and reports (interfaces for getting data out of databases). A lot
more is glue (connecting the output of one program to another). Haskell just
isn't a good fit here.

I am very excited by F#; here we have an ML dialect that has minimal impedance
mismatch with the OO/imperative world (and C# with LINQ has minimal impedance
mismatch with the declarative world of relational databases). This is where
Haskell types should look for work...

~~~
jrockway
Why is Haskell not a good fit for glue? That's what I use it for, and it works
great -- my programs are short, efficient, and easy to write and test.

My first Haskell project for work was initially a C++ project, but it was too
hard to use C++ as a glue language, so I switched to Haskell. I would have
used Perl, but Haskell works better on Windows and has an easier-to-use FFI.

I actually ended up spending more time trying to get some old version of
Visual Studio to link against my super-old-proprietary-C-library that was the
core of my project than I did writing the whole Haskell FFI binding to that
library and writing the first version of the Haskell-based program.

This turned out to be the most trouble-free program I ever wrote. It had to
operate on large datasets, and never died in the middle (like I'm used to with
Perl). The only bug that the program ever had was where one of my data
validation rules was too strict, and rejected some valid date. (The validation
rule said that the dates in the time series had to be increasing. But one
series only had one point, and hence wasn't strictly increasing. The bug
resulted in "Warning: bad data", though, not "Prelude.(!!): index too large",
as the implementation was with fold.)

Incidentally, as a result of this project, c2hs supports Windows DLL calling
conventions :)

~~~
gaius
After having written that, I realized it was more nuanced than that. Haskell's
good for parsers, for example. I am actually working on one for a proprietary
logfile format right now (it will "convert" said logfiles into SQLite .dbs).
But if you have preexisting libraries for system A in Java and system B is
CORBA then you would be mad to put Haskell in the middle, the impedance
mismatch is too great.

~~~
jrockway
This is a software-engineering-in-general problem, though, not a Haskell
problem. If you have a bunch of components that can only communicate in a very
specific way, then all the components have to communicate in that very
specific way. This limits flexibility and "working with the system" becomes
the main engineering problem. I think this is why most software dev teams
explode to needing 10 teams of managers to manage a million developers --
because so many "irreversible" decisions were made that the application
becomes workarounds on top of workarounds. Haskell is not going to magically
eliminate bad planning and the fear of refactoring. And similarly, it's not
going to make it easy to keep adding shit on top of the shit pile, like Scala
or Clojure would. (Not to dis on Scala or Clojure specifically. I've actually
never seen anyone do this; they just add more Java 1.4.2 on top of their
existing Java 1.4.2-only mess. It would be me that added the Scala or Clojure
:)

I actually have a problem like this right now; I'm starting re-development on
an application whose components talk via CORBA over an ultra-expensive and
ultra-overengineered proprietary message bus. My plan is to write a bridge
between the proprietary message bus and JSON-RPC (or something like that) in
Scala, and make the rewritten components only talk JSON-RPC. Then, when
everything is rewritten, there is no more super-expensive-message-bus
requirements, and we shut it off. Now we have the ability to write components
in any language.

(Also, the reason this doesn't count as adding shit on top of shit is because
eventually the ugly bridge will go away. That only exists to make the rewrite
into a refactor. You have to have a scaffolding, or all the shit will collapse
on top of you and make a big mess. :)

Now I know the reply is going to be, "well, not everyone can just replace
their proprietary crap with something simpler and more generic", but again,
that's not a Haskell problem.

------
lelele
Haskell is not popular because to be popular you must cater to the average
Joe. And to cater to average Joe your foremost goal must be not making him
uncomfortable about himself. Never forget this.

And since most average Joes just work to pay their bills, they don't give a
damn about technical superiority, you know.

~~~
CamperBob
Speaking as a very experienced average Joe, all I need to see is a use case
that shows how learning all of the weirdness discussed in the other comments
in this thread will help me do my job.

I can't remember the last time I had trouble getting something done in C
because it didn't support Kleisli arrows, or whatever.

~~~
lelele
Thanks for pointing this out, too.

Indeed Haskell lacks a proof of concept of its superiority. And you can't
provide such a proof with a few lines of code.

When I studied Erlang, I was flabbergasted by both code size reduction and
expressiveness thanks to pattern matching, by its fault tolerant capabilities,
by its hot-code swapping... then reading how Yaws was alive and kicking long
after Apache died under heavy load.

------
Niten
I think the main issues are that lazy evaluation makes it more difficult to
reason about the performance of your code, both in terms of what actually gets
computed in which thread / on which core, and in terms of space requirements
(lazy evaluation can force the runtime to keep things referenced longer than
you might expect offhand). I'm not saying a good Haskell programmer can't
overcome these obstacles, just that this is definitely a perceived barrier to
commercial Haskell development.

Check out this paper for a discussion of these issues in a real world Haskell
application:

<http://www.starling-software.com/misc/icfp-2009-cjs.pdf>

------
seldo
Failing to work on Windows is a much bigger problem than I think most people
realize. You can write Java on Windows and (mostly) have it run on Linux or
Solaris with no problem. And Windows has a 95%+ share in the corporate OS
market. Ruby on Rails has a similar problem (though it's got better on Windows
recently), and so does Django, which is a nightmare to get working in a
Windows environment.

~~~
Lewisham
I'm not sure that these are really the same market share segments. Django,
Rails and all that server side stuff is best run on servers, which more often
than not, are going to be running a *nix.

Windows has C# and all that, and it works nicely for them.

Perhaps this leads to a wider question of who the Haskell audience really is
and what problems they think they solve. Lots of languages have pigeon-holes,
Ruby has its super dynamism, Python is an excellent scripting environment, C
is fast, etc etc. Haskell is... mathsy. Mathsy applications already have
Matlab and such.

I think at the end of the day, Haskell will probably remain a language from
which other languages learn from, and that's OK, and that doesn't mean it's
unimportant (I think even SPJ has said similar).

~~~
bmj
I think the issue here is buy in from management. If I work at a Windows-
centric shop, it's much easier to sell a different platform if it doesn't
require building new servers for it. It's much harder to pitch a project when
your requirements include new OSes and servers.

For example, I work at a Windows-centric shop, but if I could make a
compelling case to build a tool/product on a different platform, I could get
my boss to approve it _if_ it didn't require a new piece of hardware. We have
written tools in other languages besides C#, but we stick to languages that
are easy to deploy on our current servers.

------
nephesh
As someone who has been learning Haskell recently I think I can bring up a
point that no one else has. Record syntax in Haskell sucks. Most business
programming revolves around a form of DDD, where each of your business
entities are fairly well defined. Creating records that match these business
entities is fairly simple, working with them is not. None of the web
frameworks I've seen follow a model based approach where you bind directly to
your form representation of a model. I've been trying to figure out a way to
do this in Haskell, but it looks like I have to learn Template Haskell and
Generics on top of the already steep learning curve of Haskell, for something
that would be simple in almost any other language. So far I haven't given up,
but I don't see mainstream programmers getting into Haskell until they can
describe their processes in a model focused fashion (and no, I don't mean with
OOP).

------
d0m
Even thought I don't agree on this argument, I would add:

\- Because it's not OO.

~~~
cmars232
Why doesn't Haskell support objects? Seems like that would be quite useful.
They don't need to be mutable or anything. They could be like records, that
scale.

~~~
silentbicycle
Because it has typeclasses, which solve the same problems without creating the
new problems that conventional objects do.

Why doesn't Java support pattern matching?

~~~
barrkel
Typeclasses don't solve the same problems as objects do. Typeclasses are a way
of getting access to more operations in polymorphic code, which in functional
languages is a compile time feature; they're also a way to implement
overloading.

Objects are a way of implementing protocols without needing to know the
details of the object that implements the protocol, even at runtime.
Polymorphic code in OO systems is a runtime feature, not a compile time one;
objects may be loaded dynamically and almost always are at some level in any
large OO system, for configurability and testing if nothing else.

~~~
loup-vaillant
Because two features are different doesn't mean they don't solve the same
problem. Here, most of the time, class polymorphism is used to solve problem
best solved with parametric polymorphism (sometimes called genericness).

    
    
        class Base
          Base(int i_init)         -- constructor
          virtual int f(int param) --  a method
        
        class Inherit1 (extends Base)
          int f(int param) -- reimplementation 1
        
        class Inherit2 (extends Base)
          int f(int param)  -- reimplementation 2
        
        class Inherit3 … (ad nauseam)
    

We don't need class polymorphism with inheritance, here. We can do simpler:

    
    
        class Base
           Base(int i_init, int f_init(int)) { f =: f_init; … }
           int f(int)
    

Or even simpler:

    
    
        int f(int i_init, int f_init(int)) // C-like syntax
        f: int -> (int -> int) -> int      -- Haskell syntax
    

(And don't tell me that passing function as parameters is weird, or
complicated. Functions are typically way simpler than "Objects".)

------
theli0nheart
Every language has a catalyst that pushes it from obscurity into mainstream
use. Whether it be a project (Ruby on Rails), a programmer (Linus Torvalds ->
C), a company (Google -> Python), or a library (Boost -> C++), there is always
a _force_ behind adoption.

Most languages undergo a "fad period", where it's hip and cool to write in it
and people just do it because other people do it. Clojure is going through
this right now, as are Scala and (arguably) Haskell.

We'll just have to see. I honestly hope Haskell becomes popular. Judging by
<http://shootout.alioth.debian.org/u32/haskell.php>, performance really isn't
an issue. It's more of just an issue of programmer adoption and a willingness
to throw yourself out there to spend some time to learn how to think outside
of the imperative programming box.

~~~
watmough
This reddit post tells me why Haskell isn't that popular.

[http://www.reddit.com/r/haskell/comments/cs54i/how_would_you...](http://www.reddit.com/r/haskell/comments/cs54i/how_would_you_write_du_in_haskell/)

Writing a quick directory traversal function should be a no-brainer in any
reasonably general-purpose language. The fact that the above reddit thread is
jam-packed with the ins-and-outs of doing this simple task in Haskell tells me
that Haskell may be great for some things, but it's probably not general-
purpose, or a great fit for anything close to the heavy I/O, streaming,
processing sorts of code I write.

I actually own Real World Haskell, and have tried off and on to get into it,
but I found that Clojure 'took' in my brain 1000x more easily than Haskell.
It's a real bitch, because I'd love to be able to say I can write Haskell, but
gosh-darn it, I just can't. Grrr. Sigh.

quick edit: in answer to your point about a 'killer app' for Haskell, the
parsec parser-combinator library looks bloody brilliant. Maybe if I run across
a parsing need, maybe it'll help me get something useful out of Haskell, but I
suspect my brain just doesn't get on with the Haskelly/MLy languages.

~~~
Confusion
To illustrate this point, a choice snippet from that Reddit thread, explaining
part of what seems to be considered 'the proper solution'. Please note that my
intention is not to make fun of this, but to illustrate that the terminology
in which people in the Haskell community communicate makes it impenetrable for
someone just trying to pick up the language and do stuff with it.

    
    
      it's a straightforward lifting of the non-monadic version. You can almost get
      it from g_hylo by using the identity comonad, it's distributivity law, the
      identity natural transformation, and using T.sequence as the monad's
      distributivity law[1]. But this doesn't quite get us there because it requires 
      that we can refactor the monadic parts of the coalgebra into the algebra.
    

[http://www.reddit.com/r/haskell/comments/cs54i/how_would_you...](http://www.reddit.com/r/haskell/comments/cs54i/how_would_you_write_du_in_haskell/c0uxleq)

~~~
applicative
I think you are being misled by the seemingly simple headline "how would you
write du...". The question was not straightforwardly practical but deep in the
territory of so-called 'recursion schemes:

    
    
       The natural way to do this is to use an unfold to
       generate a list or tree of all the files in the 
       directory tree, map over them to get the sizes,
       and do a fold to get the total.
    

\-- And similarly elsewhere, more explicitly, as he makes clear why he isn't
interested in the 'obvious' solutions, e.g.:

    
    
       Yep, this is a good practical approach if I just want 
       to "du". I'm looking specifically for the fold . map . 
       unfold approach ...
    

The interventions of doliorules and then winterkoninkje (whom you quote) were
in fact the ones that spoke to his condition.

------
zv
Well I've read comments so far and I did not see anyone mentioning this.

I program both on desktop and on web.

On desktop I program C# which is mediocre and recently I have started using
C++ with Qt. Qt has huge advantages over C# (QtCreator is IDE that is going to
be better in time than Visual Studio, currently it lacks few features, but
still I find it usable). On both languages I have my set of libraries which
you can't find everywhere else and make my life easier.

On web I use php and sometimes I use Rails. Each has advantages, I use php
cause I've used it since php3 so a lot of historical baggage. On each I have
my set of code and libraries I use the most.

So lately there's a whole new languages and frameworks coming out. Why should
I spend my time porting my libraries to Haskell? Do I get significant
advantage coding in it? No, because I use mostly my own libraries.

------
nradov
Because it doesn't run on the JVM.

For a variety of reasons — including critical third-party libraries — anything
that doesn't run on the JVM and interoperate with legacy Java code is just a
non starter for my company. I suspect many other organizations are in a
similar situation. It looks like someone is working on a JVM port now so
hopefully we'll see something usable in a few years.

~~~
loup-vaillant
Just to be sure: do (or would) your company use Clojure?

~~~
nradov
It's under consideration, among other options.

------
MissT
Haskell's motto is "Avoid success at all costs!"

It succeeded.

I appreciate the fact that Haskell's designers don't look down on "average"
programmers like the Java designers did but I think it's sad that they don't
look at all.

------
dasil003
Most code just doesn't need to be guaranteed correct, plain and simple. If
more code did, then Haskell would be more popular.

------
j_baker
Haskell's a statically compiled language. Wouldn't the "embeddable Haskell"
the author proposes essentially be a library?

~~~
andolanra
Only to the extent that Firefox is a JavaScript library. I think the major
idea is that there is some application whose operation is very broadly
directed by the embedded language, in a sandbox-like environment designed for
the embedded language. For instance, you could write a video game whose
graphics and collision detection and whatnot are all C++, but have Haskell
bindings so that all the high-level game code would be Haskell. This isn't all
that different from the usage of the much more C-like UnrealScript, which is
used for exactly this purpose and is both statically typed and compiled, if I
recall correctly.

------
jberryman
Actually a decent post and discussion.

------
rimantas
Not to answer the question, but I can provide some reasons why I am not going
to learn Haskell. I must say up front that I know next to nothing about the
language, and my reason my sound very irrational, superficial and plain silly,
however: it just looks ugly. That's it. I cannot imagine myself sitting all
day and staring (or writing) something that looks like explosion on a regexp
factory with ruins of Perl fallen through. True, the beauty is in the eye of
the beholder, however even if I believe there are beautiful thing which may
need considerable effort and understanding to appreciate the true elegance of
it I cannot imagine such thing being ugly at the first sight. For me it just
looks like a lot of effort went just to make it look different. _Maybe_ it
makes perfect sense once you learn it, but it just does not look elegant and
thus kills all the motivation to try. This all of course is IMVHO.

~~~
loewenskind
Really? How beautiful it is is exactly what keeps drawing me to Haskell even
though I have more invested in the dynamic language camp.

>max = head . sort

Due to the laziness, the above will find the max entry in O(n) time, just like
your hand written loop would. How can you _not_ find that beautiful?

Now I do agree that they often seem to use too many symbols that look like
other symbols but the few times I've investigated it actually ended up making
sense (e.g. Arrows).

~~~
ithkuil
I love haskell and understand your point. Laziness is beautiful and allows to
express things in a simple way and also improve the reusability of the code
etc.

However I think that you didn't pick the best example.

I tried out:

>head $ sort [1 .. 10000000]

6 secs, using ~2g of heap! (actually is should be a reverse sort)

and the "hand coded loop":

>let mx (x:xs) m = if x > m then mx xs x else mx xs m; mx [] m = m >mx [1 ..
10000000] 0

3 secs, heap usage stays negligible low and constant.

Something is clearly not behaving as you depicted.

(of course my 'loop' code is not the exact equivalent of the last.sort
composition, since it requires a 'minimum' parameter to be passed in advance,
which not all types have. On the other hand it works also for the empty list)

I also have the feeling that, unless special compiler optimization (a very
'specific' one, I fear), the simple application of the 'head' function to a
sorted list would stop when the first result element is produced, which is not
after O(n). Granted, you don't have to wait for a full sort, since the sorting
algorithm could guarantee that the rest of the list contain 'lesser/bigger'
elements only and thus stop. But keeping track of all this should be space
consuming, in respect to a simple linear scan.

Anyway the space problem of the "lazy" solution is a bigger issue than the
number of comparisons.

I'm not a haskell master, but if I got it right, one of the mayor problems of
lazy programming is that in some situations it can degenerate to a huge
amounts of "unevaluated thunks", which are frozen computations yet to be
performed, but which require some state to be held in memory (like function
arguments, I guess).

(<http://www.haskell.org/haskellwiki/Thunk>)

or in this case, the space usage is caused simply because the list has to be
materialized in memory instead of be simply traversed and generated on the
fly. (but 2g seems slightly too much).

Anyway, the point here is that the two methods are not equivalent.

I think that understanding the impact of laziness on space is an issue that
certainly increases the learning curve, as it requires time to master this and
other optimization techniques if you want to get predictable performances from
haskell.

(BTW, I actually use haskell for work, perhaps in a slightly conterintuitive
way. I use haskell for quick prototyping ideas and solutions. Sometimes I get
inspired by the solution I end up with haskell and translate it in clojure or
java (work requirement), or at other times I have to rewrite it completely,
but the possibility to quickly prototype in haskell really helps me a lot. I
would love a stable ghc JVM backend.... it would change my life)

~~~
ithkuil
I found this article referencing the O(n) complexity for the 'head . sort'

<http://apfelmus.nfshost.com/articles/quicksearch.html>

As far as I can understand from the blog and and the cited mailing lists, it
works but it requires a carefully coded sorting method, otherwise O(n log n)
as expected.

~~~
jrockway
Yes, you have to pick algorithms carefully in any programming language.
Haskell is a tool, not a magician.

------
codexon
I outlined some of the problems a while ago:

[http://www.codexon.com/posts/why-arent-functional-
languages-...](http://www.codexon.com/posts/why-arent-functional-languages-
like-haskell-and-ocaml-popular)

Short version: Haskell is harder than C while being slower and uses more
memory. The main implementation GHC, comes with GPL concerns.

~~~
dons
GPL concerns? Its BSD licensed. Haskell's library system is perhaps uniquely
BSD-friendly, with over 75% of libraries BSD licensed.

And as pointed out at the time, commercial users already funded the -dynamic
flag, along with the ability to swap out libgmp.

So that's FUD. As was pointed out in this forum at the time:
<http://news.ycombinator.com/item?id=847120>

~~~
codexon
The default behavior was to statically link to libgmp. I don't know about you,
but making people's programs GPL by default doesn't exactly inspire confidence
in the industry.

~~~
dons
Whether or not libgmp was ever statically linked by default depended on your
distribution. Were you shipping apps on Windows prior to the -dynamic flag's
introduction? If so, then you were watching what libraries you were using, and
following these instructions: <http://haskell.forkio.com/gmpwindows>

These days you can just run "cabal license-check" (IIRC) which will type check
all the libraries you use for compliance.

Have a nice day.

~~~
codexon
Dons, I know you are devoted to Haskell and will not take any criticism of it
lightly. But I am not your enemy. I am willing to praise it myself when it is
more suitable. Not when you try to spin it.

You and your supporters succeeded in bombarding every article that even
mentions Haskell the wrong way with snide comments, and probably won over a
few hobbyists. At the end of the day though, the managers making the decisions
will not think "Don Stewart said so, it must be true". They will find the same
conclusions that Jon Harrop, myself, and other people you have ostracized have
found. And this will continue until it even if you succeed in suppressing all
negative feedback on Haskell.

Have a nice day.

~~~
loup-vaillant
The only thing I ever saw Don Stewart "bombing" were factual evidence. And
what he destroys by truth should be annihilated anyway (P. C. Hodgell).

"Don Stewart said so, it must be true" actually isn't such a bad heuristic (as
far as Haskell is concerned). From what I've seen, Don is quite cautious.

~~~
codexon
_The only thing I ever saw Don Stewart "bombing" were factual evidence._

This is not surprising coming from someone involved with Haskell. Do I really
need to point to you the bug ticket that it was only 8 months ago that you
could use something other than GMP?
<http://hackage.haskell.org/trac/ghc/ticket/601>

Even with the option to dynamically link, it still doesn't change the fact
that it was the __default__. And what a scary default that was. Company
lawyers don't like to touch anything related to GPL with a 10-foot pole, for
the reason that it is really up to the jury to decide what is a "derivative
work" even if you only link dynamically! Maybe if you live in France, or have
a 5 person company, this is an acceptable state.

Anyway I am done, you and Dons win, are you happy? I simply have no ulterior
motive or incentive to defend my findings against organized groups who have
their livelihoods and PhDs based on Haskell.

~~~
loup-vaillant
Err, I was only objecting to your attack on Don's on-line behaviour. Actually
I'm (still) an outsider. Consider "what I ever saw" as anecdotal evidence.

Now it's a pity that companies are scared of the GPL. As far as I know, most
software is custom or private, is never released[1], and thus can't possibly
infringe the GPL.

I think the real problem here is corporate culture. No company would object
using the glibc in a proprietary program. So why would they be scared of any
other LGPL library? When they don't even release the software? That's plainly
irrational.

Now our choice is hard, but simple: get rid of the "GPL == we can't use it"
line of thinking, or get rid of restrictive licences.

[1]: Many custom software actually belong to the company that wrote it, rather
than to the company (or government) that purchased it. In this case GPL
infringement could happen. But really, I can't fathom why some customers still
don't demand complete ownership (including source code) for their custom
software. That strikes me as either wildly misinformed or incredibly silly.

~~~
codexon
Why do you object? I just proved to you the legitimacy of my arguments while
you still stand by Don's complete denial?I think it is very off-putting that
anything remotely negative about Haskell is usually met with snide comments
questioning their intelligence or being labeled as a troll. It also doesn't
help that my comment was upvoted a few times, and when Dons & Co. replies, it
drops to -3. I've also observed this type of behavior on Reddit.

You aren't really an outsider considering your participation in the Haskell
Cafe mailing list and being credited in Real World Haskell.

And companies do object to using glibc in a proprietary program obviously. You
are probably thinking of the GCC runtime which has an explicit exception for
commercial programs that prevents them from turning GPL.

<http://www.gnu.org/licenses/gcc-exception.html>

You also don't have any proof that most software is custom or private. Even if
it is the majority, you cannot deny that the shrink-wrap industry is huge,
especially during most of Haskell's existence. The answer is to avoid GPL code
in the language which is what I was saying the whole time. You don't put the
foundation of your business at risk just so you can use a cool new language.

~~~
loup-vaillant
> _It also doesn't help that my comment was upvoted a few times, and when Dons
> & Co. replies, it drops to -3._

Interestingly, I saw it happen almost everywhere. It looks like people are
more likely to down-vote comments which are contradicted by a recognized
authority. This is of course not a good thing.

> _You aren't really an outsider considering your participation in the Haskell
> Cafe mailing list and being credited in Real World Haskell._

I didn't post more than a few messages, 2 years ago, and I posted about 3
minor comments in Real World Haskell. I've read a few papers, but seldom have
written anything (except <http://www.loup-vaillant.fr/articles/assignment> of
course). I'm not an outsider, but hardly what I consider to be an Insider.

> _You also don't have any proof that most software is custom or private._

I don't. But in this (huge) niche, my point still stand: being afraid of the
GPL is silly. Corporations that are should stop being.

> _you cannot deny that the shrink-wrap industry is huge_

I cannot and I won't.

> _The answer is to avoid GPL code in the language […]_

Yes, assuming you want the (proprietary) shrink-wrap industry to use Haskell.
_I_ want it gone. Therefore, I see the GPL as the solution.

