
How does one get off Haskell? - iamelgringo
http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html
======
mahmud
He doesn't know this, but he really needs a good manager to mentor him. He is
a classic case of a "Perfect Language Programmer"; people like him, if not
supervised, can drive themselves insane and into isolation, not to mention
poverty.

It's impossible to lose a refined taste once you develop it, and in my
experience, the best way to overcome it is to have someone believe in you. If
you don't have the business sense to discover an interesting niche where you
can apply your skills to solve difficult problems for a small industry as an
individual, the next best thing you can do is join a "boutique" shop headed by
someone with excellent mentoring skills.

An ideal manager would be someone who appreciates your skills, but can also
steer you firmly when conformance is necessary to reach an important
objective. People like those generally love to exploit automation; you will be
allowed to write all the haskell you need for in-house tools and automate your
development processes, maintain data, and generally oil the office engines.
However, for the pieces of software that you need to _ship_ , you will be
given enough boilerplate code and development guidelines to make the
temptation of the Perfect Language impossible; you wont be as eager once you
get your fix coding peripheral projects anyway. It's always a good idea to
start at maintenance, that way you get a good understanding of the
infrastructure, while absorbing their development culture and the Ugly
Language. Maintenance code is usually big and important, and you will not even
think about rewriting it in something else.

To get a job, I would start by responding to job ads that state problems, not
those the prescribe solutions. My initial exchanges with them will be informal
emails, never send your resume off the bat. Inquire about the project, ask
questions, and demonstrate your skills. You will get more response by being
humane and eloquent. Explain to them that the technology is the same
underneath, that you have a deep knowledge of the fundamentals, and that their
job is phrased such that it asks for individual instances and ignores the big
picture. An analogy or two might come handy, internal-combustion engineer vs
Honda Civic mechanic. It's always a good sign when you see companies
advertising positions that require broad skills, across languages, APIs and
platforms. It means it's a development shop, or they're at the exploration
stage and you might be able to influence decisions.

~~~
stcredzero
I have his problem, but with Smalltalk, and there is yet another dimension to
it, since a lot of corporate Smalltalk is "stupid and ugly".

The Refactoring Browser parser tools save me time and again. Instead of
writing code, I write code that writes and transforms code. He should be able
to do this for Java with the libraries in IntelliJ. Not sure what's out there
in .net land.

Facebook is doing this to PHP with Haskell!
<http://www.haskell.org/haskellwiki/Haskell_in_industry>

------
dschobel
A nice answer to a silly question:

 _Ultimately the problems to be solved are the same, it's just that java and
c++ give you a lot of padding where you're writing boilerplate and workarounds
for not having closures, monadic values, a nice type system, etc. It could be
relaxing in the same way that playing 3rd trombone could be: you still get to
play technical music every once and a while, but you also get a lot of
downtime to count rests and listen to the music, or play whole notes. There is
a pleasure in that, even if it's not the same as when you're in the 1st violin
section. Music is still being made, problems are still getting solved._

[http://www.haskell.org/pipermail/haskell-
cafe/2010-June/0790...](http://www.haskell.org/pipermail/haskell-
cafe/2010-June/079088.html)

~~~
rntz
Using a worse ( _ahem_ sorry, "dis-preferable") language isn't like playing an
easier part. You're still expected to solve the same problems, just in a
different way. It's more like trying to wheeze out the same piece on a beat-up
second-hand _excuse_ for a trombone.

~~~
Raphael_Amiard
No it's not, because you wont get the same sound from the beat-up trombone,
whereas you can reach the exact same result programming in C# or java

~~~
stcredzero
You can play the same melody, but technique might suffer, and the result won't
be as pretty. That can be frustrating.

~~~
Raphael_Amiard
What i am getting at is that, no matter how _hard_ you try, the result won't
ever be the same. The fact that the melody is the same isn't good enough, it
simply won't sound the same. The instrument has a definitive palpable impact
on the end user (the listener in this case).

