

Stop wasting billions of dollars using the wrong software languages - the_watcher
http://venturebeat.com/2013/10/11/stop-wasting-billions-of-dollars-using-the-wrong-software-languages/

======
thinkpad20
I very much enjoy coding in Haskell, and would definitely say that it changes
the way I think about code. In particular, it's taught me that strong static
typing, no null references, and avoiding side-effects wherever possible are
all great things and IMO, those who don't use these are doing themselves a
disservice most of the time. I also think that type classes are an excellent
way to handle polymorphism, really quite beautiful. Immutable data is also (in
many cases) a great thing. And the syntax is gorgeous.

However, I hate articles like this; they really don't help their cause, they
sound driven as much by ideology as anything else, and in this case, there's
even a financial motivation. It plays into the stereotype that Haskellers tend
to find their language superior to any other, almost by definition. For
example, many the benefits that the article touts would also be found in
dialects of ML, or in Scala. However, many Haskellers I've talked to poo-poo
these other languages because "they're not pure," or some other vague
criticism. I don't mean to generalize, of course; many Haskellers probably
embrace other languages as well, but it's certainly not uncommon.

Furthermore, Haskell is not at all without its warts: aside from its steep
learning curve, it has package management issues and spotty documentation.
Moreover because of its bizarre IO system (which mostly seems to exist for
academic reasons, not for any practical purpose -- there are other, easier
ways to disallow IO outside of sanctioned functions), it demands the use of
Monads everywhere, and generally insists on a particular style which can be
very restrictive. Last but certainly not least, its default laziness (once
again, done mostly for academic reasons) can lead to bizarre performance
issues, bugs which are hard to debug. The amount of hoops to be jumped through
to accommodate laziness in Haskell is significant, to say the least.

Haskell has a number of great things in it. Functional programming on the
whole is a blast to write and leads to very stable, readable code. But Haskell
is far from the only answer. That said, it is a lot of fun to write, and its
recent upswing in popularity is a very good thing, IMO, aside from the often
pretentiousness of its users. At the least, it's raising the profile of
functional languages in general, and opening the door for new languages which
take the good parts from Haskell and leave behind the not-so-good.

~~~
asdasf
>It plays into the stereotype that Haskellers tend to find their language
superior to any other

So does everyone else. Ruby users don't advocate for ruby because they think
ruby sucks. Replace ruby with any other language and the statement holds true.

>it has package management issues

No more so than other languages.

