Polyglot programming and the benefits of mastering several languages(stxnext.com)
stxnext.com
Polyglot programming and the benefits of mastering several languages
https://www.stxnext.com/blog/polyglot-programming/
67 comments
I think that's just the nature of the ... problem domain.
There are too many little details that are too similar and our brains have gotten used to Googling. Early on I started creating text files for all these little details for all the languages I know. And now a quick search for these details is an extension of how my brain works. In other words I realized I needed to deposit these chunks of information where I know I'll need to reference them in the future. Is it "else if", "elif", "elsif" in Python, Perl, Ruby - grep or quick search my ruby.txt, ocaml.txt, etc. file. And since I live in emacs, this takes just a few characters to accomplish.
Kinda similar to https://learnxinyminutes.com/
Kinda similar to https://learnxinyminutes.com/
Nice. I should assemble some shell scripts or python to do this now.
I've mastered about a dozen and can read another dozen or so.
I have the same problem you're describing, but it tends to be with languages I haven't used in a while.
I've also resigned myself to be ok with googling a lot of things:
"list comprehension python"
"typescript generic constraint"
"golang package visibility"
Once I got ok with this approach, I became a much happier and productive developer. Rather than beating myself up that I couldn't remember the details, I just "outsourced" said details to Google/StackOverflow and focused on the big picture.
As long as I grok the semantics, I haven't missed remembering all the syntax and idioms of each and every language.
I have the same problem you're describing, but it tends to be with languages I haven't used in a while.
I've also resigned myself to be ok with googling a lot of things:
"list comprehension python"
"typescript generic constraint"
"golang package visibility"
Once I got ok with this approach, I became a much happier and productive developer. Rather than beating myself up that I couldn't remember the details, I just "outsourced" said details to Google/StackOverflow and focused on the big picture.
As long as I grok the semantics, I haven't missed remembering all the syntax and idioms of each and every language.
This is how I feel too. And not just with programming languages, but with cloud platforms like AWS and GCP. I've spent the last 3 years working just with GCP, but I have prior AWS experience and recently started working in an AWS heavy role. I don't remember anything. I know what I want to do, and what the things AWS provide do, but I can't remember how, so I'm asking questions and looking things up online because I don't know and I feel like an idiot.
This.
I'm somewhat envious of my friends who stuck with one language like C, and are super proficient with the one or two languages that they know.
I'm somewhat envious of my friends who stuck with one language like C, and are super proficient with the one or two languages that they know.
I ran between languages for a few years and have stuck with TypeScript for the last few months after deciding I wanted to be one of those people. Already so much more productive when I don’t have to Google everything I do.
[deleted]
I've dealt with 5 different databases this week. Is it SHOW CREATE TABLE blah, DESC TABLE blah, DESC blah, sp_help blah, \d blah? Is this the database that supports CROSS JOIN? What exactly can I do with aggregate functions and a GROUP BY in this database again?
Ugh, this a thousand times! It's all SQL but all these little side things like describing a table or listing all tables are completely different across the board.
Hypothesis: this is your brain doing normal garbage-collection on pieces of information that you haven't accessed frecently (frequently + recently) - you're at the tail end of the forgetting curve[1].
Does your experience confirm or deny this? That is, do you have much more trouble with languages you learned 5/10/25 years ago than ones you were using last month? Or is the process random, and you'll forget features of a language that you were just using?
Alternate hypothesis: you're getting old, and your memory is starting to go - nothing to do with programming languages in particular, the process is just more noticeable there because we have to remember so darn many little things.
Less depressing hypothesis: your brain has gotten out of the habit of remembering those things. I used to be extremely bad at remembering names, until I started paying attention to them because I learned that people really like it when you remember your name. Now I'm great with names without even trying, and I'm convinced that you can also train yourself to be better at remembering other things (i.e. programming stuff) than your natural tendencies.
[1] https://en.wikipedia.org/wiki/Forgetting_curve
Does your experience confirm or deny this? That is, do you have much more trouble with languages you learned 5/10/25 years ago than ones you were using last month? Or is the process random, and you'll forget features of a language that you were just using?
Alternate hypothesis: you're getting old, and your memory is starting to go - nothing to do with programming languages in particular, the process is just more noticeable there because we have to remember so darn many little things.
Less depressing hypothesis: your brain has gotten out of the habit of remembering those things. I used to be extremely bad at remembering names, until I started paying attention to them because I learned that people really like it when you remember your name. Now I'm great with names without even trying, and I'm convinced that you can also train yourself to be better at remembering other things (i.e. programming stuff) than your natural tendencies.
[1] https://en.wikipedia.org/wiki/Forgetting_curve
Also tricky because many things "work" but aren't stylistically acceptable.
Like, python oo is perfectly happy with "this" instead of "self".
Like, python oo is perfectly happy with "this" instead of "self".
I agree with the spirit of your point, but I'd be hesitant to say you're "mastering" your 15th language if they are all jumbled together. It sounds like you've learned 15 languages, but mastery implies an extreme depth of understanding beyond the point of confusing minor details. I would bet you have at least one or two languages that you work in often that you never get this stuff confused for, and those are the ones you've mastered. The additional languages are subject to a sort of Jack-of-all-trades syndrome.
You'd think so, but that's not the case. I've mastered go so deeply that I even wrote [1] to subvert the runtime. But even with go I have to look things up after working in Kotlin for a week.
[1] https://github.com/kstenerud/go-subvert
[1] https://github.com/kstenerud/go-subvert
[deleted]
Some people here learned, mastered and thoroughly forgot more languages and technologies than other people have started with yet.
> thoroughly forgot
I am stealing this phrase
I am stealing this phrase
I don't agree that you look like you don't know a damn thing. You know quite a lot.
In fact, I would happily hire any programmer for, say, a python or a C++ job, that knows nothing about the language in use but knows to ask precisely these questions. Bonus points for questions about function semantics and memory management.
Everything else boils down to syntax and ecosystem/tooling. The former is essentially irrelevant and the latter changes so often and is used differently in different contexts that there is little point in asking about prior experience.
In fact, I would happily hire any programmer for, say, a python or a C++ job, that knows nothing about the language in use but knows to ask precisely these questions. Bonus points for questions about function semantics and memory management.
Everything else boils down to syntax and ecosystem/tooling. The former is essentially irrelevant and the latter changes so often and is used differently in different contexts that there is little point in asking about prior experience.
It's nice, when doing actual work on a language you have zero experience with, to have a clear intuition about what to expect and what to search for and to feel confident that you'll be able to get things done based on having done it with so many other languages before.
If it's not too unusual, it feels similar to other tools you've picked up before. If it isn't it's interesting.
Something like:
"Oh, OK, Swift has a switch right? Yeah. Does it require me to explicitly break? Yeah. Can I give ranges or patterns?
That's cool, they use named parameters in Smalltalk style, probably comes from Objective C, right?
Nil! charming, like Golang or Pascal.
What do you call these ?. and !. 's? Reminds me a bit of ?. in JavaScript. It's nifty: you can enforce a value not being nil or specify a default..
Hmm, these guards are interesting, how do they work... Etc "
So obviously you need to get someone to check for footguns in your code, but after enough playing with toys you tend to get to a place you can write solid code in a new language very quickly, and where getting to a solid level of competence is relatively quick.
If it's not too unusual, it feels similar to other tools you've picked up before. If it isn't it's interesting.
Something like:
"Oh, OK, Swift has a switch right? Yeah. Does it require me to explicitly break? Yeah. Can I give ranges or patterns?
That's cool, they use named parameters in Smalltalk style, probably comes from Objective C, right?
Nil! charming, like Golang or Pascal.
What do you call these ?. and !. 's? Reminds me a bit of ?. in JavaScript. It's nifty: you can enforce a value not being nil or specify a default..
Hmm, these guards are interesting, how do they work... Etc "
So obviously you need to get someone to check for footguns in your code, but after enough playing with toys you tend to get to a place you can write solid code in a new language very quickly, and where getting to a solid level of competence is relatively quick.
That's because they are mostly the same language. Brain can't be fooled by manifestos.
For what is worth, it's the same problem with normal language. I know Italian and English, "great, I can talk to two kinds of people", except that my Italian is fully distorted by my English now (I talk both languages constantly, but I do live in an English speaking country now).
Anyway knowing many languages has some downsides, but in the end if you write the same one for a couple of months the problem of searching disappear. When you switch another couple of months and it's gone again.
Anyway knowing many languages has some downsides, but in the end if you write the same one for a couple of months the problem of searching disappear. When you switch another couple of months and it's gone again.
My brain is in the exact same state, which is frustrating when doing live coding interviews, as suddenly it's impossible to not come off looking like a complete beginner. Throw it some nervous jitters on top and it gets ugly fast.
Anyone watching me work would probably think I don't know a damn thing. And after 25 years in the industry, I sometimes wonder the same thing.
I suspect the people watching who thought you didn't know a thing would probably be the ones too inexperienced to recognise what you describe.
I also suspect that every other programmer with 25 years of experience who can be productive using many different programming languages would immediately recognise and empathise with the feeling you describe, and they also have a search window permanently open while working.
I suspect the people watching who thought you didn't know a thing would probably be the ones too inexperienced to recognise what you describe.
I also suspect that every other programmer with 25 years of experience who can be productive using many different programming languages would immediately recognise and empathise with the feeling you describe, and they also have a search window permanently open while working.
I would probably print a cheat-sheet for each language, with simple examples covering the cases you mentioned here. Looking at a piece of paper next to monitor is faster than googling.
> Anyone watching me work would probably think I don't know a damn thing.
I guess looking at the cheat-sheet would only confirm their suspicions. :D
> Anyone watching me work would probably think I don't know a damn thing.
I guess looking at the cheat-sheet would only confirm their suspicions. :D
I know people hate language wars and always reply with “Use the best language for the job.” but wouldn’t it be great if there was a language that could do it all optimally (or at least adequately).
Then we can focus on just one language to master and don’t have to keep in our heads a jumble of languages.
Then we can focus on just one language to master and don’t have to keep in our heads a jumble of languages.
Basically any modern, turing-complete, and non-esoteric (eg. Brainfuck) language fulfills the "at least adequately" part. So it comes down largely to preference and style of the language itself. I can't stand C# code or that the language uses Allman style over K&R because I truly find Allman style more difficult to read. I shouldn't - the difference is very minor - and although I work with a C# codebase in my day-to-day work I always struggle parsing the code quickly compared to languages where K&R style won out.
Now "optimally" is an entire can of worms because there are some aspects where you need to make mutually exclusive choices. You can optimize A or B but not A and B for multiple sets of A and B. So you'll end up with multiple languages or multiple flavors of a single language where decisions were made to optimize for varying sets of A and B. A and B can even be simple things like "How easy is it to footgun yourself?". Should you make code that is more boilerplate/difficult to write in order to prevent people from footgunning themselves or do you expect your developers to be more experienced and allow them to write more succinct code but having to be aware of and avoid potential footguns themselves? There are a lot of domain-specific languages for precisely the kinds of trade-offs are made that certain fields want/need. For example, mathematics domain languages tend to be 1-indexed instead of 0-indexed.
By the way that language is LISP.
[0] Just in case anyone is unfamiliar with Allman/K&R styles mentioned you can see examples on Wikipedia: https://en.wikipedia.org/wiki/Indentation_style
Now "optimally" is an entire can of worms because there are some aspects where you need to make mutually exclusive choices. You can optimize A or B but not A and B for multiple sets of A and B. So you'll end up with multiple languages or multiple flavors of a single language where decisions were made to optimize for varying sets of A and B. A and B can even be simple things like "How easy is it to footgun yourself?". Should you make code that is more boilerplate/difficult to write in order to prevent people from footgunning themselves or do you expect your developers to be more experienced and allow them to write more succinct code but having to be aware of and avoid potential footguns themselves? There are a lot of domain-specific languages for precisely the kinds of trade-offs are made that certain fields want/need. For example, mathematics domain languages tend to be 1-indexed instead of 0-indexed.
By the way that language is LISP.
[0] Just in case anyone is unfamiliar with Allman/K&R styles mentioned you can see examples on Wikipedia: https://en.wikipedia.org/wiki/Indentation_style
We already have that language but people keeping getting whiny about parentheses, and refuse to use it.
If you don‘t remember those things, you haven‘t mastered the language.
Mastering a language means not having to look up language features all 5 minutes.
-> you haven‘t mastered 15 languages.
Mastering a language means not having to look up language features all 5 minutes.
-> you haven‘t mastered 15 languages.
For me it’s trying to remember the ‘for each’ syntax in every language. I normally bounce between 4 or 5 languages every day.
I kind of think this makes programming all about the IDE.
“Mastering” is a tricky term to use here.
It could imply simply gaining a level of competency/proficiency that means you basically can use the language to accomplish things without feeling owned by the language. I think this is the kind the author is getting at.
But mastering can also mean rising to a guru level of proficiency where you can do things with the language that the majority of your peers cannot.
I find this second difficult to achieve in a polyglot sense. I used to be able to do guru level things with Smalltalk. For the last 10 years I’ve done no Smalltalk and embraced the way of the polyglot, becoming moderately proficient in Python, Kotlin, Swift, Linux cli, Elixir, C, but in no ways do I have the bandwidth to chase “guru level” with any of these. That kind of mastery usually comes from focus and experience, something that’s difficult (impossible?) to achieve when your task switching cognitively. Even with Smalltalk, I would have to swim in the waters a while before I felt I was in a master position again.
This kind of mastery also makes you a better programmer. “To boldly take this language to solutions no one has tried before” will definitely hone skills.
At the end of the day, it really boils down to “keep pushing yourself to learn new and varied things” and you’ll grow. If you decide to cache in and just leverage your acquired wisdom, you’ll stagnate.
It could imply simply gaining a level of competency/proficiency that means you basically can use the language to accomplish things without feeling owned by the language. I think this is the kind the author is getting at.
But mastering can also mean rising to a guru level of proficiency where you can do things with the language that the majority of your peers cannot.
I find this second difficult to achieve in a polyglot sense. I used to be able to do guru level things with Smalltalk. For the last 10 years I’ve done no Smalltalk and embraced the way of the polyglot, becoming moderately proficient in Python, Kotlin, Swift, Linux cli, Elixir, C, but in no ways do I have the bandwidth to chase “guru level” with any of these. That kind of mastery usually comes from focus and experience, something that’s difficult (impossible?) to achieve when your task switching cognitively. Even with Smalltalk, I would have to swim in the waters a while before I felt I was in a master position again.
This kind of mastery also makes you a better programmer. “To boldly take this language to solutions no one has tried before” will definitely hone skills.
At the end of the day, it really boils down to “keep pushing yourself to learn new and varied things” and you’ll grow. If you decide to cache in and just leverage your acquired wisdom, you’ll stagnate.
I like splitting it into competency and expertise. In my own personal experience, you can be competent with as many languages as you want, but most people can only hold expertise in a few at a time. Generally, your expertise is going to be the ones you actually use daily, because use is the only way to deepen your understanding.
I, for example, and primarily a Java and Python developer during the day, so those are my expertise. Those are the ones I feel confident telling someone to come to me with any questions on, the ones that I know the internals of, the ones I can confidently solve most problems in without having to look much up.
As a web developer in my younger days, I considered myself an expert in PHP and Javascript, but I know that I no longer hold that status with them. I could immediately understand if I were to read anything with them, but to start something from scratch I would need some lead-in time, so I'm only going to call myself competent.
I use Ruby periodically today, but not on important enough things that I need to understand it deeply, so again I would only call myself competent. I'll sure put all of those on my resume though, along with other competencies and former expertise.
I, for example, and primarily a Java and Python developer during the day, so those are my expertise. Those are the ones I feel confident telling someone to come to me with any questions on, the ones that I know the internals of, the ones I can confidently solve most problems in without having to look much up.
As a web developer in my younger days, I considered myself an expert in PHP and Javascript, but I know that I no longer hold that status with them. I could immediately understand if I were to read anything with them, but to start something from scratch I would need some lead-in time, so I'm only going to call myself competent.
I use Ruby periodically today, but not on important enough things that I need to understand it deeply, so again I would only call myself competent. I'll sure put all of those on my resume though, along with other competencies and former expertise.
> … a tricky term to use here
Strange to me that no one has mentioned fluency (as programming languages are languages).
Strange to me that no one has mentioned fluency (as programming languages are languages).
I am disenchanted with "guru level" work in a language. The old saying about "if I'm just barely smart enough to write the code, I'm not smart enough to debug it" is true immediately, and then even more true if there's a 3-6 month delay.
I appreciate being back in a language long enough to not have to look things up all the time, but the dialect of all of them I write in gets simpler and simpler over time.
Portable guru knowledge like "I know how to write an interpreter/compiler" and "I know that for this task there must be a library in $LANGUAGE" and "I know that language construct/function call looks simple but it has to be an O(n^2) algorithm for it to be doing what it says its doing" is much more useful.
I appreciate being back in a language long enough to not have to look things up all the time, but the dialect of all of them I write in gets simpler and simpler over time.
Portable guru knowledge like "I know how to write an interpreter/compiler" and "I know that for this task there must be a library in $LANGUAGE" and "I know that language construct/function call looks simple but it has to be an O(n^2) algorithm for it to be doing what it says its doing" is much more useful.
Yes, I feel like aiming for a T or Pi shape is a good analogy: Try to truly master the 1 or 2 languages you work with most of the time. Have a good enough knowledge of other languages in order to learn and grow or to use them for specific needs.
Edit: typo.
Edit: typo.
I'd say it's not just learning multiple languages that is valuable, but learning languages with different paradigms. If you learn 5 different object-oriented languages, you'll mostly get exposed to different OOP concepts. If you learn an OOP language, a Procedural language, a Functional language, a declarative Logic language (Prolog, SQL, etc), and maybe something else you'll have a much broader set of ways to think about solving problems.
A few years ago I did a MOOC called 'programming languages' which teaches languages like racket and ML.
In one of the intro lectures, the professor remarked that (paraphraaing here) 'now I am not naive--I know you will probably end up programming in Java or python when you reach the professional world, but the purpose of this course is not that you will actually go out and use racket in your life as a business programmer, but instead that your knowledge of racket will change the way you program in Java or Python'.
So there's really two types of learning--learning a language to use it, and learning a language as a sort of intellectual feast to bring back to your own.
This also has paralells in (human) language. The only languages I've studied are French and Hebrew. French has 'que' which can combine two noun phrases in a way that doesn't quite exist in English, and Hebrew has construct state.
[1] https://www.coursera.org/learn/programming-languages Sorry if I make a mistake here, Im not really very knowledgeable about either language, but I hope the general point stands.
In one of the intro lectures, the professor remarked that (paraphraaing here) 'now I am not naive--I know you will probably end up programming in Java or python when you reach the professional world, but the purpose of this course is not that you will actually go out and use racket in your life as a business programmer, but instead that your knowledge of racket will change the way you program in Java or Python'.
So there's really two types of learning--learning a language to use it, and learning a language as a sort of intellectual feast to bring back to your own.
This also has paralells in (human) language. The only languages I've studied are French and Hebrew. French has 'que' which can combine two noun phrases in a way that doesn't quite exist in English, and Hebrew has construct state.
[1] https://www.coursera.org/learn/programming-languages Sorry if I make a mistake here, Im not really very knowledgeable about either language, but I hope the general point stands.
That was a great MOOC by Dan Grossman - discussed a number of times here on HN.
The famous quote from Alan J Perlis:
"A language that doesn't affect the way you think about programming, is not worth knowing."
http://www.cs.yale.edu/homes/perlis-alan/quotes.html
The famous quote from Alan J Perlis:
"A language that doesn't affect the way you think about programming, is not worth knowing."
http://www.cs.yale.edu/homes/perlis-alan/quotes.html
> The younger generation is also familiar with the “memento Ruby” argument. “The decision to learn a new language is about career planning and risk diversification. Just look at Ruby,” Michał says.
It's funny, while community interest in Ruby peaked around 2012, industry adoption and usage of Ruby at startups and in enterprise is higher right now than it ever was, so this whole "remember Ruby" trope is such a farce.
It's funny, while community interest in Ruby peaked around 2012, industry adoption and usage of Ruby at startups and in enterprise is higher right now than it ever was, so this whole "remember Ruby" trope is such a farce.
Ruby is in the post-hype phase.
Right, but my point is adoption and hype don't always go hand-in-hand. JavaScript for example has always had heavy adoption but now is going through a hype phase. Ruby had a hype phase a decade ago but only now is seeing heavy adoption. Similarly PHP hype peaked in the early 00s, but adoption didn't peak until ~2017 and is now beginning to decline. Rust is seeing heavy hype that will probably be followed in 5-10 years with heavy adoption.
I'm not sure that there are as many problems to solve for languages like Rust and Go as there are for languages like PHP and JS, Ruby or Python. Basically desktop/system vs web apps. Of course we can write web apps with Rust and Go and we do but why bother? There is evidence that the world is using PHP to write web apps, not the new (and better) languages of the last few years. It's so much easier.
Java is somewhat in the middle: a compiled language heavily used for web apps. There was little else to use in the 90s, except Perl, so big Java shops got established, banks started using it and it will live at least as long as COBOL. But do I want to write web apps with Java? No thank you, I jumped ship to Ruby 15 years ago, then added Python and Node.
Java is somewhat in the middle: a compiled language heavily used for web apps. There was little else to use in the 90s, except Perl, so big Java shops got established, banks started using it and it will live at least as long as COBOL. But do I want to write web apps with Java? No thank you, I jumped ship to Ruby 15 years ago, then added Python and Node.
Anecdata, but PHP is still growing outside the valley. It has the shortest effort to MVP measure of all languages. So if you only have money for one part time engineer, you go with PHP.
From time to time I've been good enough to think I'm a master of a language. But that skill fades so fast. For some reason the mountains of trivia just sort of fade away without pretty regular use.
Once upon a time, I could tell you all the semantics of `static` in C, but now I couldn't even give an accurate count of all the ways it's overloaded. There's like the top level declaration that sets aside memory, there's the declaration in a function that has slightly different initialization rules and is good for coroutines. And like, 4? more meanings in different locations. I only hit that level because of a compilers class.
I feel like I could ramp back up, but the subtle nuances just sort of flit away like butterflies.
More than 2 seems really challenging. Even simple stuff there's not much to scheme, but try getting a chez runtime running on a raspberry pi, and really understand the impact of the flags you build with and run with. Not easy (for me) to stay really sharp with that.
I mean, sure, I can bang out some code. I can pattern match well enough that code I contribute blends in with the style of a project. But mastery? That's a big lift.
Once upon a time, I could tell you all the semantics of `static` in C, but now I couldn't even give an accurate count of all the ways it's overloaded. There's like the top level declaration that sets aside memory, there's the declaration in a function that has slightly different initialization rules and is good for coroutines. And like, 4? more meanings in different locations. I only hit that level because of a compilers class.
I feel like I could ramp back up, but the subtle nuances just sort of flit away like butterflies.
More than 2 seems really challenging. Even simple stuff there's not much to scheme, but try getting a chez runtime running on a raspberry pi, and really understand the impact of the flags you build with and run with. Not easy (for me) to stay really sharp with that.
I mean, sure, I can bang out some code. I can pattern match well enough that code I contribute blends in with the style of a project. But mastery? That's a big lift.
You can't actually be a Master of only 1 language.
This applies to human and computational languages. Consider that English derives from French, German, Latin, Greek, etc. Without knowledge of the root languages, you can't actually master English.
And beyond polyglot is "polyparadigm". Knowing 7 languages in the same paradigm makes you an expert in a particular style of programming. But True Mastery means transcending style.
With that said, most are better served by gaining proficiency communicating with (managing) people than mastering programming.
This applies to human and computational languages. Consider that English derives from French, German, Latin, Greek, etc. Without knowledge of the root languages, you can't actually master English.
And beyond polyglot is "polyparadigm". Knowing 7 languages in the same paradigm makes you an expert in a particular style of programming. But True Mastery means transcending style.
With that said, most are better served by gaining proficiency communicating with (managing) people than mastering programming.
I think only very few people can be really proficient in more than 3-5 programming languages (at the same point in time). And with really proficient, I mean both a good understanding of the programming language semantically, being aware and keeping track of newer features in the language and having good knowledge of the standard library of the language (and potentially other common libraries). If you are not proficient in a programming language, you cannot work efficiently with it.
Personally as a backend .net developer, I consider myself proficient in C#, I know some basic SQL, and some basic TypeScript and JavaScript. Earlier on I have touched Basic, Pascal, Haskell, Prolog, Scheme, Ruby, Bash, Java and C. I have worked with several different programming paradigms and I have no doubt that this made me a better developer. Still, I don't consider myself a polyglot programmer. Even though I was proficient in Java and C earlier on, nowadays I would have to search basic things all the time if I'd work with those languages again. So that would not be efficient at all.
In my opinion, the concept of a polyglot programmer is only useful if it means a certain level of proficiency in multiple programming languages and that requires a lot more than understanding the syntax of those languages.
Personally as a backend .net developer, I consider myself proficient in C#, I know some basic SQL, and some basic TypeScript and JavaScript. Earlier on I have touched Basic, Pascal, Haskell, Prolog, Scheme, Ruby, Bash, Java and C. I have worked with several different programming paradigms and I have no doubt that this made me a better developer. Still, I don't consider myself a polyglot programmer. Even though I was proficient in Java and C earlier on, nowadays I would have to search basic things all the time if I'd work with those languages again. So that would not be efficient at all.
In my opinion, the concept of a polyglot programmer is only useful if it means a certain level of proficiency in multiple programming languages and that requires a lot more than understanding the syntax of those languages.
I've learned a number of languages, in my 35+ years of programming, but I generally only work with one or two at a time.
The last few years, it has been Swift (frontend), and PHP (backend).
The last few years, it has been Swift (frontend), and PHP (backend).
> Fascinated by the concept of polyglot programming, I decided to make good use of the fact that I know several exceptionally experienced developers and take a closer look at the topic.
The author selected only “polyglot” programmers so of course they would sing its praises. Or did the author expect them to say, “well I have experience with these 15 different frameworks, but I’d say 12 of them were a waste of time... meh.” You might make an off-hand comment on that on HN, but you typically won’t do that when you are being interviewed because of your seniority or whatever. That’s like downplaying things on your résumé.
Not that I personally think that being a “polyglot” is bad. But we need to distinguish between two things:
1. Mastering a wide breadth of programming ideas expressed through different languages 2. Knowing or having experience with implementing a lot of stuff
(2) might simply require being a polyglot because different domains and different fields use different languages. But (2) does not imply (1): you might have experience with eight different programming languages that are very much alike (only really differeing in third party libraries, perhaps), so you haven’t really gotten the chance to be a “polyglot” in the multiple paradigms sense of the word.
The author selected only “polyglot” programmers so of course they would sing its praises. Or did the author expect them to say, “well I have experience with these 15 different frameworks, but I’d say 12 of them were a waste of time... meh.” You might make an off-hand comment on that on HN, but you typically won’t do that when you are being interviewed because of your seniority or whatever. That’s like downplaying things on your résumé.
Not that I personally think that being a “polyglot” is bad. But we need to distinguish between two things:
1. Mastering a wide breadth of programming ideas expressed through different languages 2. Knowing or having experience with implementing a lot of stuff
(2) might simply require being a polyglot because different domains and different fields use different languages. But (2) does not imply (1): you might have experience with eight different programming languages that are very much alike (only really differeing in third party libraries, perhaps), so you haven’t really gotten the chance to be a “polyglot” in the multiple paradigms sense of the word.
What I love about systems like bazel, buck, etc. is that they tend to be language-agnostic, or maybe more like language accepting, unlike the new trend where each new language, comes their own build system: rust, go, dart/flutter, zig, etc... so good luck trying to explain dependencies from one to another... I simply wish the build process was not so entangled in the language itself.
So since my early days I've been doing multiple languages, started in Java at school then picked up JavaScript and Ruby pretty quickly, as well as being a bash Unix cli afficiando, since then my list of languages numbers in the double digits.
One of the things I am always astounded by is developers that only know one language, having multiple languages has changed the way I understand programming in general. At that point when I approach a problem I start by reasoning what the appropriate paradiagm or approach is to solve the problem and then decide the language from that. At this point when I see requirements that list X years in specific language I am confused as to why people don't just want programmers since languages seem so easy to pickup.
Their is a dark side to this I will admit though I do struggle a little bit more approaching a new language and then trying to find ways around concepts that I feel should be there, or I struggle sometimes to deal with language specific details.
One of the things I am always astounded by is developers that only know one language, having multiple languages has changed the way I understand programming in general. At that point when I approach a problem I start by reasoning what the appropriate paradiagm or approach is to solve the problem and then decide the language from that. At this point when I see requirements that list X years in specific language I am confused as to why people don't just want programmers since languages seem so easy to pickup.
Their is a dark side to this I will admit though I do struggle a little bit more approaching a new language and then trying to find ways around concepts that I feel should be there, or I struggle sometimes to deal with language specific details.
since languages seem so easy to pickup.
What takes time is being productive with the APIs and ecosystem, not learning the language.
What takes time is being productive with the APIs and ecosystem, not learning the language.
+1000
Or learning the underlying programming paradigm.
Even if Haskell used a Python-like syntax, I bet people would still find it 90% as hard to learn as they do now, due to the killer combination of lazy evaluation and purely-functional design.
Even if Haskell used a Python-like syntax, I bet people would still find it 90% as hard to learn as they do now, due to the killer combination of lazy evaluation and purely-functional design.
Yep. People often point at syntax and say "yuk!" but the problem is really not groking semantics. Syntax is just easy to bikeshed.
Thank you for clarifying my point, and attaching precise terminology to it!
Come to think of it, that's probably why people mistakenly think that Lisps are so hard. The syntax is scary, and easy to bikeshed - even though most of their semantics (for CL and Scheme, at least) are really easy, and very similar to Python.
Come to think of it, that's probably why people mistakenly think that Lisps are so hard. The syntax is scary, and easy to bikeshed - even though most of their semantics (for CL and Scheme, at least) are really easy, and very similar to Python.
I agree. For example, while easy to learn, Python is pretty hard to truly master, due to the huge library. I guess going the polyglot route depends on how much time you can spend programming. If it's a full time job, it pays. If you can devote at most 1-2 hours a day, like me, it's probably better to focus in one or two at most, otherwise you will never grok any of them.
The languages I'm using now are Ruby, Python, Elixir, JavaScript. Languages I was proficient into and I kind of let go are Java, C, Visual Basic, Perl. Maybe I should count some BASIC from the 80s too. Then there are a number of other languages I used for some time (PHP, even COBOL) but never become really an expert.
The pros:
I reuse some approaches that work well in some languages, unless they are definitely not idiomatic.
I keep my code idiomatic but simple because I don't have time to go into a language deep rabbit holes (eg: we usually don't need any metaprogramming.)
I can instantly smell bad design in some features because they remember me of the pitfalls of those parts of the languages I'm familiar with. Hint: moving the separator to the opposite end of Python's join / split is a bad idea, I never remember if "," splits or joins. Pick a direction and stick to it, a-la Ruby. After all, if ",".join(["a", "b"]) why not ",".split("a,b") ? Of course as I'm not a language designer this doesn't give me any advantage. Actually, I lose time thinking about it.
I can pick contracts for more projects because there are more chances that my potential customer has invested in one of the languages I know.
The cons:
I long for structural pattern matching a-la Elixir in every languages, not the glorified switch/case or the destructuring assignment that many languages are adding now.
I spend time to look for basic things like how to convert a string to lowercase because every language does it differently and I can't remember it. Is it necessary to be smart with those little things? Apparently yes so they go with downcase(), lower(), toLowerCase(), tolower(), lc() in random historical order. At least some languages copied other (Elixir from Ruby, JavaScript from Java.)
The pros:
I reuse some approaches that work well in some languages, unless they are definitely not idiomatic.
I keep my code idiomatic but simple because I don't have time to go into a language deep rabbit holes (eg: we usually don't need any metaprogramming.)
I can instantly smell bad design in some features because they remember me of the pitfalls of those parts of the languages I'm familiar with. Hint: moving the separator to the opposite end of Python's join / split is a bad idea, I never remember if "," splits or joins. Pick a direction and stick to it, a-la Ruby. After all, if ",".join(["a", "b"]) why not ",".split("a,b") ? Of course as I'm not a language designer this doesn't give me any advantage. Actually, I lose time thinking about it.
I can pick contracts for more projects because there are more chances that my potential customer has invested in one of the languages I know.
The cons:
I long for structural pattern matching a-la Elixir in every languages, not the glorified switch/case or the destructuring assignment that many languages are adding now.
I spend time to look for basic things like how to convert a string to lowercase because every language does it differently and I can't remember it. Is it necessary to be smart with those little things? Apparently yes so they go with downcase(), lower(), toLowerCase(), tolower(), lc() in random historical order. At least some languages copied other (Elixir from Ruby, JavaScript from Java.)
For me, the biggest benefit of being able to use significantly different languages, is being able to know "what's possible" so when approaching a new language due to whatever reason (work, interest, etc.) I know what to look for beyond just basic language features offered by pretty much all languages.
I think I’ve now reached a state where I only need two languages:
- Rust for when performance really matters
I guess I’m fortunate enough that I can pick my work.
- Rust for when performance really matters
- F# for everything else and React
I guess I’m fortunate enough that I can pick my work.
Agreed, I've found that "high level, mainstream ecosystem" is good for just about everything, and that I like a low-level Rust/C/Zig for tinkering.
One thing I haven't remedied is scripting/glue... I really don't love bash, but I also feel dirty using some full-blown scripting language while Scala sulks in the corner.
One thing I haven't remedied is scripting/glue... I really don't love bash, but I also feel dirty using some full-blown scripting language while Scala sulks in the corner.
When can you say that you have mastered a language?
I don't think you can really master dozens of languages, not if you also consider at least the SDK. If it's just the syntax then ok, but after almost 10 years with Java, more recently with kotlin, I still don't know a lot of JDK features. Sql? I worked with Oracle, SqlServer, Postgresql, MySql every one is a quite different beast, knowing (basic) SQL syntax is not enough.
Javascript? I'm no expert, but every day I learn a new "feature".
Having said that, the more languages you "know", the better, at least for me the job is more interesting :)
Having said that, the more languages you "know", the better, at least for me the job is more interesting :)
A couple of drawbacks I never see mentioned in these discussions:
* When you know more languages and you are faced with problems whose solutions are trivial to express in one of them, but you are forced to use another it is extremely frustrating.
* Trying to use a particular style/paradigm from a language in another one will raise a lot of eyebrows followed by "this is terrible code".
So to me, learning more languages just leads to frustration. I can't use them at work. I can't even use their style.
* When you know more languages and you are faced with problems whose solutions are trivial to express in one of them, but you are forced to use another it is extremely frustrating.
* Trying to use a particular style/paradigm from a language in another one will raise a lot of eyebrows followed by "this is terrible code".
So to me, learning more languages just leads to frustration. I can't use them at work. I can't even use their style.
I've found the opposite to be true. Knowing how I would solve a problem in more than one language has made a number of things easier over the years. Heck, if you look at Symfony's (a php framework) Validation API https://symfony.com/doc/current/validation.html they are implementing a Java JSR ( https://jcp.org/en/jsr/detail?id=303 ) using PHP constructs.
Ideas can cross pollinate between languages, but not everything translates well.
Ideas can cross pollinate between languages, but not everything translates well.
I generally enjoy picking up new languages. It's always a chance to see how other language designers worked around common programming tasks. It's also great because you get exposed to an entire set of tools that may be unfamiliar to you.
I'm a fan of polyglots.
I'm a fan of polyglots.
If you can't see the benefits of learning (mastering, I guess people call it) then you are in the wrong profession/hobby, even in 1999. It was an okay book, this is not an okay article.
That is definitly much better than being siloed in just one language.
Does it need parentheses or not?
How are closure variables managed? Do I need to release things?
Do lambdas require scoping braces or not? What's the damn syntax for them again???
Do I need to use case(X), switch(X), when(X), something else?
Do cases fall through or not?
How do I concatenate strings in this language again?
How do I get lengths in this language again?
Is it -> or => or functions? Are functions even first class? Can they be anonymous?
How did this language handle async operations again?
Anyone watching me work would probably think I don't know a damn thing. And after 25 years in the industry, I sometimes wonder the same thing.