From Rails to Clojure, Then to Java, Then Back to Rails
engineering-management.space
From Rails to Clojure, Then to Java, Then Back to Rails
1–10 of 157 posts
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#2In the "things learned from Ruby" section:
Focus on strong object oriented programming
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#3In the "things learned from Ruby" section: Focus on strong object oriented programming What I've learned from Ruby is to favor functional programming concepts - minimize side effects, isolate state mutation, etc. Ruby is definitely OO, but when my Ruby code is more functional it's less buggy, easier to understand and move around, and generally less convoluted.
Like Gary Bernhardt's notion of a "Functional Core, Imperative Shell" —
https://www.destroyallsoftware.com/screencasts/catalog/funct...
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#4[deleted]
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#5Another thing I’m getting is that the new kids won’t like rails, and it’s being harder to hire.
I'm surprised by this, to me the language used would be a long way down the list when evaluating an employer.
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#6Another thing I’m getting is that the new kids won’t like rails, and it’s being harder to hire. I'm surprised by this, to me the language used would be a long way down the list when evaluating an employer.
Surprising, for me it's one of the top criteria. The languages I'm using are shaping my process of thought, like when I'm speaking a different natural language, and some are more enjoyable than others to "think" in.
Besides, some languages give you vastly different career prospects (industries you can work in, salaries/rates, environment, etc.)
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#7Another thing I’m getting is that the new kids won’t like rails, and it’s being harder to hire. I'm surprised by this, to me the language used would be a long way down the list when evaluating an employer.
Judging by listings in the month jobs posting, the vast majority of hiring companies won't look at you if you don't have immediate and long experience with their current tech stack.
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#8Another thing I’m getting is that the new kids won’t like rails, and it’s being harder to hire. I'm surprised by this, to me the language used would be a long way down the list when evaluating an employer.
While I'd agree with you as an entry level candidate, with experienced people, I've found the language is often the most important thing on the list. Often above salary. I would say it is more commonly number one than any other factor. I only know of a few programmers who have shifted through more than 2 languages in their careers (20+ year type careers). I don't have brilliant insight as to why. Perhaps the fear of starting at ground zero? Imposter syndrome? Feeling of throwing your past experience down the drain?
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#9Another thing I’m getting is that the new kids won’t like rails, and it’s being harder to hire. I'm surprised by this, to me the language used would be a long way down the list when evaluating an employer.
Why is this surprising? For years employers have included proficiency with a specific brand of tool (language) as part of their job descriptions. And in the Bay Area anyway there is often a lot of talk about being able to use any language you're comfortable with in the interview process, but in practice unless you use the language(s) in the stack you're interviewing for it's a harder sell.
I self-select myself out of jobs that have specific languages in the job listing if I can't honestly say I've used them professionally.
Re: From Rails to Clojure, Then to Java, Then Back to Rails
#10In the "things learned from Ruby" section: Focus on strong object oriented programming What I've learned from Ruby is to favor functional programming concepts - minimize side effects, isolate state mutation, etc. Ruby is definitely OO, but when my Ruby code is more functional it's less buggy, easier to understand and move around, and generally less convoluted.
As someone stated, good OO and good functional is approaching the same goal from different sides. Your code being functional doesn't really make it less OO.