>Moreover because of its bizarre IO system (which mostly seems to exist for
academic reasons, not for any practical purpose

What on earth are you talking about? Why is it that everyone I see posting "I
totally like haskell but..." on HN displays a very basic ignorance of haskell?
What is bizarre about the "IO system" in haskell? The fact that IO actions
have a type? That is entirely for practical purposes.

>it demands the use of Monads everywhere

It most certainly does not. People use monads frequently because they are
incredibly useful. You do not need to know what a monad is or how it works to
use one.

>Last but certainly not least, its default laziness (once again, done mostly
for academic reasons) can lead to bizarre performance issues, bugs which are
hard to debug

The only criticism in your list that is actually loosely based on reality, and
you still managed to get pretty far off-base. Haskell is not lazy for
"academic reasons" (what does that even mean? Do you think they hand out phds
for making a language "acadamic-y" enough or something?). Laziness was a
choice, just as strictness is. It has pros and cons, just as strictness does.
Being unfamiliar with laziness does not make laziness bad. For 90% of code, it
doesn't matter. For 10%, you want to ensure strict or lazy evaluation.
Regardless of which one is the default in your language, you want the other to
be an easy to use option. This is the case in haskell.

>The amount of hoops to be jumped through to accommodate laziness in Haskell
is significant, to say the least.

I have ~100k lines of haskell code in production. I have never even thought
about having to "accommodate" laziness in any of that code. I have exploited
laziness in a couple of spots as a free optimization, but otherwise it didn't
even come up.

~~~
thinkpad20
I'm not a big fan of condescension and being spoken to like a half-wit. I'm
sure you're much smarter than me. You've certainly demonstrated all of my
favorite characteristics of Haskellers. Like I said, I love Haskell, have
written a good amount of it, and am excited to keep learning more.
Unfortunately, one of the big downsides of Haskell is having to learn it from
people like you.

~~~
asdasf
I was not condescending nor did I speak to you like a half-wit. Unfortunately
it is quite difficult to call someone out on making statements that
demonstrate ignorance without causing offense. Haskell has many problems, but
the things you listed are misconceptions and misunderstands spread around by
people who have heard about haskell but not used it. I'd certainly like it if
you are able to be more specific about what you think the "weird IO system"
problem is.

~~~
maxerickson
In some sense, it is condescending to insist that you were not. You may be
certain that was not your intent, but you can't really know how your words
come across.

------
bskap
Is this a news article or an advertisement for this guy's commercial Haskell
tools? I'm having trouble figuring it out.

~~~
loop0
I'm wondering if his web IDE is made in haskell

~~~
asdasf
It is.

------
memracom
Unfortunately many companies let themselves be led into a complex mess by so-
called "rockstar" developers who usually are just people who have mastered a
particular language and its libraries, and perhaps one common framework in
that language. This allows them to churn out masses of poorly written code and
bamboozle management into thinking that they are 10X productive. They are like
the sales guy who makes some big sales, collects his commission checks, and
then leaves the company before everyone finds out that the product was not
suitable for that customer, and the contracts are cancelled. Then, working for
another company, he does the same thing again. Some companies now withold part
of their commission payments for a period of time to be sure that the product
was sold correctly, that it gets delivered to the customer properly, and that
the customer begins using it and gaining some value from the product.

However, in software, we let rockstars create a big mess, and then over the
next few years we spend many man-years of effort into maintaining that
software, fixing bugs, attempting to shoehorn new features into a system that
is rigid, inflexible and even fragile. This is what rockstars bring us,
momentary euphoria until the concert is over and we are stuck in a traffic jam
trying to get home. This is not scalable and not sustainable. If you see a job
ad that asks for rockstars, run away. Their management are fools and they are
busing building a complex mess that will destroy their business.

------
forgottenpaswrd
Stop telling me what to do.

This is like telling Chefs they should not use pointed and sharp knives as
they are dangerous in the wrong hands.

We use Haskell when we need it. Useful for some works, totally inappropriate
for others.

~~~
asdasf
>This is like telling Chefs they should not use pointed and sharp knives as
they are dangerous in the wrong hands.

How is it like that at all? It is telling people to use a tool that does the
job better. If you don't believe the tool is better then that is certainly a
debate you could start. But making bad analogies doesn't seem to be a good way
to do that.

~~~
jameshart
What it's like is telling everybody who does any cutting at all that they're
doing it wrong because they're not using a sawzall. You are wasting time, and
your clients money, by doing your cutting any other way!

But I'm a sushi chef. And my friend here is a child working on a cutting-and-
sticking project.

 _Never mind that! The sawzall would cut 90% quicker and the blade would last
five times longer!_

This argument is not going to end well.

~~~
asdasf
No, it isn't like that. At all. It isn't even remotely close. Making bad
analogies is not productive. It is like someone saying "haskell is safer than
python, but just as productive, you should give it a try". So lets discuss
that, instead of bizarre kitchen powertool fantasies.

------
alarge
Can someone address the actual usefulness/fit of Haskell as a general purpose
programming language for development of complex systems?

Most of my career (roughly 30 years), I've been a Unix server-side engineer,
writing code in C and C++ with a smattering of Java every now and then. With
my latest job, I've picked up Ruby, Javascript (including Node.js) and Go. Of
the three, I tend to prefer Ruby for small utility code and Go for serious
server code.

In addition to the relatively clean syntax of these languages (and Go's
awesome concurrency paradigm), one of the things I really like about the
modern crop of languages is the library and 3rd-party support. Need to talk to
mysql? There's a gem/package/module for that. Redis? Same. Pubnub? Same. Stuff
like http is baked into the standard libraries. Need to implement a high-
performance logging subsystem with file rotation based on age or size? These
languages all provide library access to the necessary OS fundamentals to do
that. In short, I haven't found very many problems that I could solve in C++
that I can't in Ruby or Go (or probably in Node). And with a lot less effort
and (at least in Go or Node) at close to the same performance.

I hear the whole "functional programming is better" pitch, and I have very
limited knowledge/experience in that area. What negatives does a paradigm
shift from "imperative" to "functional" programming introduce? Are there some
classes of problems that _aren 't_ appropriate for a language like Haskell?
Are there real-world examples of high-traffic services where the entire
backend is built in Haskell?

~~~
asdasf
Most of what you describe applies to haskell just as it does to everything
else. It is a general purpose programming language. If you want to see what
packages are available look here:
[http://hackage.haskell.org/](http://hackage.haskell.org/) Yes, simple http
support is in the standard library, more full featured http libs are on
hackage.

As for the functional programming question: I haven't found any negatives. I
went from imperative programming to ocaml specifically because I thought the
whole functional programming thing was just hype and wouldn't really be
suitable for everything, so I wanted to be able to fall back on imperative and
OO styles as needed. After a few years of never needing to fall back, I
decided to take a closer look at haskell.

The places haskell isn't ideal are basically the same as other high level
languages. If you are doing bit twiddling or need precise control over how
data is laid out in memory, you pretty much want C. I also still use shell
scripts for little sysadmin stuff. Other than that I pretty much do everything
in haskell now: web development, random utilities that are bigger than I want
a shell script to be, network services, etc.

------
pekk
The idea that Python is a low-level language and that this is why software
costs money to maintain is stupid. There isn't a better word to describe this.
It's just stupid nonsense.

------
thescribe
Just another functional programming will be bug free and wash your car
article.

------
the_watcher
Any professional programmers care to weigh in here? I have always been under
the impression that, while Haskell/Scala/insert super awesome programming
language may be the "best" language, you should really be using the right tool
for the job, which should mean different languages for different tasks. All of
this assumes an equal supply of talented programmers for every language, by
the way, something that I am aware is far from true.

~~~
memracom
The article DOES recommend using different languages for different tasks. A
large part of it was about Ruby and Python shops that added Haskell to their
toolbox in order to clean up overly complex parts of their codebase.

As far as the supply of programmers is concerned, if a software developer is
TRULY talented, then they will be able to learn a new language in a couple of
days, and learn a new paradigm (such as functional programming) in a couple of
weeks. I say this as a person who has moved from imperative programming to
object-oriented programming to functional programming over my career. And I
have used so many languages that I have difficulty even enumerating all of
them. They range from machine language, to various assembly languages to
FORTRAN, COBOL, C, Visual BASIC, Java, Python, Ruby, Scala. The hard part of
programming is not the coding. It is the DESIGNING. If you do the design part
well, then the code flows from your fingers naturally, and you end up doing
very little debugging, especially if you practice TDD which forces you to
debug problems within 15 minutes of creating them.

~~~
EpicEng
Well, I don't know about a couple of days for learning a new language, but I
agree with the sentiment. Learning a new language is more than figuring out
the syntax for a loop. It's the library(s) that takes time.

------
metaphorm
this article is terrible. simultaneously self-promotional garbage for the
author AND "cult of Haskell" magical thinking.

------
kabouseng
If the advantages of using Haskell (or any other language) are so clear cut,
wouldn't the market automatically switch to Haskell?

Clearly the fact that the most of software is not written in Haskell shows
that Haskell is not the silver bullet for all software development as this
article and other FP pundits claim it to be.

~~~
Jtsummers
_If the advantages of using Haskell (or any other language) are so clear cut,
wouldn 't the market automatically switch to Haskell?_

That's a specious argument, you're assuming that "the market" is infallible,
which is far from evident. I'm not going to say that Haskell is great for all
or even half of all applications out there, but market acceptance is not a
valid argument against it.