That's simply not true of programming languages. The programmer _may_ take
longer to get the same result in Java than in Haskell, but he can reach the
exact same result.

It may be true about programming languages ecosystems (libraries and such) and
this may have a much more profound effect on the user experience, but
interestingly enough, the ecosystems of Java / C++ are amongst the biggest and
most fertile, so that's definitely not a point against them.

EDIT: One point you might be making is that the programmer's pleasure and
frustration will have an impact on the end result. While already very far from
the musical instrument analogy, for the reasons i have explained above, this
really remains to be proved. The fact that haskell and other 'state of the
art' languages are more pleasurable when you program for yourself doesn't
necessarily map to the fact that it would make programming in an enterprise
context more efficient. It could, but i would like to see cold hard data of
this before making statements such as "the end result won't be as good".

~~~
lars512
This is only true if you think of the result narrowly as a well known final
running state. In reality, what you work with is more like a wavefront which
is updated as bugs are found and requirements are better understood. If you
work in a terrible language, your ability to adapt to conditions which change
daily is not the same as with a good language.

To update the analogy: you're playing an old saxophone, with so many extra
keys that you'll never memorize all the conbinations, and the music is being
slightly changed at every practice. A new instrument, with less keys to
achieve the same thing, allows you to memorize them well, adapt to today's
song, and play it with flair and improvisation.

~~~
Raphael_Amiard
> you're playing an old saxophone, with so many extra keys that you'll never
> memorize all the conbinations, and the music is being slightly changed at
> every practice. A new instrument, with less keys to achieve the same thing,
> allows you to memorize them well, adapt to today's song, and play it with
> flair and improvisation.

Well have you ever played saxophone ? Old saxophones don't have "extra keys",
and better instruments don't have less keys to achieve the same thing, because
you __don't __achieve the same thing with less keys. You're talking about
different instruments then, and as musicians are generally not stuck on the
notion of productivity, they don't even try to quantify such things. This is
maybe the most upsetting analogy i have ever saw. You're literally talking
about things you don't have a clue about (i'm speaking about the musical
analogy here).

Your observations on good and bad languages is very vague, and you're only
moving the problem to changing requirements, but then you have the same sets
of things to prove : Show me hard proof that productivity will be superior
with language x than with language y. I'm totally open to the idea that it can
be superior. I'm precisely saying, you have no real clue as if it is or not,
and it's a __thousand __times harder to define than to define if a saxophone
is superior or inferior to another saxophone.

I have trouble seeing why the idea that improvements in productivity relative
to the "quality" of a language is something that is very hard to quantify, has
so much trouble getting through this argument. Maybe it is because, as
hackers, we have trouble accepting that our pet language of the day isn't
necessarily better, in a production environment, than one of the heavy
weights.

------
Dove
A self-professed perl hacker, my first Real Programming Job had me working
eight hours a day in a horrid little proprietary scripting language without
pointers (or references), without proper data structures beyond arrays, and
with a long list of language warts and misfeatures. Three things got me
through it.

#1: Work on a project you believe in. Are you doing something great? Something
world-changing? Are there people you care about who are going to really
appreciate your work? Do you really, really wish that what you're building
existed? That'll help you slog through with the technology you're forced to
use.

#2: Mentally prototype in your language of choice. I was coding in CrapplyLang
but I as _thinking_ in perl. My code was littered with comments that said, "In
perl, this would be <oneliner>" followed by thirty to fifty lines of terse
nasty.

#3: Get out before it causes permanent damage.

~~~
madrik
Couldn't you have made Perl write the proprietary language programs for you?

~~~
Dove
I was about a month away from doing _exactly that_ when I finally got another
job.

------
FlemishBeeCycle
I love Haskell as much as the next guy, but are we to believe that he has
simply forgotten how to program in an imperative fashion? I doubt that. I
guess he's asking "how do you make programming in ____ less painful"? That's a
very open-ended question. Maybe I'm reading it wrong, but if this gentleman
wants serious responses he might want to get a bit more specific.

Otherwise it just comes off as a roundabout way to talk about how awesome
Haskell is.

