Hacker News Reader

I think this attitude results in people only ever reaching local maxima in their development environments.

Adopting something like Haskell instead of Ruby isn't just an exercise for magpies who like new shiny things (In fact, Haskell is older than Ruby, and many concepts in functional programming are far older than most OO design patterns). It's embracing a different way to think about programming which can have fundamental improvements to the maintainability of the code you write, rather than just cursory ones.

No one is saying that a business problem can't be solved, or money can't be made, using Ruby.

Sure, rewriting a project from one language to another is very expensive and usually not worth it, but does that mean that we shouldn't explore other tools at all? At some point, a new project will begin, and it'll be valuable to have a more robust decision about which tools to use than just "Rails worked ok for us last time."

I'm not saying you can't ever move on, just do it with dignity.

That is to say, picking products mature enough for production use, and executing your migration without feeling the need to justify it to the world by shitting all over your old environment.

Age has little to do with it. FWIW, Haskell is trendy right now. Probably for good reason. My issue isn't with the direction, it's the method.

When you switch to something different, you see that a bunch of your problems and annoyances simply went away. You may not see yet the new problems and annoyances that you acquired. You're in the honeymoon phase.

With time, you will see the problems with the new language/tool/environment. Is it better than what you had before? Maybe, maybe not. But you are not in a position to accurately evaluate it while you're in the honeymoon phase.

> Honestly, I think part of maturing into a senior software engineer (and later, a good manager) is accepting that while things aren't perfect, they're plenty good enough to solve your problems and make money.

I don't think this at all. I think part of maturing into a senior dev is having the experience to know what makes you happy, what makes you unhappy, and still make money.

For many the journey matters, and for the more passionate, "good enough" is a give-up mentality. And it's a good thing you don't have to keep these thoughts to yourself...you should feel free to share.

Happiness... Passion... these terms don't mean anything when it comes to maturity as a programmer.

Maturity as a programmer means being able to identify and do what it takes to get things done. Whether a developer is "happy", or "passionate" only begins to matter when they're doing what needs being done.

A true sign of maturity is when a programmer is faced with a workload that they are deeply unhappy about, but still get it done, because it needs to be done. The corresponding sign of mature leadership is acknowledging that developer's unhappiness and giving them extra money, work they enjoy, and/or time off after the crap work is done.

I guess we're just maturing in different ways. Your definition sounds like a big company doing less-rewarding work and middle management. For me, it was realizing you don't have to move towards management or dealing with lots of "crap work" (can't avoid it all of course). Also with maturity comes the realization that things that need to be done and being happy while doing it don't have to be mutually exclusive.

If you were tasked with maintaining a 10 year old codebase, your happiness really doesn't matter. If you don't find code maintenance enjoyable work, you're not going to enjoy the work. Sure, you might be able to make a game of it - to make it enjoyable - but that has no real bearing on your maturity as a programmer, just your personality.

That some programmers truly enjoy their work is a gift that they are lucky to have; not a sign of maturity.

> If you were tasked with maintaining a 10 year old codebase

Then I quit my job. As a quality senior you have the leverage to pick where and how you work. Otherwise, you may be thinking of just a tenured junior or someone who was given a title of "senior". This is why I said earlier "part of maturing into a senior dev is having the experience to know what makes you happy"...not just doing what someone tells you.

Heh. I actually enjoy maintaining old code, as long as that means I can improve it while adding new functionality.

If it means "no, we can't change that method with a 200+ cyclomatic complexity because the NY office wrote it and they would be upset about it" then yeah, that would suck. (Real story in a recent contract with a bank.)

> A true sign of maturity is when a programmer is faced with a workload that they are deeply unhappy about, but still get it done, because it needs to be done.

I’d like to pause the ruby discussion here to point out this is a deeply unhealthy viewpoint—it’s your own funeral if you knowingly go to a job that makes you “deeply unhappy” every day. That’s not maturity, that’s self harm. Maturity is responsibility, including to yourself.

Hence the directly following comment about mature management.

Leaving if management is not mature is a perfectly reasonable thing to do; but not doing the work you've been given before you leave is irresponsible at best, petulant at worst.

A personal anecdote: I've been pushed into QA for several, because we needed it to be done, and I had the prior experience. I hate doing QA work. After the crunch was done, I took a break, then went back to work I wanted to be doing. And yes, perhaps this denotes a lack of hubris, but I consider that to be mark of maturity as an employee in me, and in my manager.

For any given problem, I usually describe <my current favorite language> as being less crappy than every thing else that I've tried. Every language has disappointed me when I try to do thing those languages were never designed to do. Calling a spork a crappy spoon and/or fork ignores why one embraced the spork in the first place. Embrace the spork.

Fact is, they do spend a lot of time coding, but most of the code they write is either boilerplate, countermeasures to the language shortcomings, or tests to keep the language from biting you.

At some point (and if the codebase is not that good to begin with) one might conclude that the language is being hostile. A bit excessive maybe, but understandable.

This happens with every language, especially when maintaining 10 year old projects. Even a 10 year old project written by middle-of-the-bell-curve programmers in Haskell would be inducing the same amount of ire. "Who writes types this way?" "Did they even think about refactoring the existing types when bolting this other crap on?"

It's the maintenance that's driving this guy nuts, not the language itself. Haskel just happens to be his side project, which will, of course, look cleaner. I felt the exact same way when moving from Perl to Python.

Perl is also user hostile. So is haskell. Many languages are not, and people don’t typically build and maintain software in them for a reason—it’s expensive and slow compared to, say, java. What’s your point?

Some of the issues are totally language-related.

> It’s hard to reason about code when it does something entirely different depending on what code has executed in the runtime before it.

> What we really need are more explicit guarantees on every line of code that we write [...] than what Ruby can provide

Maintenance has a cost on any language, but in some cases you also have to make up for the lack of guarantees the platform gives you. Tooling, as you said, can help, but substantial effort is required to develop and mantain, say, a (production-grade) static type checker. You can't just tell $random_ruby_dev to "help improve tooling" if there is no tooling to begin with.

> If these programmers spent half as much time coding as they did bitching about their and others' programming environments, I think they'd get a lot more work done. Not to mention, be happier with life.

Without this "bitching about their and others' programming environments" we'd still be using punch cards. The author indeed does not contribute anything "new", but it's still pretty well written and to readers who are at a similar stage in their education/maturing in a more modern time it does a pretty great job of introducing concepts the typical ruby-only developer might not be familiar with.

I could have written a very similar article 15 years ago from a perspective of a black belt perl developer who found lisp to realize that his code already was lisp. Just in perl. Would it help a 25 year old other version of me today? No. Because he'd probably be proficient in ruby and not in perl. Nobody under 35 understands rants about lwp or Moose anymore and thus does not even have a chance of getting the point without lengthy research.

You can skip it if you acknowledge the tradeoffs, including the difficulties of hiring for a language people dislike, for better or worse.

Personally I would never work with other peoples rails again without seeing the code before hand. Rails outfits pay nowhere near enough to deal with method_missing and rails magic.