How does one get off Haskell?
haskell.org
haskell.org
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.
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
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...
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".
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.
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.
One of my earliest programming experiences was for a very primitive language. You had something like 26 variables total, all globals, and no flow control except GOTO. I ended up reinventing quite a lot of things to get even trivial programs working. I remember teaching myself loops, bitmasks and more, before I even knew what those things were.
Or that time I remember having to use VBScript. Someone had made an OCX marked 'safe for scripting' that would write out some assembly and execute it, allowing one to call any C functions that left the stack clean (e.g. Windows APIs). I remember finding some crazy ways to abuse that. I also remember turning a testing tool into a music player when I was bored.
That said, I understand not wanting to program like that 40-hours a week. I know it can be grating after a while. But sometimes, you can have a bit of fun by finding clever ways to expand the capabilities of very limited systems.
#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.
The big, awesome system I wrote . . . I left instructions for no one to modify it under any circumstances. Ever. My boss asked, "Isn't there someone else in BigCorp that can maintain this code?" No, there was no one, I could say with great authority. I was BigCorp's uncontested expert on CrapplyLang; its other experts were all my students or colleagues. One had a fascination with subroutines such that every subroutine was two lines long, called another subroutine, and manipulated global variables. Another . . . well, let's just say she called me up three years later having lost a closing curly brace. Because she didn't realize she had to put one in.
In the mean time, those perl lines expanded into terse nasty? Tended to be things like binary trees implemented entirely with strings (XML? Yeah, something like that.) or regular expressions unrolled into finite state machines. I would have had a hard time making heads or tails of it without the perl comments.
The way I put it to my boss, you need to find someone smart enough to figure out how to get things done in CrapplyLang, and dumb enough to do it. I was the only person I was aware of in all of existence who qualified.
Otherwise it just comes off as a roundabout way to talk about how awesome Haskell is.
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.
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.
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.
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.
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.
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..
All of the great programmer's I know (small sample I guess) have a favourite language, and generally dislike working in other languages, even though they can.
Most human beings have to work extremely hard to earn food for the day.
I'm genuinely shocked by such a "spoiled child" attitude.
The wasted time is what gets to me. I have met lots of people who don't mind, as long as the pay is OK. I am not one of them (or maybe they never paid enough).
Although I have actually heard stories about coal miners who are happy, so maybe it is just my cultural bias talking.
You love programming and work as a programmer, isn't that great? Oh sorry, it's not the language you like and you cannot use your favorite editor and you actually have to come to the office and make the customer happy.
Seriously.
And actually, I recently realized that maybe I am not really a programmer. I like to build stuff, but I don't like programming just for programming's sake. So I guess that makes me 'not a programmer'.
I do like some programming for programming's sake, for example puzzles from coding competitions. But it's not as if you just have to put some lines of code in front of me to edit, and I am happy.
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.
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.
Someone on a Haskell mailing list is asking other Haskell programmers if there is a way they know of that he can do what makes him happy.
Yes, happiness is not at the same place on the hierarchy of needs as 'food', but that hardly means you shouldn't strive for it.
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"
http://www.google.com/search?q=haskell+jobs
Work for a startup!
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).
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.
It's like two totally different philosophies that arrive at very similar conclusions.
Possibly, he's partly upset about the type of problems that he'd be solving in those languages, rather than the languages themselves.