Hacker News Reader

Comment by chihuahua | Hacker News Reader

I used to think that way until I ran into one of the pathological cases (Ruby) and now I'll think very carefully about which job offers to accept based on the language(s) involved.

View on HN

Me, before Ruby: “languages are languages, I can usually pick up what I need to in order to contribute.”

Me, after Ruby: “fools rush in where wise men fear to tread.”

exactly - last year I had to learn Go and Scala for a job, and it was a nice experience learning something new. 2 languages with advantages and disadvantages, and good support from VSCode and IntelliJ. This year, I had to learn Ruby, and found it to be a mess, with poor support from VSCode and RubyMine. Apparently you can't know what methods exist on a class until runtime, so the IDEs don't can't tell you much about your code.

Just like you shouldn't be so open-minded that your brain falls out, a language shouldn't be so dynamic that you can't tell anything about a line of code until you're in the middle of executing it. Maybe it's great for cranking out a CRUD web app in a weekend, but not so great for a product that's had 300 developers writing code for 10 years.

I've just inherited a Rails project that's been in development for the last 10 years. I know one of Ruby's mantras is something along the lines of "Optimized for Programmer Happiness," but after working with it for a couple of months, I have to ask "who is the programmer there?," certainly not the maintenance programmer. If code is read X times more than its written, then aiding comprehension is of the utmost importance. I'm not a huge fan of Go, but I do have to say that its readability greatly improves the developer-experience.

> Apparently you can't know what methods exist on a class until runtime, so the IDEs don't can't tell you much about your code.

If you didn't know that going in you did zero research about the job you took.

Reply on news.ycombinator.com