There is a lot to learn about culture, tools, frameworks etc.
There is a lot to learn about culture, tools, frameworks etc.
So Clojure, Java, Javascript, Haskell and Ruby are all basically the same?
I think damage can be done hammering different languages into the same methodologies..
> If a developer is skilled
You suggest skill is generic. If a programmer is smart they can learn new paradigms. Projecting the paradigms they are used to onto new domains can produce problems, least of all the standardisation.
Basically, yes. You learn to think how, the rest is implementation. Don't get me wrong, it's not an immediate switch, it takes learning and time, but deep inside, the are the same indeed.
It's just like grapes and grapefruit. Completely indistinguishable from one another.
Nice try, but we were talking about PHP and Java. Also, for instance, functional paradigm is the same for all functional languages, which is what I meant in the first place.
> You suggest skill is generic.
I'm suggesting the developer understands the OOP paradigm, knows about design patterns and isn't confused by the small differences in syntax or how much a language borrows from each paradigm. Two languages using the same paradigm are closer to each other, regardless of how different their syntaxes may be.
> Projecting the paradigms they are used to onto new domains can produce problems
That's completely true, but I'm not going to write generic comments that cover every case. I'm replying to someone comparing PHP to Java. It's my understanding the PHP is mostly OOP.
You started by saying "Software is software", you didn't mean this to imply all languages are similar?
> functional paradigm is the same for all functional languages
So Haskell and Clojure are similar?
> understands the OOP paradigm, knows about design patterns
Design patterns differ between languages. And OOP principles too. I don't want to see ConfigurationBuilderFactory classes in my Python code.
> I'm not going to write generic comments that cover every case
You only claimed "Two languages using the same paradigm are closer to each other" - but this seems tautologically true, depending on how you define "paradigm". Many OO languages differ in ways significant to the Java way of OOP.
Yes.
> Design patterns differ between languages. And OOP principles too
Not that much compared to paradigms. They're closer to coding styles. Once you understand what encapsulation is and how python lacks visibility modifiers, it's only a matter of using a coding style to compensate.
> "Two languages using the same paradigm are closer to each other" - but this seems tautologically true
Taken out of context, sure, but you excluded the second part. That's why I think Haskell and Closure are similar.
Using the incorrect nail for the job can lead to disaster or complications down the road. Think of using a nail that will rust over time being used on an exterior deck. Or a nail that is too long or thick for the pieces of lumber it is supposed to be securely (potentially splitting the boards).
If so, sounds like he's smart enough to pick it up.
A novice PHP developer will (or at least would have 5 years ago) create a messy script with interspersed HTML and PHP, a SQL injection vulnerability or two, and little code organization.
A novice Java developer will implement a bunch of patterns they don't understand (probably misusing them), and write a mess of code with too many side-effects.
An experienced developer can write good code in either language, and many of the patterns will end up looking similar.
Don't Haskell and Java differ significantly wrt Type systems? And the rigid class structures of Java might cause one to build very different programs that you might in a more dynamic language?
It takes a few weeks, month and perhaps 1-2 years for someone and i think it is fair enough to decide to hire an java guy for a java position over an php developer and to ask this in a job interview. It might be also okay to hire some php developer (or vice versa) but dismissing it, that there is a difference, is wrong.
Let's say you are looking for experience with Machine Learning, Distributed Systems, Databases, Kernel, Graphics, Embedded, etc. IMHO those things are harder to learn than a new programming language or framework (at least after having some experience).
That said, I think this article was more about requirements such as: "at least 3 years experience with X". Where X is just another language/framework/tool. It artificially limits the number of applicants and you might miss some pretty good devs, just because they don't try to apply since either they've only worked with X for one year yet or they've only used tool Y instead of X.
But the more collaborative your environment is, the more the trivia doesn't matter. I often work on pair-programming teams, and in that context I mainly care about deep skills.