~~~
mahmud
I believe him.

Some programming is impossible to get back to. I myself am a read-only C-like
language user; only way I can keep myself interested is to fiddle with obscure
corners of the spec and pushing the compilers, but hardly can I do any serious
programming with them with a straight face.

For me to use a language seriously I must respect it. Having been a Lisper for
10 years, I simply don't respect the market languages out there. I have
absolutely no confidence in their design choices, workflow, environment, or
the engineering methodologies and tools they have spawned to compensate for
their ills. They're palatable in snippets, but for creative flow and work from
scratch, I will quickly convince myself to "prototype" in Lisp, and sometime
later, end up deploying it in Lisp, or generating from it.

If it's not Lisp, then jQuery :-)

P.S. If it doesn't have a REPL that works with emacs, I probably wont touch
it.

~~~
ezy
Would that change if the end goal, the project itself, were interesting? This
type of thing always seems indicative of smart people working on dumb software
to me. Or perhaps a type of avoidance behavior when things get overwhelming.
That is, the software goal itself is so mundane or immense to you, that you
have to shift focus the tools used to achieve it.

From personal experience, the only time I've diddled with tools to an
extraordinary degree or have been less flexible about them is when the task at
hand was either dull, or in some cases, so overwhelming that I had to "warm
up", so to speak, to take on the harder task.

------
plinkplonk
I think his real question maybe "How can I make money writing Haskell?". I
sympathize, but I don't have a generic answer yet. In India the skillset in
demand is j2ee/dotNet.

Thankfully, _my_ clients don't care about what languages their solutions are
written in. (The web is the "gui" in any case) so I've built systems in
Haskell and got paid for them.

------
dasil003
Why must one swing between such extremes? From a language built to further the
state-of-the-art of programming itself, to a language designed to prevent
anything ever surpassing the lowest common denominator in massive monolithic
corporate environments? (okay that doesn't describe PHP, but let's not go
there).

Seems like there's ample middle ground with Ruby, Python, Scala, maybe even
Perl. It doesn't do anything for the underlying fact that most work that's
easy to find is pretty boring, but I suspect a little fun could be had along
the way. It's not likely to be a huge time sink either... the author's
functional thinking will ensure quality is high even if he feels dirty cutting
corners to get the job done quickly so he can get back to his mistress. No one
will ever be the wiser.

------
defdac
I think language agnostic programmers are more genuinely interested in
programming compared to fanbois.

That said you will always be a bit faster in your "native" language. Your
native language skills benifits with experience from other laungages.

There isn't a Golden Hammer.

~~~
michaelfairley
Some languages are just more fun and more productive to work with. There is no
Golder Hammer, but there are jackhammers, and I'd sure as hell rather break
through a rock with one of those than a hammer.

~~~
stcredzero
Actually, there have been many Haskell programs winning programming contests.
A lot of times, the programs are like 3X smaller and get finished long before
non-Haskell competitors.

~~~
snprbob86
Links?

~~~
tmorgan
<http://icfpcontest.org/>

although "functional programming" is in the name, any language can enter. lots
of Haskell and other FP winners in there. Although in '08 a Java team won..

------
shin_lao
Oh my. Someone complaining that he has to program in a language different than
his favorite language to make a living.

Most human beings have to work extremely hard to earn food for the day.

I'm genuinely shocked by such a "spoiled child" attitude.

~~~
daveungerer
Not sure why you were voted down, but I tried to get you back up. This guy
says: "I need money, only way of getting it is doing Java, C# or PHP".

So he's basically whining instead of doing something about it. Why hasn't he
started a profitable Haskell project? Or why doesn't he learn Ruby or Python,
which are at least far better than Java? "Spoiled child" is exactly correct.
If you really want to use a niche language, you can hope, but not expect that
the world will give you a job programming it. Create your own, _profitable_
opportunity. Otherwise, get used to being a starving artist.

~~~
jamesbritt
"So he's basically whining instead of doing something about it."

Why is asking for ideas "whining"? Is complaining about such a post also
whining?

