Yes, theoretically, there's an abstract idea of what to do, and a programming language is a "mere" concrete expression of that idea.
In practice, however, there can be a world's difference between these concrete expressions.
Do a concurrent program in Python and in Go. Solve a particular problem in an imperative language vs. a functional one. Consider the consequences of static vs. dynamic typing. And so on.
At the minimum, this ignores that there are idiomatic ways to solve problems in a particular language.
I think this koan was more at the point at the time it was written (I'm assuming it was the ~80s), but there's been explosion of new concepts and new languages to fit them since, and I don't think it applies any longer.
In practice, the vast majority of the job market is encompassed by JavaScript, TypeScript, Python, C# and Java. A lot of that Python still adheres to imperative and OOP ideology too, despite being able to ditch it entirely. Most people also aren't doing things which differ immensely from other languages.
The old "well Haskell ain't C++ ain't Java" doesn't go for the majority of real life cases. The majority of real life cases are recruiters tilting their head when a C# developer claims to be able to work in a Java shop writing basic CRUD code. Most of the grey zone between "basic CRUD" and "bleeding edge" also isn't too difficult to learn on the job.
Additionally, most languages are slowly implementing things from other paradigms. The only things preventing these features from being fully adopted are, in a twist of irony, the same jobs clinging onto the old ways.
I don't agree, it applies now more than ever. Good developers have strong fundamentals, not being able to switch between static and dynamic languages taking advantage of the differences, or between imperative and functional paradigms is the mark of a very weak developer.
There's been an explosion of languages, but not really an explosion of concepts.
I think where we differ is in our assumption about the strength of the fundamentals. You're assuming a good developer already has full breadth, whereas I'm assuming that you can be a good developer and still encounter challenging novelties.
Take my Python vs. Go concurrency example. That's just one fundamental concept, but with two very different solutions.
One could even argue that just the Python version alone can have significantly differing solutions, the choice of which is determined by the runtime (CPython or another implementation without a GIL).
Then, of course, there's the idiomatic way of doing things that cannot just be carried over from knowledge with other languages.
The point that the koan makes is not that they are different, but both have their own corner cases that you need to learn and its not that hard to learn them.
It may not be hard, but it can be time-consuming. Knowing how long someone has written Python is useful information for how to onboard them, and how to interview them.
Dan Grossman (in Programming Languages Part A on Coursera) suggests there are 5 broad areas of knowledge about a programming language:
- syntax
- semantics
- idioms
- tools
- packages
The koan glosses over the time it takes to become familiar with the bigger language ecosystems (tools and packages), which is awkward when a business gets value from packages like web frameworks.
Having said that, recruitment can seem 100% about tools and packages.
I’m not sure how consciously hirers think about the different areas of knowledge. E.g. might a deep knowledge of Python semantics offset inexperience with Flask? Does ignorance of idioms necessarily indicate poor semantic understanding?
In hindsight, I’ve had hiring discussions that touched on these questions but without a clear framework for considering the trade offs. Guessing it’s the same for many people hiring at smaller companies.
Although I agree to the gist of it in terms of ‘Programming’; I may not agree in terms of ‘Programming Languages’.
IMHO, mastering a programming language to write clear, concise & idiomatic code takes time (sometimes more, sometimes less). I think of programming languages as tools; none is better than the other. It’s a matter of using the right tool for the right job.
Learning a tool takes time and dedication; often having experience with one tool may shorten the time required to learn another.
The more expertise I've gained with my preferred language, the more I value that expertise in others. If my teammates are new to the language, they'll be frustrated when I use its idioms and take advantage of its idiosyncrasies. In turn, I'll be frustrated when they contort it and write inefficient code, due to ignorance of the compiler, interpreter, and available libraries.
I understand the criticism alongside _if you know one, two programming languages, then you know it all_. However, what seems to be overlooked at times is that there are different categories of programming languages, where your experience and knowledge in imperative languages doesn't help that much.
Looking at Prolog for instance, where you need to understand a whole new concept on how to achieve something requires time and experience.
Do companies even take this requirement seriously?
I see "X years of experience in language Y" all the time in job listings, but I have _never_ been asked about it during an interview. My resume only lists a vague descriptor of language experience (Novice/Comfortable/Expert), so they aren't getting it from there.
Has anyone here on HN ever been in a situation where a company requested (for example) 7 years of $language and you only had 6 years and got rejected because of that?
The "years of experience with a language" is a question for non-technical recruiters. They need some sort of proxy for skill, and length of time is the best one they have. I don't think any actual technical engineers would use this metric when deciding who to hire. It is solely to appease the resume gatekeepers.
I have seen HR sheets were every single CV entry gets some kind of points and experience level, pages of it.
Usually used by recruiters as gatekeeping before the CV lands on the desk of someone technical, most of the CVs that don't uphold the desired metrics don't make it.
What is a problem is the unwillingness to admit a proxy is downright bad, and the reluctance to investigate the efficiency of a proxy.
Most of recruiting is individuals stubbornly ignoring research and insisting they know better despite doing nothing that could pinpoint the reason for their success. Not always the recruiters either.
... but you don't know in which framework the floor was designed, and I need you to hit the ground running to do work on this floor using this framework.
... which although less than five years old, I require ten years experience in.
Yes, theoretically, there's an abstract idea of what to do, and a programming language is a "mere" concrete expression of that idea.
In practice, however, there can be a world's difference between these concrete expressions.
Do a concurrent program in Python and in Go. Solve a particular problem in an imperative language vs. a functional one. Consider the consequences of static vs. dynamic typing. And so on.
At the minimum, this ignores that there are idiomatic ways to solve problems in a particular language.
I think this koan was more at the point at the time it was written (I'm assuming it was the ~80s), but there's been explosion of new concepts and new languages to fit them since, and I don't think it applies any longer.