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.
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.
Couldn't he just use Haskell to write the Java/PHP/whatever code for him? Yeah, every project becomes a language translator, but then he wouldn't have to leave his beloved ivory tower of horrors.
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.
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.
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".
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.
> 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.
It's weird, and it's not quite the same situation as you're talking about, but I've found that working with overly limited languages and systems can be rewarding, too. Especially when they're so limited that you have to be creative just to find any solution.
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.
The problem is when your job is to get stuff out the door as quickly as possible. I just quit a job where I was writing primarily in a proprietary extension to a proprietary dialect of BASIC that has all manner of weird compiler quirks and just plain poor architecture. I knew there were ways I could do some better stuff long-term, but implementing them was completely outside the scope of the limited projects I was undertaking.
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.
CrapplyLang has programmers like the Cyberathlete Professional League has athletes.
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.
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.
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.
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.
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.
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.
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.
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.
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..
I disagree. My experience is that excellent programmers become fanbois because of their frustration working with sub-standard tools. So when they find the tools (by which I mean language) that allows them express their craft in the best way possible (for them), they latch onto it and become fanbois.
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.
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.
"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.
It's not just the language, it is everything that Java entails (speaking for myself, not the OP). It entails lots and lots of wasted time.
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).
You should consider yourself lucky for working on things you like.
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.
Where did I say that I get to work on stuff I like? I think you confuse me with somebody else.
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.
There are people with far worse jobs (if they have jobs at all), but the solution certainly isn't to shut up. A better solution is to spend a little of your time educating yourself and aiding others with their (and your) problems.
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.
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).
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".
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.
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.
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.
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.
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.
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.