If talking about it on mailing lists is _all_ that happens, then that's a
problem. But asking for some ideas to see what options are out there? He'd be
foolish not to.

------
revorad
The first reply is rather amusing: _Become the farmer. The life in village
brings advantage for health more._

------
allend
Never used Haskell, so if are Haskell-ian soul trapping sirens I am not aware
of, ignore this dumb post.

1\. There are languages out there you have not used.

2\. Get rid of biases and give second chances to the ones that you have.

3\. Maybe you are right. You'll never be able to get off Haskell. Stop
complaining, and go do something else. Math, art, biology, business, some of
that shit is pretty fucking interesting.

"Il faut aller voir"

~~~
ComputerGuru
Don't know why you're getting downvoted, but I agree. Life's a bitch, deal
with it.

------
jcromartie
I'd encourage idealist freelancers to try Clojure. It's very much idealist and
completely practical at the same time. And, yes, there are monads.

------
edwtjo
You don't, you just adapt to the rest of the world and use it given the
appropriate opportunity.

------
stcredzero
My answer: Don't. I think London might be a nice place!

<http://www.google.com/search?q=haskell+jobs>

Work for a startup!

------
strlen
This is a fairly interesting discussion. I'm not a Haskelite (if I had to pick
a favourite language it would be OCaml, with Common Lisp and plain-old-C being
close seconds), but I can understand where he's coming from. I'd imagine most
people on this site at in the same boat: we don't get to have full freedom to
choose our tools (in some cases even if we're running our own companies: there
are many interesting projects where our favourite tools are the _wrong_ tools
for the job). That doesn't mean we should lose passion for those tools, nor
does it mean that we can't find meaning and enjoyment in our work.

Oddly enough, I've found this sort of inspiration when I was reading
"Programming Pearls". The author managed to maintain an very upbeat and
enthusiastic tone, pointing out clever hacks, even when he talked about
programming in Cobol and BASIC. That helped me regain the sight of the fact
that as a professional programmer _and_ a (for lack of a better word) computer
nerd, I was lucky enough to be in a place where I could make a profession out
of my passion. Most people aren't that lucky. The fact that I don't always get
to choose my tools shouldn't let me get in the way of enjoying programming: I
love to program, when I drive in to the office, I'm going to be programming.

Ultimately, though, the advice I would give is:

* Look for interesting and non-trivial work, irrespective of what language is used (that criteria does generally disqualify some of the most frustrating and boring "niche" languages e.g., SAP, ASP, Coldfusion, PHP, Visual Basic).

A common pattern I've noticed when interesting languages are used for mundane
problems in start-ups is that as soon as the initial generation of developers
leaves (and the start-up becomes a modestly profitable midsize company: most
stay that way, rather than become "the next Google") management pressure grows
to switch to blub.

* Consider non-blub languages that on .NET and JVM: F# (being worked on by Peyton-Jones!), Scala (surprisingly many Haskell hackers are involved in it, despite Scala being far closer to OCaml), Clojure (borrows several ML family concepts in a _very_ interesting way -- that alone would actually make it interesting even if it didn't run on the JVM)

