Learn more ? I'm actively trying to unlearn a bunch of languages at this point!
ofcourse, when I was a wageslave in the bay area, its nice to know python, java, javascript, scala etc. - got me jobs every 2-3 years & put food on table.
now that i'm in academia, its completely upside down.
literally everybody is way more productive than me in just about any task. The other day I as supposed to program a poisson clock, it took forever. Meanwhile my advisors & classmates with zero industry experience chug thru these tasks effortlessly. Lately I've confirmed its because they know exactly 1 language , but they know it so well & in so much depth, they know exactly where to look, the right mcmc library, the right slice sampler, the right optimizer, that's what matters.
There's no point programming the same bloody front-end & back-end in a dozen different languages just because of industry constraints. That's like eating a spaghetti with a fork, a spoon, with chopsticks, with your fingers...its the same fucking spaghetti. cook something else, not just rotate dish-ware.
It's perfectly possible to know several languages in-depth. It just takes a lot of time and effort. Moreover, it gets easier with time and practice. Knowing N languages makes learning N+1 language just a bit easier. For me the turning point was around N == 10, since when learning a new language - and yes, in-depth, including idioms, stdlib, some external libraries, maybe some framework (if needed), and also some facts about the implementation and its inner workings[1] - takes a week at most, and for simpler cases a weekend is enough.
OTOH, it took around 15 years to get there. I understand that this kind of dedication may not be possible or worth it for everyone.
[1] Because there is very, very little unique features to each language. Unless you go to the fringes, you're bound to see the same concepts applied again and again and again, which gets really disheartening after a while. If you don't believe me, try naming any "new" feature which was added to your favorite (EDIT: I meant mainstream - TIOBE top 10 or 20 - lang here!) language recently - and I'll show you that same feature implemented 10 or 20 years ago in another language(s).
> Lately I've confirmed its because they know exactly 1 language , but they know it so well & in so much depth, they know exactly where to look, the right mcmc library, the right slice sampler, the right optimizer, that's what matters.
That sounds like your "issue" isn't knowing too many languages but that you don't know any one language as in depth as they do though?
I don't see why you'd want to unlearn anything.. doesn't that knowledge only help?
I think there are benefits to learning more languages but also support the idea you should have at least one you're super comfortable with.. thats not mutually exclusive!
Not sure know how far you may be into your career but as one who’s had a couple decades, it’s definitely possible to have both. I have been able to learn two very different languages (C and Haskell) to that level of comfort and am feeling nearly there in Rust. At the same time, I feel reasonably comfortable picking up a project in any of about 20 others with frequent reference to standard lib docs.
With only my own experience and that of people I’ve worked with to go by I can’t provide any broader scope, but I feel like it really is the case that a critical mass of familiarity with different languages and ecosystems makes it far easier to pick up and run with others and be more or less unaffected by the differences. It is probably important that the languages in your set be actually different though, rather than superficially different as most historically-popular languages have tended to be.
As a developer you are the chef. If all you can make is spaghetti, is it the kitchen's fault? OP makes the point explicit: the language shapes the way you approach problem solving.
When declarative, functional and procedural programming all yield the "same fucking spaghetti", you might just have missed the point.
It just sounds like they know the domain space better then you. You seem to know less about the domain of a poisson clock then them.
Maybe because I'm also unfamiliar with it, I can't judge. But knowing the right set of algorithms to solve domain specific problem sounds language agnostic to me.
That said, I agree that you should also continue to learn about CS, learn more data-structures, more algorithms, explore newer techniques and paradigms. That includes learning new languages, but not only that.
> Lately I've confirmed its because they know exactly 1 language , but they know it so well & in so much depth, they know exactly where to look, the right mcmc library, the right slice sampler, the right optimizer, that's what matters.
It sounds to me like you're working in a highly specialized area that requires deep domain knowledge and rich set of tools to apply that knowledge. Your colleagues have a lot of familiarity with that domain and those tools. Knowing multiple languages isn't your problem, it's just that you haven't spent your entire career working in this particular domain and you're playing catch-up.
I work for an airline. I known about constraints. If I knew only one language, I never would be at the level I am. Here is the tech stack I deal with daily.
VB6
Kix scripts
Powershell
.net 3.5
Winforms
WPF
.net 4+
.net core
.net asp
Java
JavaScript
React
Angular
C++
Golang.
If programming is a job and not your craft, it will be harder for you. You just have to practice more.
I mean sure, if you have limitless time then feel free to learn a bunch of programming languages as well as everything else you could want to learn. But real humans have opportunity cost. If you are a software engineer, the time you spend on skill development can already cut across many, many dimensions. Additional programming languages is just one, and I'd argue a fairly narrow one after you've touched on a few key language paradigms.
What about:
- Architecture
- Software Delivery
- Networking
- Project management
- Interaction design
- Visual design
- Human factors/Social systems
- Graphics/Art (2D/3D)
- Market validation
- Sales & Marketing
- Business planning and finance
- Application domain knowledge
- Operations and Monitoring
- Data infrastructure
- Analytics
- Machine Learning
- Machine Vision
- Computer Graphics
- Simulation
- Game Engineering + Design
- Information Retrieval + Recommender Systems
- Embedded systems/Control theory
- Optimization
- Scientific Computing
I mean there is basically an endless list of areas you can reach into in the limited time you have time focused on skill development as a software engineer beyond "on the job" training. Building a strong, broad "stack" of skills seems like a good investment. Learning new programming languages is a niche within a niche depending on how expansive a scope you set for yourself as a person creating software for the world to use.
At this point I have almost 20 languages that I've used for at least two years, which is what I consider an decent bar for "knowing" a language.
The problem I now have is that I don't know if I'll ever be able to master any language anymore. Mmmmaybe C, since I've used that fairly consistently, albeit on-and-off for 25 years.
But whenever I get to an "if" or "for" or function declaration, I often have to look at an example real quick because I have too many fighting memories: is it "if () then {}" or "if then:" and is it "else if" or "elif"? Do I need parens around the clauses? Is it "&&" or "and"?
Mostly I've found that the difference between two languages isn't the difference between two cheeseburgers, but rather the difference between a cheeseburger and lasagna. There's absolutely personal preferences (I still despise Python's whitespace-as-scope, even though I love the language), but they all get your belly full.
> I don't know if I'll ever be able to master any language anymore
Even with just a handful of languages in my toolbox, I feel this way too. A mixture of unease and anxiety.
In addition to syntactic variations, I find that the notion of writing idiomatic code in a given language amounts to more thinking overhead which eats into productivity. I'd need to be programming in the same language over a long period of time for idiomatic code to come more naturally. Can't seem to just instantly switch like some talented folk out there.
Try clustering similar languages into groups centered around shared features, then try to come up with high-level statements which hold true for all the languages in a group. Then try to derive the individual differences within the group from these statements. Use mnemonic techniques as required and prepare cheatsheets if needed.
One thing to realize, though, is that syntax - outside of a few special cases - is the most trivial part of any language. It's 100% acceptable to forget the syntax of a `for` loop in one language, as long as you still know that, in that language, the `for` loop is actually a for-each construct working on sequences of some types and additionally it's an expression which returns a sequence of results, making it equivalent to `map` higher-order function. Now, I described the `for` loop of (for example) Elixir, CoffeeScript, Racket, Common Lisp (`loop` with `collect`) and F# and Scala (with `yield`). As long as I know that a language I'm using right now belongs to this group, I can plan my implementation around the semantics outlined above. Then, when it comes to writing the code, I can just look up the syntax, or more commonly - just make my editor autocomplete and snippet-insert the relevant bits for me.
So, my advice would be to first learn and understand as many programming language features as possible, focus on their semantics, and then group the languages you know around the features. The syntax is really a trivial matter, and "mastering it" (ie. having the whole grammar constantly in your head) is not actually necessary in my experience.
I'm this way with foreign languages: Spanish and french. I know french very well, and learning/speaking Spanish is significantly harder because I'm always using french words by mistake. sure it'll get better with practice, but interlingual dyslexia is real.
IDEs are useful for this. Let them keep track of minutia like syntax rules and names of common but differently-named methods. I find also find that it only takes me about a day of picking a language back up to remember which way they've gone on most of these things.
This kind of gets at what I think is the big advantage of learning a bunch of languages: it gives you instincts for which things are minutia and which aren't. The things you listed that every language has but does differently, which are annoying to figure out and remember, that's the minutia.
At the end of the day it's more about applying the right patterns. A language is just a hammer. But you won't make good furniture without design skills. So it does not matter that you need to Google up things and forget things.
Lol - I remember years ago bouncing through javascript, python, lisp, prolog and others, all using ";" differently; then coming back around to C, and despite once knowing the spec by heart and having written C parsers, writing some one-line test programs... because I just could not believe that semicolon was a statement terminator - it looked so "this just isn't right". :)
> [syntax]
But when swapping languages, I had more trouble with cognitive interference on higher-level constructs. Syntax can go in cheat sheets[1], and idioms gathered in example files. Badly organized and incomplete documentation (once common before the programming community exploded in size) can be overlaid with tables of contents and notes. Because remembering how to find things in each languages' documentation was for me a major pain. But for designing say large apis, you have to remember things like some type-system path does look pretty... but only until you hit some language-misfeature monster that lives on it. And also not shy from some approach because of a misremembered or misattributed gotcha from another language. Though maybe that's easier now with so much discussion of best practices, and so much code available to read.
> cheeseburger and lasagna [...] they all get your belly full.
Or alternately, that they're all shambling toxic wretchedness, but you choose the one which seems likely to poison the customer the least, cooking it as well as circumstances permit. Cockroach popcorn and fried millipedes can be tasty. And even with swill milk... gypsum plaster is non-toxic... it's the other adulterants, little nutrition, and absence of sanitation that burn you. I do love programming, but I so look forward to less crippling languages.
The best technique I've found for staying sane when working in a large number of languages is to configure your editor to highlight errors based on language. If you use perens where you're not supposed to, your editor should tell you right away. No need to go find an example.
This becomes less useful when it's "which library do I use" or "what is the idiomatic way to do this in X language".
I know a bunch of languages too, or at least I claim that I know, because I've used it for some time in the past. And I do not remember the most of them, in the sense that I cannot right now start writing in those languages. But I can start to write C or rust without need to take a look into a tutorial or something like, because I use them routinely.
After lisp I've lost the idea of syntax as of an inherent part of language. You know, all that stuff, that lisp's s-expressions and their memory representation are mapped into each other seamlessly lead to a conclusion that any of them is not important, there is an abstract idea of a lisp object while conrete representations of lisp objects are just some practical ways to deal with them in different situations.
So the official language syntax is a one of the practical ways to represent ideas using that language. The most of languages do not bother to have a second representation, but it doesn't matter. Syntax doesn't matter. You can learn it on a whim in a half an hour of leizure reading.
I wrote a working compiler (learning type exercise level) effectively in pseudo-code resembling Java once because I didn't know the syntax very well, then commented it all out and translated it to Java line by line. Surprisingly, it had no bugs that I ever knew of. It definitely freed me up to think purely about the logic.
You might just throw down whatever and let the next compile/interpretation cycle let you know if you didn't get the syntax right.
Yes, esp some languages are deceptively similar: if you know C, then PERL, Javascript, and PHP looks very similar, but it is hard to remember the differences.
In case anyone isn't familiar with them, these two books[1][2] from the Pragmatic Programmer are great for doing just this. They offer a guided intro to 7 different languages each, and they're a whole lot of fun.
I loved the first one. It's one of my all-time favorite technical books. I was really disappointed by the second, though. I'd recommend skipping it. The second lacked the cohesion of the first probably owing to the fact that it wasn't written by the same author as the first. And each chapter was written by a different author.
I learned programming from books like The Waite Group's Turbo-C Bible around 1989. In trying to teach my oldest son programming through using modern books, it seemed much more difficult. IDEs and languages change so rapidly that books (and even online tutorials) are dated quickly. Menu options change, links stop working, etc.
It made my son more frustrated when he was first starting.
I spent a lot of time learning Haskell early in my career. I doubt I'll ever write an actual program in Haskell. I probably won't write so much as a single line of it that will ever see production. (Thank goodness. Haskell is far from perfect, despite its many zealots.) But learning Haskell has changed the way I write code in any language. It's helped me to write better, more testable, more readable, more maintainable, more bug-free Javascript. I wrote a lot of Clojure for a while a few years ago and being familiar with Haskell dropped the learning curve of Clojure down to almost nothing. I personally adore Lisps more than Haskell, but Haskell unlocked the world of functional programming for me. It also showed me the true power strong typing has at a time when the only strong typing I was aware of was the dismal type system of Java. (Like late 90s Java at that!)
I couldn't agree more, but if I could make a recommendation. If you already know a mainstream OO language, you won't get much benefit out of learning another in the same arena. Going from Java to C# you will learn less than going from javascript to ocaml or Java to Haskell.
The best thing (for my own learning) I ever decided to do was learn Haskell. I have never been paid to write code in Haskell but it gave me such a confidence with languages that I don't think I've seen any language features in any other language that has ever surprised me or that I felt like I couldn't learn. Haskell and it's language extensions will expose you to many many different ideas. It helped me learn Rust, I feel like I can read ocaml, any other functional language doesn't feel like a stretch to read, etc
So, don't just learn many languages. My advice would be to pick languages across paradigms and learn them. Don't waste your time learning 5 object oriented languages.
So I fully agree here because techniques from one language often lead to much better technique in a language of a different paradigm.
For instance, I now use many of the functional techniques I’ve learned in JavaScript to write less, easier to read code instead of more loc of imperative code. I’ve also worked at a company that had many functional patterns implemented in php, and frankly made the language quite decent.
In terms of the time issue, I spend about 15 minutes a day just before bedtime learning new languages. I probably manage to do this 4 days out of every 7.
My suggestion is Objective-C. It's just so weird to anyone who's never coded in it, that it will force you out of your comfort zone into new ways of thinking. The NS framework is probably the most well designed stdlib of any language ever, and the whole thing is inspired directly from Smalltalk. Protocol Oriented Programming [0] was also a real revelation for me, and I still apply those concepts anywhere I can. It's also a great introduction to lower level concepts like pointers and memory management that is a lot more forgiving than C/C++.
I feel the highest good I get out of playing with alternatives is that I hit a higher rate of "hits" on picking up on things previously invisible to me.
Playing with a different editor gives me ideas for different workflows and shortcuts which my main editor already supports. Playing with a different programming language shows me how powerful X is which I never touched in my main programming language.
The focus on learning and exploring an alternative is more powerful for me than mastering that alternative. I get the greatest benefit with a relatively smaller investment that way.
Maybe instead of learning more programming languages, just pick small bits of something to explore.
This might make for an interesting app (which won't make money.) Create a sort of "useless but interesting facts" type of app for programmers. Allow people to submit "cards" with something on it and then up/down vote on the card. The snippet could be a term, clever code, or anything bite size. The programming equivalent of "how to say ck in Klingon."
It is really fun to learn new languages and you certainly should know a language in each of the major paradigms. But beyond that I think learning languages might have diminishing returns compared to tackling other "axes" of difference, e.g. learning new platforms, frameworks or environments.
The conceptual differences between a desktop GUI app, a command line app or a web app are much bigger than between say functionally similar web apps implemented in three different programming languages. A business app based on a relational database is fundamentally different from say a game, even if the language is the same.
I think there's a bit of a threshold with language learning. When you know a handful (or just theo necessary ones for your job), there is probably a bit of tendency to be religious about your "stack". When you know a few more than you need, then you're driven to pick between them for any given thing. Then, you start picking languages you don't know and learning them to do some thing you need done, and so on.
I wrote some data automations recently for a client. Here are the languages and DSLs that ended up in the mix: cron, Makefile, bash, sed, regex, jq query, python, R, sql, nginx conf.
I think especially if you're a vertically scaling kind of gal, and you have a fondness for conciseness, parsimony and efficiency; you'll just end up attracted to many language solutions. I just think there is no better way to write less code or keep the semantics of your language more relevant to the task in hand.
Frankly I've never understood the desire to be a polyglot. The time spent learning new syntax and a new standard library could have been spent learning libraries, algorithms, data structures, etc, so I don't think it's the most productive way to improve yourself as a programmer. I'm more interested in learning a new language because it lets me do something I couldn't do before.
But also learn one or two languages that fit your domain of work, really really well. I have seen too many programmers that justify their lack of skills in their main language they are supposed to know by bragging about their knowledge of some hipster language they rarely use. "my code is way too slow, but hey I know the syntax of dependent types in Agda..."
I learned many languages for years and I received a poor return on time investment. Later, I started learning AWS in depth and studying for certs. I now know way more than I previously did about networking, envelope encryption, messaging, infrastructure as code, pipelines, caching, CDN’s, networking protocols, load balancers, dns, and designing highly available and scalable systems. In summary, don’t forgo learning about systems to chase a hot new language.
Instead of learning more programming languages, learn more programming languages paradigms. If you know OOP, try functional programming; if you use dynamic types, try static types as well.
You don't get anything by learning more and more programming languages. Programming languages are tools, be expert at 2 or 3 languages and that should be enough. Learn anything more to solve a specific problem.
You understand the crux of a language by being expert at it not by "me too" novice at it.
> You understand the crux of a language by being expert at it not by "me too" novice at it.
Let's not pretend "knowing" a language well is akin to a 10-year-journey like some arcane samurai art.
If you
- could build an interpreter for a minimal version of the language
- can expand most syntactic sugar into more minimal constructs of the language
- can reason about the language in usual PL terms (call-by-value/call-by-name, pure/not-pure, strictly/dynamically typed, ...)
- know the 5-10 most important milestones in the history of that language
- know the standard libraries so that you don't repeat code that is written there,
then what use is there to master a language further? If someone is experienced in language learning, the above can be accomplished for nearly any language in idk, a year? At that point of mastery, it makes much sense to learn another way of thinking instead of memorizing the official language specification verbatim.
A programmer with 3 completely different paradigms to think in will be much more effective than one with just one paradigm to think in. Time is much better spent learning new paradigm than to gain that last bit of mastery.
The "we use the right tool for the right job" mindset looks good on paper but doesn't scale very well.
Most of the time it tends to favor developers who are the most distracted by the newest and shiniest trends.
It is helpful for any dev team to have 2 or 3 programming languages in their toolbox that they can use to solve their problems. Any discussion about adding a new language to that toolbox would need to involve discussions about QA, deployment and long-term supportability. Unfortunately most developers are less concerned about those "non-technical" aspects.
THIS 100%! ...I'm an extremely undisciplined never-finish-even-starting-almost-antyhing ADHD-I crazed squirrel-brain that never has enough out of learning "just a tiny bit" of some new programming language, new tech, or even entirely new field, but hardly gets good at anything.
Sure, learn one or two languages from completely different paradigms than what you use daily, to broaden your mind and seed stuff in context. But the... STOP! And get more projects finished faster and better instead, you'll learn 100x faster this way, and learn more useful things.
Then learn some time management and communication skills...
I dislike this reasoning with passion.
I tend to think the pleasure of learning a new programming language is rarely productive, except for newbies.
I also think that our world would be a better place with fewer languages, we really have a lot of useless redundancy.
What we need, most of the time, is a good library tailored to solve a specific problem (string manipulation or complex maths could even be done in BASIC or asm with a powerful dedicated library)
Creating a new language is like forking a code base.
Because of knowing many language helps me a lot. Example, the import module system of Python is amazing. I'm not a fan of it at all but I really like how it were design. When I come to Ruby, I think Ruby need some love for its module.
Or JavaScript binding? Even if arrow function, it does has place you cannot avoid writing `.bind(this)` and you ask a question why we have to do this?
Then come pattern matching of Elixir/Erlang and it blows my mind and I just want to have that ability every where.
Then come Elm/Hashkell or any language that use `whitespace` instead of commma/parenthesis and I just love how natural these language read.
```
hello(username, country)
```
compare with
```
hello username country
```
The more I learn those languages, the more I appreciate the people who invented these and always thinking of different way to do thing.
[+] [-] dxbydt|7 years ago|reply
ofcourse, when I was a wageslave in the bay area, its nice to know python, java, javascript, scala etc. - got me jobs every 2-3 years & put food on table.
now that i'm in academia, its completely upside down. literally everybody is way more productive than me in just about any task. The other day I as supposed to program a poisson clock, it took forever. Meanwhile my advisors & classmates with zero industry experience chug thru these tasks effortlessly. Lately I've confirmed its because they know exactly 1 language , but they know it so well & in so much depth, they know exactly where to look, the right mcmc library, the right slice sampler, the right optimizer, that's what matters.
There's no point programming the same bloody front-end & back-end in a dozen different languages just because of industry constraints. That's like eating a spaghetti with a fork, a spoon, with chopsticks, with your fingers...its the same fucking spaghetti. cook something else, not just rotate dish-ware.
[+] [-] klibertp|7 years ago|reply
OTOH, it took around 15 years to get there. I understand that this kind of dedication may not be possible or worth it for everyone.
[1] Because there is very, very little unique features to each language. Unless you go to the fringes, you're bound to see the same concepts applied again and again and again, which gets really disheartening after a while. If you don't believe me, try naming any "new" feature which was added to your favorite (EDIT: I meant mainstream - TIOBE top 10 or 20 - lang here!) language recently - and I'll show you that same feature implemented 10 or 20 years ago in another language(s).
EDIT: more neutral wording.
[+] [-] rifung|7 years ago|reply
That sounds like your "issue" isn't knowing too many languages but that you don't know any one language as in depth as they do though?
I don't see why you'd want to unlearn anything.. doesn't that knowledge only help?
I think there are benefits to learning more languages but also support the idea you should have at least one you're super comfortable with.. thats not mutually exclusive!
[+] [-] mokus|7 years ago|reply
With only my own experience and that of people I’ve worked with to go by I can’t provide any broader scope, but I feel like it really is the case that a critical mass of familiarity with different languages and ecosystems makes it far easier to pick up and run with others and be more or less unaffected by the differences. It is probably important that the languages in your set be actually different though, rather than superficially different as most historically-popular languages have tended to be.
[+] [-] mawaldne|7 years ago|reply
https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb
“A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness.”
[+] [-] jlg23|7 years ago|reply
As a developer you are the chef. If all you can make is spaghetti, is it the kitchen's fault? OP makes the point explicit: the language shapes the way you approach problem solving.
When declarative, functional and procedural programming all yield the "same fucking spaghetti", you might just have missed the point.
[+] [-] didibus|7 years ago|reply
Maybe because I'm also unfamiliar with it, I can't judge. But knowing the right set of algorithms to solve domain specific problem sounds language agnostic to me.
That said, I agree that you should also continue to learn about CS, learn more data-structures, more algorithms, explore newer techniques and paradigms. That includes learning new languages, but not only that.
[+] [-] not_kurt_godel|7 years ago|reply
It sounds to me like you're working in a highly specialized area that requires deep domain knowledge and rich set of tools to apply that knowledge. Your colleagues have a lot of familiarity with that domain and those tools. Knowing multiple languages isn't your problem, it's just that you haven't spent your entire career working in this particular domain and you're playing catch-up.
[+] [-] ryanthedev|7 years ago|reply
VB6 Kix scripts Powershell .net 3.5 Winforms WPF .net 4+ .net core .net asp Java JavaScript React Angular C++ Golang.
If programming is a job and not your craft, it will be harder for you. You just have to practice more.
[+] [-] gfodor|7 years ago|reply
What about:
- Architecture
- Software Delivery
- Networking
- Project management
- Interaction design
- Visual design
- Human factors/Social systems
- Graphics/Art (2D/3D)
- Market validation
- Sales & Marketing
- Business planning and finance
- Application domain knowledge
- Operations and Monitoring
- Data infrastructure
- Analytics
- Machine Learning
- Machine Vision
- Computer Graphics
- Simulation
- Game Engineering + Design
- Information Retrieval + Recommender Systems
- Embedded systems/Control theory
- Optimization
- Scientific Computing
I mean there is basically an endless list of areas you can reach into in the limited time you have time focused on skill development as a software engineer beyond "on the job" training. Building a strong, broad "stack" of skills seems like a good investment. Learning new programming languages is a niche within a niche depending on how expansive a scope you set for yourself as a person creating software for the world to use.
[+] [-] gilbetron|7 years ago|reply
The problem I now have is that I don't know if I'll ever be able to master any language anymore. Mmmmaybe C, since I've used that fairly consistently, albeit on-and-off for 25 years.
But whenever I get to an "if" or "for" or function declaration, I often have to look at an example real quick because I have too many fighting memories: is it "if () then {}" or "if then:" and is it "else if" or "elif"? Do I need parens around the clauses? Is it "&&" or "and"?
Mostly I've found that the difference between two languages isn't the difference between two cheeseburgers, but rather the difference between a cheeseburger and lasagna. There's absolutely personal preferences (I still despise Python's whitespace-as-scope, even though I love the language), but they all get your belly full.
[+] [-] miqkt|7 years ago|reply
Even with just a handful of languages in my toolbox, I feel this way too. A mixture of unease and anxiety.
In addition to syntactic variations, I find that the notion of writing idiomatic code in a given language amounts to more thinking overhead which eats into productivity. I'd need to be programming in the same language over a long period of time for idiomatic code to come more naturally. Can't seem to just instantly switch like some talented folk out there.
[+] [-] klibertp|7 years ago|reply
One thing to realize, though, is that syntax - outside of a few special cases - is the most trivial part of any language. It's 100% acceptable to forget the syntax of a `for` loop in one language, as long as you still know that, in that language, the `for` loop is actually a for-each construct working on sequences of some types and additionally it's an expression which returns a sequence of results, making it equivalent to `map` higher-order function. Now, I described the `for` loop of (for example) Elixir, CoffeeScript, Racket, Common Lisp (`loop` with `collect`) and F# and Scala (with `yield`). As long as I know that a language I'm using right now belongs to this group, I can plan my implementation around the semantics outlined above. Then, when it comes to writing the code, I can just look up the syntax, or more commonly - just make my editor autocomplete and snippet-insert the relevant bits for me.
So, my advice would be to first learn and understand as many programming language features as possible, focus on their semantics, and then group the languages you know around the features. The syntax is really a trivial matter, and "mastering it" (ie. having the whole grammar constantly in your head) is not actually necessary in my experience.
[+] [-] dajohnson89|7 years ago|reply
[+] [-] YjSe2GMQ|7 years ago|reply
C, {all kinds of assembly}, {C++, Java, C#}, {Python, Ruby}, {Haskell, OCaml}, Prolog, {VHDL, Verilog}
[+] [-] rb808|7 years ago|reply
[+] [-] sanderjd|7 years ago|reply
This kind of gets at what I think is the big advantage of learning a bunch of languages: it gives you instincts for which things are minutia and which aren't. The things you listed that every language has but does differently, which are annoying to figure out and remember, that's the minutia.
[+] [-] Waterluvian|7 years ago|reply
[+] [-] holoduke|7 years ago|reply
[+] [-] mncharity|7 years ago|reply
Lol - I remember years ago bouncing through javascript, python, lisp, prolog and others, all using ";" differently; then coming back around to C, and despite once knowing the spec by heart and having written C parsers, writing some one-line test programs... because I just could not believe that semicolon was a statement terminator - it looked so "this just isn't right". :)
> [syntax]
But when swapping languages, I had more trouble with cognitive interference on higher-level constructs. Syntax can go in cheat sheets[1], and idioms gathered in example files. Badly organized and incomplete documentation (once common before the programming community exploded in size) can be overlaid with tables of contents and notes. Because remembering how to find things in each languages' documentation was for me a major pain. But for designing say large apis, you have to remember things like some type-system path does look pretty... but only until you hit some language-misfeature monster that lives on it. And also not shy from some approach because of a misremembered or misattributed gotcha from another language. Though maybe that's easier now with so much discussion of best practices, and so much code available to read.
> cheeseburger and lasagna [...] they all get your belly full.
Or alternately, that they're all shambling toxic wretchedness, but you choose the one which seems likely to poison the customer the least, cooking it as well as circumstances permit. Cockroach popcorn and fried millipedes can be tasty. And even with swill milk... gypsum plaster is non-toxic... it's the other adulterants, little nutrition, and absence of sanitation that burn you. I do love programming, but I so look forward to less crippling languages.
[1] http://rigaux.org/language-study/syntax-across-languages.htm...
[+] [-] jniedrauer|7 years ago|reply
This becomes less useful when it's "which library do I use" or "what is the idiomatic way to do this in X language".
[+] [-] ordu|7 years ago|reply
After lisp I've lost the idea of syntax as of an inherent part of language. You know, all that stuff, that lisp's s-expressions and their memory representation are mapped into each other seamlessly lead to a conclusion that any of them is not important, there is an abstract idea of a lisp object while conrete representations of lisp objects are just some practical ways to deal with them in different situations.
So the official language syntax is a one of the practical ways to represent ideas using that language. The most of languages do not bother to have a second representation, but it doesn't matter. Syntax doesn't matter. You can learn it on a whim in a half an hour of leizure reading.
[+] [-] theonemind|7 years ago|reply
You might just throw down whatever and let the next compile/interpretation cycle let you know if you didn't get the syntax right.
[+] [-] billfruit|7 years ago|reply
[+] [-] walterstucco|7 years ago|reply
[deleted]
[+] [-] cnasc|7 years ago|reply
[1] https://pragprog.com/book/btlang/seven-languages-in-seven-we...
[2] https://pragprog.com/book/7lang/seven-more-languages-in-seve...
[+] [-] Lowkeyloki|7 years ago|reply
[+] [-] 300bps|7 years ago|reply
It made my son more frustrated when he was first starting.
[+] [-] macintux|7 years ago|reply
[+] [-] mlevental|7 years ago|reply
[+] [-] Lowkeyloki|7 years ago|reply
[+] [-] leshow|7 years ago|reply
The best thing (for my own learning) I ever decided to do was learn Haskell. I have never been paid to write code in Haskell but it gave me such a confidence with languages that I don't think I've seen any language features in any other language that has ever surprised me or that I felt like I couldn't learn. Haskell and it's language extensions will expose you to many many different ideas. It helped me learn Rust, I feel like I can read ocaml, any other functional language doesn't feel like a stretch to read, etc
So, don't just learn many languages. My advice would be to pick languages across paradigms and learn them. Don't waste your time learning 5 object oriented languages.
[+] [-] nikhizzle|7 years ago|reply
For instance, I now use many of the functional techniques I’ve learned in JavaScript to write less, easier to read code instead of more loc of imperative code. I’ve also worked at a company that had many functional patterns implemented in php, and frankly made the language quite decent.
In terms of the time issue, I spend about 15 minutes a day just before bedtime learning new languages. I probably manage to do this 4 days out of every 7.
[+] [-] aphextron|7 years ago|reply
[0] https://www.sicpers.info/2015/06/protocol-oriented-programmi...
[+] [-] gexla|7 years ago|reply
Playing with a different editor gives me ideas for different workflows and shortcuts which my main editor already supports. Playing with a different programming language shows me how powerful X is which I never touched in my main programming language.
The focus on learning and exploring an alternative is more powerful for me than mastering that alternative. I get the greatest benefit with a relatively smaller investment that way.
Maybe instead of learning more programming languages, just pick small bits of something to explore.
This might make for an interesting app (which won't make money.) Create a sort of "useless but interesting facts" type of app for programmers. Allow people to submit "cards" with something on it and then up/down vote on the card. The snippet could be a term, clever code, or anything bite size. The programming equivalent of "how to say ck in Klingon."
[+] [-] goto11|7 years ago|reply
The conceptual differences between a desktop GUI app, a command line app or a web app are much bigger than between say functionally similar web apps implemented in three different programming languages. A business app based on a relational database is fundamentally different from say a game, even if the language is the same.
[+] [-] usgroup|7 years ago|reply
I wrote some data automations recently for a client. Here are the languages and DSLs that ended up in the mix: cron, Makefile, bash, sed, regex, jq query, python, R, sql, nginx conf.
I think especially if you're a vertically scaling kind of gal, and you have a fondness for conciseness, parsimony and efficiency; you'll just end up attracted to many language solutions. I just think there is no better way to write less code or keep the semantics of your language more relevant to the task in hand.
[+] [-] CuriouslyC|7 years ago|reply
[+] [-] tezka|7 years ago|reply
[+] [-] deboflo|7 years ago|reply
[+] [-] vnorilo|7 years ago|reply
C/C++/Rust/Ada on bare metal or systems work for building abstraction upwards from the hardware.
Clojure/Scheme/Common Lisp/Racket: A good dynamic language that's extremely composable, to build abstraction downward from human logic.
ML/F#/Haskell: Powerful type systems that can layer abstraction on abstraction.
I have no experience of the following, but I imagine at least cog and erlang belong to similarly mind-expanding buckets.
[+] [-] wintorez|7 years ago|reply
[+] [-] acroback|7 years ago|reply
Does author has trouble with discipline?
You don't get anything by learning more and more programming languages. Programming languages are tools, be expert at 2 or 3 languages and that should be enough. Learn anything more to solve a specific problem.
You understand the crux of a language by being expert at it not by "me too" novice at it.
[+] [-] schwurb|7 years ago|reply
Let's not pretend "knowing" a language well is akin to a 10-year-journey like some arcane samurai art.
If you
- could build an interpreter for a minimal version of the language
- can expand most syntactic sugar into more minimal constructs of the language
- can reason about the language in usual PL terms (call-by-value/call-by-name, pure/not-pure, strictly/dynamically typed, ...)
- know the 5-10 most important milestones in the history of that language
- know the standard libraries so that you don't repeat code that is written there,
then what use is there to master a language further? If someone is experienced in language learning, the above can be accomplished for nearly any language in idk, a year? At that point of mastery, it makes much sense to learn another way of thinking instead of memorizing the official language specification verbatim.
A programmer with 3 completely different paradigms to think in will be much more effective than one with just one paradigm to think in. Time is much better spent learning new paradigm than to gain that last bit of mastery.
[+] [-] shiitake|7 years ago|reply
Most of the time it tends to favor developers who are the most distracted by the newest and shiniest trends.
It is helpful for any dev team to have 2 or 3 programming languages in their toolbox that they can use to solve their problems. Any discussion about adding a new language to that toolbox would need to involve discussions about QA, deployment and long-term supportability. Unfortunately most developers are less concerned about those "non-technical" aspects.
[+] [-] nnq|7 years ago|reply
Sure, learn one or two languages from completely different paradigms than what you use daily, to broaden your mind and seed stuff in context. But the... STOP! And get more projects finished faster and better instead, you'll learn 100x faster this way, and learn more useful things.
Then learn some time management and communication skills...
[+] [-] picacho|7 years ago|reply
[+] [-] stephc_int13|7 years ago|reply
What we need, most of the time, is a good library tailored to solve a specific problem (string manipulation or complex maths could even be done in BASIC or asm with a powerful dedicated library)
Creating a new language is like forking a code base.
[+] [-] kureikain|7 years ago|reply
Because of knowing many language helps me a lot. Example, the import module system of Python is amazing. I'm not a fan of it at all but I really like how it were design. When I come to Ruby, I think Ruby need some love for its module.
Or JavaScript binding? Even if arrow function, it does has place you cannot avoid writing `.bind(this)` and you ask a question why we have to do this?
Then come pattern matching of Elixir/Erlang and it blows my mind and I just want to have that ability every where.
Then come Elm/Hashkell or any language that use `whitespace` instead of commma/parenthesis and I just love how natural these language read.
``` hello(username, country) ```
compare with
``` hello username country ```
The more I learn those languages, the more I appreciate the people who invented these and always thinking of different way to do thing.
[+] [-] codr7|7 years ago|reply
And once you know enough different languages; design and build your own [0], even if no one will use them.
[0] https://github.com/codr7/g-fu