Illustrating the Dialectical Relationship Between Idiomatic and Generalist Approach to Programming Languages
idioms VS algorithms ?
The aim of this pageđź“ť is stress a dialectical relationship between 2 approaches to programming languages:
- idiomatic approach
- generalist approach
The approaches are taken by two usually agreeing masters: prof. Jay Sussman (SICP) and (Uncle) Bob Martin. I found the following bit stressing the tension between the to in the introduction of a solution of a leet code puzzle:
Different interviewers would probably expect different approaches for this problem. The holy war question is to use or not use built-in methods. As you may notice, most of design problems on Leetcode are voted down because of two main reasons: 1) There was no approach with built-in methods / data structures in the article OR/CONTRADICTORY 2) One of the approaches in the article did contain built-in methods / data structures. Seems like the community has no common opinion yet, and in practice that means an unpredictable interview experience for some sort of problems.
— Reverse Words in a String < LeetCode
1. IDIOMATIC APPROACH
- Stress is on peculiarity of the language, on understanding the area of needs that powered the language design, on understanding that a particular language is often applied in mostly in particular domains and that it has developed idioms that have to be learnt by practice and are essential to the competence of writing code
If you think about this, what you’ve learned so far is the rules of some language, some primitive, some means of combination, almost all of them, the means of abstraction, almost all of them. But what you haven’t learned is common patterns of usage. Now, most of the time, you learn idioms when learning a language, which is a common pattern that mean things that are useful to know in a flash. And if you build a great number of them, if you’re a FORTRAN programmer, of course, everybody knows how to — what do you do, for example, to get an integer which is the biggest integer in something. It’s a classic thing. Every FORTRAN programmer knows how to do that. And if you don’t know that, you’re in real hot water because it takes a long time to think it out. However, one of the things you can do in this language that we’re showing you is not only do you know something like that, but you give the knowledge of that a name. And so that’s what we’re going to be going after right now.
— Lecture 2A | MIT 6.001 Structure and Interpretation, 1986 — YouTube
- Prof. Sussman would take us to side with the idiomatic approach
2. GENERALIST APPROACH
- Uncle Bob in the recent interview would take us to side with the generalist approach
A CTO once wrote: “Does anyone know an Elixir programmer. Do you know any?” Bob: The best way to hire programmers is to ignore languages that they know. The languages are ephemeral. They come and go. It is not hard to learn a language. If you’ve got a project and it happens to be in Elixir you don’t need to go and hire an elixir programmer. You need to go and hire programmers. Good programmers can pick up any language. The time to take to pick up a language is very short compared to time to take it takes to master programming itself. It is mistake, in my opinion, to hunt for programmers that know Java. Find programmers who know how to write in any language and you’ll be much better off.
— Uncle Bob Martin // The Clean Coder | alphalist