* Additionally, consider a full time job rather than projects and free lancing. If technology is a company's core competency, they're going to be very reluctant to outsource its development (typically exceptions are only made for exceptional individuals who are unwilling to sign on full time and even then it's often difficult to do).

Almost axiomatically, some of the most interesting software work is generally
done by companies where software is the core competency (the big exception
being things like computational finance and scientific/medical computing or
highly innovative enterprises such as Amazon [pre-AWS -- AWS made them a
genuine tech company] or PayPal). Thus, if you only choose to work on a
freelance/project basis you're likely locking yourself out of very interesting
jobs. Of course, this doesn't apply if you're in an area where most of the
full-time jobs are in the outsourcing industry (either in offshoring firms or
in off-shore offices of foreign firms).

* Use Haskell (or whatever else you like) as your secret weapon. Build prototypes in it and then once you have a clear mental picture implement them in another language. Write tools in it to automate away the drudgery (code analysis, debugging, verification: things Haskell is great at).

I should add that C and C++ shops tend to be slightly more open to this use of
Haskell, OCaml, Scheme and other uncommon languages: C/C++ are not very
scalable languages when it comes to "scaling down" to scripting and automation
work. Nonetheless I also know of people prototyping Java and Scala code in
Haskell as well.

* Don't forget that Haskell, Common Lisp etc... jobs are out there. They're just rare. They also typically look for individuals with specific skills rather than individuals skilled at specific languages e.g., you're more likely to find a Haskell job if you've written static analysis tools in Java than if you've written web apps in Haskell. ITA software very specifically stated that they don't require new hires to know Lisp, they want smart people whom they're willing to invest in and educate. "I really want to program in X language and you're one of the few places that uses it", unfortunately, won't persuade them if you can't pass their technical interview (unless they're specifically looking for an evangelist rather than a developer).

If you can manage to provide a more or less stable situation for yourself
which lets you develop new skills, you can always switch when tgw opportunity
comes. Technology job market is usually fluid. If you're not constantly
thinking "how will I get the next contract, what money will I live on" you
don't have to keep taking jobs you don't like (only to discover a posting for
a "perfect job" a week after you begin a new six month contract).

Finally, remember that there are people who hate Haskell, Lisp etc.. too _when
they are forced to use it_. There's no better example than university
students. I was unfortunate enough to be exempt (as a CS major in School of
Arts and Sciences vs. a CSE student in the School of Engineering) from taking
a specific undergrad course (the equiv of 6.001 or CS68a) that was taught in
Haskell. I couldn't enroll in the course, as the priority went to students
from whom it was required. I was green with envy, but most students absolutely
_hated_ it. I volunteered to help out my Berkeley friends with CS68a (their
SICP class), but they endlessly complained of not knowing what the point of
the course was (especially the non-CS students who had no prior or following
programming experience).

------
moron4hire
I don't understand the issue here. 1) You've identified the problem:
programming in Haskell isn't making you as much money as programming in Java.
2) You've identified a course of action: stop programming in Haskell and
program in Java. It's not like this is even a South Park dilemma, there is no
"Step 3: ???" before "Step 4: Profit".

~~~
eru
The dilemma is: Programming in Java isn't any fun for him.

~~~
moron4hire
That's why they have to pay us to get us to do it.

~~~
eru
I get paid for Ocaml (and perhaps Haskell, too, soon).

------
Tichy
I am kind of in the same situation, sans the Haskell part (haven't really
tried it yet).

One way I hope to at least endure Java is to do Android development - at least
then the results are cool.

Otherwise, I guess try proposing Clojure, or move on to Ruby. My problem with
that is that I haven't really warmed to Rails yet, but possibly Rails 3 might
fix that.

------
jaekwon
Does anyone have a meaningful productivity comparison between Ruby and
Haskell? Ruby is slow but I find it expressive enough. Unless you're doing
intensive data processing, I wonder how you would like Ruby.

~~~
steveklabnik
I've often thought about this, as my two favorite languages are Ruby and
Haskell. They are pretty much the farthest languages from each other in some
ways, yet pretty close in others.

It's like two totally different philosophies that arrive at very similar
conclusions.

------
10ren
The actual writing of code is the easy part of programming; it's the
conceptual solving of problems that is difficult. If you think in terms of any
particular language, you are limited by those terms.

Possibly, he's partly upset about the type of problems that he'd be solving in
those languages, rather than the languages themselves.

------
stonemetal
Sounds like one of those kids who will only eat cheese pizza. Just because X
is your favorite doesn't mean you can't run with something else for a while.
Enjoy the things you don't get in your language of choice.

------
gphil
The OP should just get a non-programming job to pay the bills, just like many
artists and musicians have to hold "day jobs" to support their passion.

------
jrockway
He answered his own question -- by scraping the bottom of the barrel for
projects that should have been outsourced to China for three cents an hour.

