I think the period where I grew the most as a dev was an interlude when I knew I was changing jobs, including moving countries.
From having built trading systems in c++, I ended up building, over about a year or so:
- A django (python / js) website. It integrated with both Android (java) and iOS (objective-C) apps that could read QR codes and ask the server stuff. It also made me interact with the app stores for the first time. It was also the first time I did anything on the web, including figuring out how pages are laid out. Bought a MacBook for the first time too.
- A consumer iOS app written in Swift. New language again. Went native, ran into a lot of constraint errors that eventually taught me a lot.
- A trading system in c++ that didn't use STL.
I remember at the beginning of each new language/framework thinking "OMG how do I do this". And yet it's not that bad once you've done it once or twice. I reckon it's a lot easier than learning a new natural language (German, Mandarin).
The thing it really gives you is a low opportunity cost. If you have some task, and the evidence points towards some specific framework/language being a good choice, hopefully you won't resist it due to internal anxiety about starting over again.
The constraints are such a pain at first for iOS! Then you get used to it and become a guru :D Happy you've had opportunity to try out a vast ecosystem.
Different languages also have their own culture and ecosystem, which are also valuable to learn in order to get a different perspective.
Some things that are taken as best practices are bad practices in other langauges and vice versa.
For example, lots of Java devs are against early and multiple returns to the point of absurdity, while in functional languages this is idiomatic and no problem at all.
Using different languages lets you see how different approaches work out in practice, so you can get a better view about which approaches work and which approaches are just cargo-cult nonsense.
I think this is my first post on HN, but have been a long time lurker.
That aside. Your point around ecosystems is interesting to me. As a wannabee coder I'm always trying new things. Most of my code was in PowerShell although I did do a bit of C++ and Delphi in school.
I have been dabbling with dotnet core (C#) and Python the last couple of years.
I tried to get into Java a bit, but to be frank the learning curve to go from start to consuming a REST service was just way too hard. I couldn't understand the difference between when I should be using JavaEE, JavaSE, spring boot, spring framework etc. I gave up after two days.
In contrast Python is just so easy. And if I want something more robust I'll rather go to dotnet.
Go is on my list as it seems to offer a lot of what I want, and although there are some apparently weird things in it I think i can be productive with it for some basic business logic within a couple of days.
The problem being, cargocults tend to hold the power. So yes, learn new concepts, practice them and more, but don't be surprised if in practice you can barely utilize them thanks to cargocults insisting they are wrong.
We see this in C#. Has a ridiculous amount of features outside default OOP and continues to get more baseline, even has great interop with several other languages. But culture changes very, very slowly. Large scale adoption tends to happen only when some major framework insists on using a certain paradigm.
"For example, lots of Java devs are against early and multiple returns to the point of absurdity, while in functional languages this is idiomatic and no problem at all."
Which functional language are you talking about? Of the two functional languages I know, Elm can only have a single return statement. Scala encourages a single return.
Rust convinced me that having a section at the top of a function that early returns in error/exceptional situations works very well. I find myself missing this in the one functional language I've tried, Elixir, although I find Elixir worth it for other reasons.
I initially fell in love with the Rust convention of simply bubbling up errors throughout a function but I've gradually realized that leads to a poor API. [1]
I'm currently learning c++ for a personal project. I want to use a library with an API that's sufficiently templated it'll be easier to write a c++ shim than directly generating bindings. So far I'm at the stage where I'm constantly thinking Rust does things better. Hopefully later on I'll realize why the different tradeoffs c++ makes make sense. (One example would be how generic code is typechecked).
[1]: If you want to be able to simply propagate up errors with the `?` operator you need to implement automatic conversations from your dependencies' errors to your error type. But that means your API will have a single error type for every dependency error type - say MyError::Io(io::Error) - which is the wrong level of specificity. I now think you should either expose only a string message your user can just show their end user or an error that's much more specific so they can write code that intelligently responds to it. Something like MyError::ReadConfigFailed(io::Error)
I find the java example different to my experience. java doesn't have all expressions return values, like if, making the attempt to have single returns from functions much harder to do tidily than in other languages like for example ruby, rust, scala.
not just get familiar with somebody's interpretations that they implemented as a language.
Languages that I used besides my job language barely gave me anything, in most cases they made me appreciate more for sane environment (package managers, IDEs, debuggers, strong standard library)
edit. just to be clear:
I don't see value in learning C#+Java+PHP, but C#+Erlang? yea
I do see value in learning Rust after C
but still - concepts are more important, you don't have to learn langs in order to be familiar with concepts
Learn software engineering - it's broad as hell and you can easily do that using one language
Concepts can often be simulated in many languages, but only clumsily, and the lack of ergonomic affordances in syntax, control flow and type systems can lead one to believe that a different paradigm doesn't work very well - it can be hard to see the wood for the trees.
It's hard to write a declarative querying library in C. SQL is not an ideal language, but as a way of expressing intent rather than a physical query plan, it's a long way away from C.
It's hard to appreciate the power of interactive debugger REPLs like binding.pry or JS's debugger without experiencing them. A C++ debugger, even a Java debugger, is a pale imitation, and it's not easy to simulate the experience without building a dynamic language inside the static language.
If all you've ever known is statically typed languages, you can suffer from a myopic parochialism with respect to dynamic typing. IMO the most popular statically typed languages only work well because they have runtime polymorphism holes in their type systems. More powerful statically typed programming languages tend to grow ever more esoteric typing constructs to enable static types to follow dynamic control and data flow - there's an inherent tension there and if language complexity isn't carefully managed, it becomes harder to express intent and error messages get more vague and cryptic.
Algebraic data types and pattern matching tends to be under-appreciated if one is schooled in object-oriented languages. Object orientation has a big hammer for switching control flow based on data values, dynamic dispatch, and architectures tend to leverage dynamic dispatch where they would be much better off with switch statements. If the set of variants is known up front, you're probably much better off with sum types and pattern matching than with interfaces, abstract classes and virtual methods.
I have a few reasons to work in (not just learn) close languages. The languages might use roughly similar concepts and syntax and solve similar problems (think, C++, C#, PHP, Java, Go), yet their community, practices, tooling, frameworks are wildly different.
If as a C++ developer in 2005 you never experienced how smooth debugging and profiling could be in Java, how fast things could compile, how easy it was to drop a jar and deploy to your server farm, you were missing out.
Similarly, if as a Go developer you don’t know how quickly you can install WordPress, write a 200 line PHP plugin, and get an entire business off the ground, you are missing out.
Most transformational for me was to be a Common Lisp developer, and find the language that allowed the ideas and concepts in my brain to be turned into prototype at the speed of thought. It’s a challenging language to use in the real world, but it really brought the point home that a language is just a vessel for ideas.
>but still - concepts are more important, you don't have to learn langs in order to be familiar with concepts
You kinda do. Concepts are often exclusive to languages. And often concepts can't be internalized without practice of that lang.
Your own examples in your edit literally contradict what you say as you chose langs with extremely divergent concepts. C# and Erlang, Rust and C. You missed haskell and lisp.
When I was in undergrad our professor had us learn Java, but also Lisp and Prolog, and that was very valuable to my growth as an aspiring (and now thankfully employed) programmer :)
+1. I once wrote an article exactly describing this[1]... but I think that learning concepts involves learning different languages because the concepts are not implemented the same way in every language and seeing different implementations helps understanding the nuances and differences a lot.
Charlie Watts wasn't just into jazz, he was into all music. George Harrison understood that jazz could deepen him as a musician, but found Indian music.
If one wants to write a language that is truly original, that might actually influence the future, not just smearing around familiar weightings for features found useful "in the trades", then one wants to have some grasp of languages representative of every language in use. Then, only proceed with a compelling vision of what's missing.
For the rest of us, being a language junkie can be a problem. Without being judgmental, it is possible for a person to be too promiscuous. Same with languages. I wish I could just stick to Haskell and get work done.
I agree that it is way more valuable to know / being able to invent concepts, algorithms, architectures. That is what interests me most when I design software products for my clients and for my own company.
Languages for me are just tools, like screwdrivers. I use / used many and do not get hung up. And no I do not learn languages just for the fuck of it. Only if I see some positive ROI.
I’ve worked deeply with about 9 programming languages.
Not hobby level, but client work level.
They did not really help me to become a better software engineer.
What did?
Being able to understand the business of the customer and create software that helped them do that easier.
That’s why today I tell junior programmers that almost everything we do these days could be accomplished with Bash, text files to hold the data and static html files.
Don’t focus on the language, focus on the business case.
Sure some languages are more efficient than others but all those do is help you build a solution faster. And languages are similar for the most part - so that helps you learn new languages faster.
"Being able to understand the business of the customer and create software that helped them do that easier."
I don't consider that software 'engineering' necessarily.
Yes to be a more useful employee or more successful freelancer etc understanding the business case is absolutely an essential skill. But the 'engineering' begins once the problem has been defined; how do you actually implement the vision.
You can write basically the same code with different syntax, or you can learn the paradigms, styles, and idioms associated with each language. That latter is the valuable part because it teaches you a new way to conceptualize and approach problems.
That's because you've been learning languages that are similar. The algol family of languages with OOP.
You need to learn languages outside of this family to see the benefit. But the benefit won't be in your ability to do "business". It will be exclusively improvements in programming unrelated to "business programming"
>That’s why today I tell junior programmers that almost everything we do these days could be accomplished with Bash, text files to hold the data and static html files.
Why? Junior programmers are aware of this already. And get this: junior programmers are even aware that everything can be accomplished with assembly language. They are also aware why things aren't done in assembly, typically.
Learning different programming languages definitely helped expose me to new ideas, but I think it's a relatively shallow way to grow. There's only a few that I think are really worth learning for the sake of personal growth:
- both C and C++
- Some form of lisp. I could see julia taking this spot.
- Haskell
- SQL
There are obviously more that are worth learning for industrial use. Learning the above will give a solid understanding of how every other language works though, even if there's different semantics for a particular language.
When I was really into learning new languages, I think it was because I didn't have a good sense of how to do more challenging things.
At some point, I settled down and got more into projects that really require more domain knowledge. Writing an external merge sort, interpreter & compiler, a gameboy emulator, a disk persisted b+tree, ray tracing & physically based rendering, etc.
Those types of problems are what really pushed my boundaries and made me think more about how to solve problems. In the case of ray tracing & pbr, it forced me to learn some calculus, linear algebra, and statistics, which has been an incredibly rewarding experience.
It can be fun to imagine what solving a problem looks like in a language, because it may have some qualities that play to the strengths of a solution. At the end of the day, the languages are just tools people have come up with. Learning the quirks of C++ becomes less fun when you start to realize that it is the way it is because of how history unfolded rather than because of some interesting concept.
I think it is impossible to make a list of programming languages that are worth learning.
Just as a comparison, would you also make such a list for normal languages? English, Arabic and Chinese?
Choosing a language to learn depends on, among many more aspects:
* What style do you prefer. Return codes vs exceptions, small lambdas vs elaborate functions...
* What paradigms you find useful (procedural, functional)
* how do you think, rather mathematical, more in a state/execution way or more like cooking (recipes),...
* what applications do you like? Frontend to a store, embedded/industrial, mission critical,...
* simply taste. I hate ruby and love python. For a lot of people it is the other way around.
* do you love optimizing? For what memory, speed?
* Do you prioritize or advocate readability, maintainability, re-use?
In the end you have to choose your battles, you can't master all paradigms and styles in one lifetime.
I think SQL is both the simplest to learn and most worthwhile in this aspect.
Why? Short answer - Because it doesn't have for loops.
It forces you to think about data in another way. It is like origami for programming. You can't brute force it, you have to fold your way to the result.
What would you say the value is in learning some sort of lisp? I see the value in all the others, but lisp dialects tend to be pretty vanilla aside from their syntax. I can't think of anything you'd learn from lisp that you wouldn't from Haskell.
Leaning new languages is great fun, but I do think it has diminishing returns when you have covered the major paradigms. The key to growth is to discover new "aspects" where you can broaden your experience, e.g. windows vs unix, desktop GUI versus web versus systems programming, low level vs high level, game programming vs line-of-business development, stand-alone apps vs large enterprise systems, green field versus legacy.
Knowing 27 languages but only having worked on say small green-field web apps is still a very limited experience.
I value learning new languages, especially as I have yet to find a very good one.
Some are pure and beautiful like Scheme, but if you asked me what single language I would take to a lonely island with me where I was stranded, it would still have to be C.
To those here who would like to have some guidance diving into other languages I can recommend these two books:
Other than the fact that C can be run on basically any device on earth, and the super rich history behind it, does C as a language have any benefits? I personally don’t find C more ergonomic, expressive or beautiful compared to any other language.
The first book is my all-time favorite programming book. I was disappointed by the second one, though. It didn't hold the same charm and wonder as the original.
TypeError: Cannot read properties of undefined (reading 'reduce')
at getTweets (/myapp/build/index.js:898:22)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at loader5 (/myapp/build/index.js:991:48)
at Object.callRouteLoader (/myapp/node_modules/@remix-run/server runtime/dist/data.js:77:14)
It's also really, really fun to use a language that's completely different than what you're used to.
I've learned Elixir, Scala, F#, and Common Lisp on the side in the past year or so. I like Elixir and CL to the point where they're typically my go-to for personal projects. I liked Scala and F# a lot but I don't reach for them so often; it'd be nice to work with them.
The worst part about learning (and liking!) new languages is that at work, we're pretty firmly in Go. IMO, while Go is nice from a minimalism and resource utilization standpoint, it's simply not fun to write after using much more expressive languages.
> IMO, while Go is nice from a minimalism and resource utilization standpoint, it's simply not fun to write after using much more expressive languages.
It's definitely a blessing and a curse. What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language. Speaking strictly from an expressivity and language semantics standpoint, as its runtime and standard toolset are simply great, it's just filled with so many head scratchers when you dig into what's going on and why.
Like the go modules import compatibility rules forcing you to create new vX versions of modules. It's not that it's unsound, it's just unlike everything else out there, and so you can't take your knowledge from other packages managers and apply them to Go. Maybe that expands the mind a bit, but in my experience it just confuses teams and forces them to sometimes go back and revert a major version bump because it's easier to just do that.
Elixir was the most pleasant experience I’ve had learning a new language. I really enjoy the ergonomics of pattern matching and the pipe operator. Really wish I had an opportunity to use it professionally.
I have used several languages professionally and written personal projects in about a dozen languages. But I'm not sure if it has helped me grow as a software engineer.
I'm mostly saying this because every company I worked for implemented similar antipatterns. It's like the human brain subconsciously leads people to make similar bad decisions regardless of the programming language.
On the other hand, learning different languages makes you more gritty. If you can troubleshoot code in half a dozen languages, chances are you can figure out the 7th.
I don't know why the comments are so negative. I agree that the fundamentals are important and that you can then learn almost any language, but OP might have a different learning process and getting the hands dirty might be helping him and honestly trying out a new language along with making your fundamentals clear does not hurt anyone.
Frankly the article reads like it’s an Instagram post that you’d find with #blessed on it or some other self-important nonsense. Which is fine if the target audience is juniors—look at all the cool stuff this guy is doing because he’s continuing his education. But then he gets the content of the message wrong, so to other seniors it’s kind of open season.
Agreed. Personally, the way I overcame my lack of a complete college education was through learning multiple languages. Researching the way different languages solved the same problems - and why - helped me understand the fundamentals, as I didn't have an algorithms or data structures course to lean on.
A single programming language, isn't always a "single language" across different code bases. Especially for languages like C and C++, there are many different approaches that different code bases use -- memory management strategies, all kinds of internal APIs, different control flow, etc.
Other languages might feel more like a "single language" because they are more domain-specific, and there are established basic libraries that are widely used, so moving from one code base to another is more fluid.
Wouldn’t it be more useful to your audience (juniors I assume) to say that “learning patterns in software design helped you grow as an engineer?” I mean you call out things like discovering DDD and I’m sure you also came across Data-oriented design as well, Patterns of enterprise architecture, etc. In my experience knowing those patterns provides far more value in one’s toolkit than “knowing” Kotlin, Ruby, Scala, Golang, Rust & C++.
Different languages provide different features and support these patterns in different ways. I think they’re complementary.
Not to mention that learning different languages can be quite valuable for one’s career, as it is another skill one can employ for practical purposes and for distinguishing oneself among peers.
> Because of some of my programming teachers, I had a feeling that JavaScript is not a “real” programming language. In addition, it was JavaScript in the frontend environment, so you know, moving divs and buttons around, not algorithms.
Well, it certainly does not live up to the standards of languages, which those people would call "real programming languages". So while they are doing a true scotchman thing there, there is also some truth at the core of it. If we remember JS how it was a decade or more ago, and what JS today still keeps downwards-compatibility with, it is easy to see, how the very foundations are flawed, to say the least. Self-respecting computer scientists, professors or not, will most likely not accept those shaky foundations as something worthy.
Anyway, it is not the pure count of programming languages, but rather the count of programming language families one got to know, that makes the difference. If all one ever touches are languages out of the algol family, then it will have far far less benefit, compared to trying out languages from various families. For example one will learn much more, trying out SQL, a lisp, an APL, Prolog and a Smalltalk dialect, a language with stytic typing and a langauge with dynamic typing, than from trying out Java, C++ and C# and the like.
This is because the various different families do things vastly differently and require you to switch your brain into different modes, while languages of the same family will mostly only make you learn a new syntax and new built-in function names.
Feels like the moment to mention 'Strange Code' - https://nostarch.com/strange-code by Ronald T. Kneusel (no relation or affiliation, I just like the book).
You're never going to build your next major project in one of them (unless you happen to be a COBOL developer or happen to maintain OpenFirmware boot code written in Forth) but seeing different ways of doing things is both interesting and instructive.
A lot of people seem to overdo it, but I'd recommend
- Some sort of assembly
- C
- Java/Kotlin/C#/similar
- Python
- Javascript
- Some Lisp flavor
- Possibly Erlang
- Possibly Rust
This covers a lot of layers of the stack, along with some unique paradigms. I'd use it somewhat seriously for a while (months to year), not just as a toy to learn a language in a week. For a toy, JS and Java are close enough that you might not appreciate that once you get past the syntax, they're radically different.
I think it's also very important to see (and easy to miss) that a language is just a part of bigger programming systems. Every problem domains with enough complexity will eventually grow into some sort of a domain specific programming system to provide flexibility and simplicity. Composition, abstraction and generalization are all important tools to tackle this problem and programming languages exist exactly for this reason.
Because general purpose language only solves a tip of iceberg, you will find out that your system begins to resemble more and more of a language as your system evolves. (Although it's usually best to avoid this situation IMHO, but if more than thousands of users depend on it then it's inevitable!) At this moment, some knowledge on language design and implementation could be helpful to avoid pitfalls and make the system more consistent and easy to the users even if it doesn't take a form of a textual language with its own unique syntax.
If I hadn't tried new languages, I would be stuck with assembler language forever. ;)
To this date I feel that using Python and SQL are amongst the best decisions in my developer life. Domain specific, without any helper libraries nor macros. Eye opener for using abstractions instead of doing everything the hard way using any low level languages.
What grew me the most as a programmer was doing the Advent of Code challenge every year using a different language each year (and doing 1 year with 3 languages each day). Learned so many new algorithms and languages I never would’ve otherwise encountered. Side note, Advent of Code 2022 starts December 1!
I agree that learning ML style languages has benefits, when I discovered the concept of "Option" the ideas behind pattern matching and functional programming made a lot more sense, especially when it comes to writing systems software.
But for some reason your comment reminds me of James Mickens quote from "USENIX: The Night Watch" article[1] "You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis"
"null-safe type" is a term which takes the perspective of backpedaling out of a mistake, which keeps highlighting the mistake. The mistake is unnecessary in the first place; types do not naturally have a null in them that has to be exorcised.
For instance, when we think of a type like "the natural numbers", that's just a set of 1, 2, 3, ... there is no "null reference to Integer" in there.
Thus I think terms like "null-safe type" is just something we should leave to Java programmers, and not use as a way to talk about types.
I’ve learned a handful of languages over the years, it was fairly straightforward to reason about all the c-likes (java, php, js, c#, etc), and others (python, tcl). They all have quirks and unique pros/cons, but it was mostly a matter of applying familiar ideas to a new environment/syntax.
But by a large margin nothing melted my brain more than learning a pure functional language (xquery, in my case). To have to think about programming in a completely different way was extremely beneficial. I highly recommend it, given the chance.
I love moving domains every so often because changing up tooling and languages is such a great learning experience. Here's a related piece I wrote talking about why I think learners should also be learning multiple programming languages: https://blog.boot.dev/education/learn-multiple-programming-l...
My job involves using multiple languages, our small team own packages that include java, kotlin, ruby, python, typescript. Everyone is expected to write in any language as needed.
We also conduct interview in any language a candidate would like to use.
I think if you try different enough programming languages it helps a lot... but what I found even more interesting is doing the same coding kata in those different languages.
Elixir vs Javascript vs Python vs Ruby... so much difference.
Here my thought: I would love a language that is simple as Lisp, compose via pipe all the way down, have elegant type like StandardML, that run on powerful concurrency engine like Erlang/OTP.
Without even reading the article, one hundred times yes. Exposure to different paradigms and concepts is more important to absorb than syntax in this endeavour, however.
the startup company i work in uses 6 different programming languages, which makes me feel what you argue here. to add, markup languages are fun and contrubiting also, particularly devops developing with yaml and composing Docker components makes you think in a different organizational mindset than other programming domains
For my personal case, I found out that writing "real programs" in anything else than assembly with a conservative usage of a macro processor is kind of toxic: it is a complex matter based on my experience and what I could understand from "software history".
A high level script language would be such "real program". Idem for a command shell.
risc-v, if successfull, will help a lot to this then remove a lot of what I consider toxic.
Are you actually saying all programs should be written in a macro assembly language? Tied to only one hardware platform, with high level concepts completely obfuscated by the need to express them in assembly? So when MS wants to make an ARM version of Windows, rewrite! When Apple switched from 68k to Power to x86/x64 to ARM, rewrite! Port the Linux kernel to a new platform, rewrite! Port the unix utilities to a new platform, rewrite! Any application writer wanting to port their program from one hardware system to another, rewrite!
That would be an awful world to live in, though more people would be employed. Less would actually get done, though.
Why do you think so? I assume that writing the same piece of code in assembly would take more than twice as long (conservative estimate) if you do the same in high level languages without much benefit. Can you elaborate your opinion a bit more as I am curious. I have been wanting to get into learning assembly but just cant seem to do it as high level languages are so easy to code in and want to know if anyone really uses assembly nowadays.
lordnacho|3 years ago
From having built trading systems in c++, I ended up building, over about a year or so:
- A django (python / js) website. It integrated with both Android (java) and iOS (objective-C) apps that could read QR codes and ask the server stuff. It also made me interact with the app stores for the first time. It was also the first time I did anything on the web, including figuring out how pages are laid out. Bought a MacBook for the first time too.
- A consumer iOS app written in Swift. New language again. Went native, ran into a lot of constraint errors that eventually taught me a lot.
- A trading system in c++ that didn't use STL.
I remember at the beginning of each new language/framework thinking "OMG how do I do this". And yet it's not that bad once you've done it once or twice. I reckon it's a lot easier than learning a new natural language (German, Mandarin).
The thing it really gives you is a low opportunity cost. If you have some task, and the evidence points towards some specific framework/language being a good choice, hopefully you won't resist it due to internal anxiety about starting over again.
otachack|3 years ago
mettamage|3 years ago
synthc|3 years ago
Some things that are taken as best practices are bad practices in other langauges and vice versa.
For example, lots of Java devs are against early and multiple returns to the point of absurdity, while in functional languages this is idiomatic and no problem at all.
Using different languages lets you see how different approaches work out in practice, so you can get a better view about which approaches work and which approaches are just cargo-cult nonsense.
rantingdemon|3 years ago
That aside. Your point around ecosystems is interesting to me. As a wannabee coder I'm always trying new things. Most of my code was in PowerShell although I did do a bit of C++ and Delphi in school.
I have been dabbling with dotnet core (C#) and Python the last couple of years.
I tried to get into Java a bit, but to be frank the learning curve to go from start to consuming a REST service was just way too hard. I couldn't understand the difference between when I should be using JavaEE, JavaSE, spring boot, spring framework etc. I gave up after two days.
In contrast Python is just so easy. And if I want something more robust I'll rather go to dotnet.
Go is on my list as it seems to offer a lot of what I want, and although there are some apparently weird things in it I think i can be productive with it for some basic business logic within a couple of days.
BlargMcLarg|3 years ago
We see this in C#. Has a ridiculous amount of features outside default OOP and continues to get more baseline, even has great interop with several other languages. But culture changes very, very slowly. Large scale adoption tends to happen only when some major framework insists on using a certain paradigm.
eweise|3 years ago
Which functional language are you talking about? Of the two functional languages I know, Elm can only have a single return statement. Scala encourages a single return.
iudqnolq|3 years ago
I initially fell in love with the Rust convention of simply bubbling up errors throughout a function but I've gradually realized that leads to a poor API. [1]
I'm currently learning c++ for a personal project. I want to use a library with an API that's sufficiently templated it'll be easier to write a c++ shim than directly generating bindings. So far I'm at the stage where I'm constantly thinking Rust does things better. Hopefully later on I'll realize why the different tradeoffs c++ makes make sense. (One example would be how generic code is typechecked).
[1]: If you want to be able to simply propagate up errors with the `?` operator you need to implement automatic conversations from your dependencies' errors to your error type. But that means your API will have a single error type for every dependency error type - say MyError::Io(io::Error) - which is the wrong level of specificity. I now think you should either expose only a string message your user can just show their end user or an error that's much more specific so they can write code that intelligently responds to it. Something like MyError::ReadConfigFailed(io::Error)
sendomatic|3 years ago
tester756|3 years ago
Learn concepts, obtain foundational computer science knowledge, write complex projects
not just get familiar with somebody's interpretations that they implemented as a language.
Languages that I used besides my job language barely gave me anything, in most cases they made me appreciate more for sane environment (package managers, IDEs, debuggers, strong standard library)
edit. just to be clear:
I don't see value in learning C#+Java+PHP, but C#+Erlang? yea
I do see value in learning Rust after C
but still - concepts are more important, you don't have to learn langs in order to be familiar with concepts
Learn software engineering - it's broad as hell and you can easily do that using one language
barrkel|3 years ago
It's hard to write a declarative querying library in C. SQL is not an ideal language, but as a way of expressing intent rather than a physical query plan, it's a long way away from C.
It's hard to appreciate the power of interactive debugger REPLs like binding.pry or JS's debugger without experiencing them. A C++ debugger, even a Java debugger, is a pale imitation, and it's not easy to simulate the experience without building a dynamic language inside the static language.
If all you've ever known is statically typed languages, you can suffer from a myopic parochialism with respect to dynamic typing. IMO the most popular statically typed languages only work well because they have runtime polymorphism holes in their type systems. More powerful statically typed programming languages tend to grow ever more esoteric typing constructs to enable static types to follow dynamic control and data flow - there's an inherent tension there and if language complexity isn't carefully managed, it becomes harder to express intent and error messages get more vague and cryptic.
Algebraic data types and pattern matching tends to be under-appreciated if one is schooled in object-oriented languages. Object orientation has a big hammer for switching control flow based on data values, dynamic dispatch, and architectures tend to leverage dynamic dispatch where they would be much better off with switch statements. If the set of variants is known up front, you're probably much better off with sum types and pattern matching than with interfaces, abstract classes and virtual methods.
larve|3 years ago
I have a few reasons to work in (not just learn) close languages. The languages might use roughly similar concepts and syntax and solve similar problems (think, C++, C#, PHP, Java, Go), yet their community, practices, tooling, frameworks are wildly different.
If as a C++ developer in 2005 you never experienced how smooth debugging and profiling could be in Java, how fast things could compile, how easy it was to drop a jar and deploy to your server farm, you were missing out.
Similarly, if as a Go developer you don’t know how quickly you can install WordPress, write a 200 line PHP plugin, and get an entire business off the ground, you are missing out.
Most transformational for me was to be a Common Lisp developer, and find the language that allowed the ideas and concepts in my brain to be turned into prototype at the speed of thought. It’s a challenging language to use in the real world, but it really brought the point home that a language is just a vessel for ideas.
chrisseaton|3 years ago
Well yeah learning a wide variety of languages is a good way to do that. People write new languages because they want to implement new concepts.
deltasevennine|3 years ago
You kinda do. Concepts are often exclusive to languages. And often concepts can't be internalized without practice of that lang.
Your own examples in your edit literally contradict what you say as you chose langs with extremely divergent concepts. C# and Erlang, Rust and C. You missed haskell and lisp.
wildrhythms|3 years ago
sandreas|3 years ago
[1]: https://pilabor.com/blog/2021/05/learn-concepts-not-framewor...
Aperocky|3 years ago
Syzygies|3 years ago
Charlie Watts wasn't just into jazz, he was into all music. George Harrison understood that jazz could deepen him as a musician, but found Indian music.
If one wants to write a language that is truly original, that might actually influence the future, not just smearing around familiar weightings for features found useful "in the trades", then one wants to have some grasp of languages representative of every language in use. Then, only proceed with a compelling vision of what's missing.
For the rest of us, being a language junkie can be a problem. Without being judgmental, it is possible for a person to be too promiscuous. Same with languages. I wish I could just stick to Haskell and get work done.
FpUser|3 years ago
Languages for me are just tools, like screwdrivers. I use / used many and do not get hung up. And no I do not learn languages just for the fuck of it. Only if I see some positive ROI.
xigoi|3 years ago
eric4smith|3 years ago
Not hobby level, but client work level.
They did not really help me to become a better software engineer.
What did?
Being able to understand the business of the customer and create software that helped them do that easier.
That’s why today I tell junior programmers that almost everything we do these days could be accomplished with Bash, text files to hold the data and static html files.
Don’t focus on the language, focus on the business case.
Sure some languages are more efficient than others but all those do is help you build a solution faster. And languages are similar for the most part - so that helps you learn new languages faster.
jacknews|3 years ago
I don't consider that software 'engineering' necessarily.
Yes to be a more useful employee or more successful freelancer etc understanding the business case is absolutely an essential skill. But the 'engineering' begins once the problem has been defined; how do you actually implement the vision.
sicp-enjoyer|3 years ago
deltasevennine|3 years ago
You need to learn languages outside of this family to see the benefit. But the benefit won't be in your ability to do "business". It will be exclusively improvements in programming unrelated to "business programming"
>That’s why today I tell junior programmers that almost everything we do these days could be accomplished with Bash, text files to hold the data and static html files.
Why? Junior programmers are aware of this already. And get this: junior programmers are even aware that everything can be accomplished with assembly language. They are also aware why things aren't done in assembly, typically.
chrsig|3 years ago
- both C and C++
- Some form of lisp. I could see julia taking this spot.
- Haskell
- SQL
There are obviously more that are worth learning for industrial use. Learning the above will give a solid understanding of how every other language works though, even if there's different semantics for a particular language.
When I was really into learning new languages, I think it was because I didn't have a good sense of how to do more challenging things.
At some point, I settled down and got more into projects that really require more domain knowledge. Writing an external merge sort, interpreter & compiler, a gameboy emulator, a disk persisted b+tree, ray tracing & physically based rendering, etc.
Those types of problems are what really pushed my boundaries and made me think more about how to solve problems. In the case of ray tracing & pbr, it forced me to learn some calculus, linear algebra, and statistics, which has been an incredibly rewarding experience.
It can be fun to imagine what solving a problem looks like in a language, because it may have some qualities that play to the strengths of a solution. At the end of the day, the languages are just tools people have come up with. Learning the quirks of C++ becomes less fun when you start to realize that it is the way it is because of how history unfolded rather than because of some interesting concept.
(edit: hn list formatting)
nuancebydefault|3 years ago
Choosing a language to learn depends on, among many more aspects:
* What style do you prefer. Return codes vs exceptions, small lambdas vs elaborate functions...
* What paradigms you find useful (procedural, functional)
* how do you think, rather mathematical, more in a state/execution way or more like cooking (recipes),...
* what applications do you like? Frontend to a store, embedded/industrial, mission critical,...
* simply taste. I hate ruby and love python. For a lot of people it is the other way around.
* do you love optimizing? For what memory, speed?
* Do you prioritize or advocate readability, maintainability, re-use?
In the end you have to choose your battles, you can't master all paradigms and styles in one lifetime.
fifilura|3 years ago
Why? Short answer - Because it doesn't have for loops.
It forces you to think about data in another way. It is like origami for programming. You can't brute force it, you have to fold your way to the result.
tomtheelder|3 years ago
goto11|3 years ago
Knowing 27 languages but only having worked on say small green-field web apps is still a very limited experience.
jll29|3 years ago
To those here who would like to have some guidance diving into other languages I can recommend these two books:
Bruce Tate: Seven Languages in Seven Weeks https://www.amazon.com/Seven-Languages-Weeks-Programming-Pro...
Bruce Tate: Seven More Languages in Seven Weeks https://www.amazon.com/Seven-More-Languages-Weeks-Shaping/dp...
You can work through them in <4 months, and then we can talk again whether you found it useful (I did).
tonmoy|3 years ago
Stamp01|3 years ago
tender_euler|3 years ago
LudwigNagasena|3 years ago
tender_euler|3 years ago
baransu|3 years ago
filippofinke|3 years ago
mikedelago|3 years ago
I've learned Elixir, Scala, F#, and Common Lisp on the side in the past year or so. I like Elixir and CL to the point where they're typically my go-to for personal projects. I liked Scala and F# a lot but I don't reach for them so often; it'd be nice to work with them.
The worst part about learning (and liking!) new languages is that at work, we're pretty firmly in Go. IMO, while Go is nice from a minimalism and resource utilization standpoint, it's simply not fun to write after using much more expressive languages.
phillipcarter|3 years ago
It's definitely a blessing and a curse. What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language. Speaking strictly from an expressivity and language semantics standpoint, as its runtime and standard toolset are simply great, it's just filled with so many head scratchers when you dig into what's going on and why.
Like the go modules import compatibility rules forcing you to create new vX versions of modules. It's not that it's unsound, it's just unlike everything else out there, and so you can't take your knowledge from other packages managers and apply them to Go. Maybe that expands the mind a bit, but in my experience it just confuses teams and forces them to sometimes go back and revert a major version bump because it's easier to just do that.
wefarrell|3 years ago
mkl95|3 years ago
I'm mostly saying this because every company I worked for implemented similar antipatterns. It's like the human brain subconsciously leads people to make similar bad decisions regardless of the programming language.
On the other hand, learning different languages makes you more gritty. If you can troubleshoot code in half a dozen languages, chances are you can figure out the 7th.
stoicjumbotron|3 years ago
raydiatian|3 years ago
z3c0|3 years ago
300bps|3 years ago
In the last few years I’ve interviewed over 100 graduating Computer Science students from very good schools.
One of the questions I asked was, “Did you learn your first programming language as part of your college curriculum or before?”
Almost all of them answered they learned their first programming language in college.
I can’t even fathom it. I learned BASIC when I was 10. Logo when I was 12. Assembly when I was 13. C when I was 16 and C++ when I was 17.
This was a long time ago of course - I can’t believe how much things have changed with a population self-selected for being interested in computers.
jeff-davis|3 years ago
Other languages might feel more like a "single language" because they are more domain-specific, and there are established basic libraries that are widely used, so moving from one code base to another is more fluid.
rlv-dan|3 years ago
raydiatian|3 years ago
sidlls|3 years ago
Not to mention that learning different languages can be quite valuable for one’s career, as it is another skill one can employ for practical purposes and for distinguishing oneself among peers.
dopidopHN|3 years ago
For instance using more functional language convinced me of the vertus of immutability.
Pattern won’t do that
zffr|3 years ago
zelphirkalt|3 years ago
Well, it certainly does not live up to the standards of languages, which those people would call "real programming languages". So while they are doing a true scotchman thing there, there is also some truth at the core of it. If we remember JS how it was a decade or more ago, and what JS today still keeps downwards-compatibility with, it is easy to see, how the very foundations are flawed, to say the least. Self-respecting computer scientists, professors or not, will most likely not accept those shaky foundations as something worthy.
Anyway, it is not the pure count of programming languages, but rather the count of programming language families one got to know, that makes the difference. If all one ever touches are languages out of the algol family, then it will have far far less benefit, compared to trying out languages from various families. For example one will learn much more, trying out SQL, a lisp, an APL, Prolog and a Smalltalk dialect, a language with stytic typing and a langauge with dynamic typing, than from trying out Java, C++ and C# and the like.
This is because the various different families do things vastly differently and require you to switch your brain into different modes, while languages of the same family will mostly only make you learn a new syntax and new built-in function names.
zahllos|3 years ago
You're never going to build your next major project in one of them (unless you happen to be a COBOL developer or happen to maintain OpenFirmware boot code written in Forth) but seeing different ways of doing things is both interesting and instructive.
dehrmann|3 years ago
- Some sort of assembly
- C
- Java/Kotlin/C#/similar
- Python
- Javascript
- Some Lisp flavor
- Possibly Erlang
- Possibly Rust
This covers a lot of layers of the stack, along with some unique paradigms. I'd use it somewhat seriously for a while (months to year), not just as a toy to learn a language in a week. For a toy, JS and Java are close enough that you might not appreciate that once you get past the syntax, they're radically different.
agumonkey|3 years ago
summerlight|3 years ago
Because general purpose language only solves a tip of iceberg, you will find out that your system begins to resemble more and more of a language as your system evolves. (Although it's usually best to avoid this situation IMHO, but if more than thousands of users depend on it then it's inevitable!) At this moment, some knowledge on language design and implementation could be helpful to avoid pitfalls and make the system more consistent and easy to the users even if it doesn't take a form of a textual language with its own unique syntax.
_the_inflator|3 years ago
To this date I feel that using Python and SQL are amongst the best decisions in my developer life. Domain specific, without any helper libraries nor macros. Eye opener for using abstractions instead of doing everything the hard way using any low level languages.
wycy|3 years ago
dejj|3 years ago
- Pony’s lifetimes and destructive reading [1]
- Mercury’s overloading of dataflow direction and determinism [2]
were mentioned in [3].
[1]https://tutorial.ponylang.io/reference-capabilities/consume-...
[2]https://www.mercurylang.org/information/doc-latest/mercury_r...
[3]https://news.ycombinator.com/item?id=33102582
throwaway234239|3 years ago
When you don't learn elementary type-safety, you create languages like Java and Go which are plagued with NullPointerException's and nil panics.
So please, learn an ML (and a Lisp).
jumperjumper|3 years ago
[1]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf
kazinator|3 years ago
For instance, when we think of a type like "the natural numbers", that's just a set of 1, 2, 3, ... there is no "null reference to Integer" in there.
Thus I think terms like "null-safe type" is just something we should leave to Java programmers, and not use as a way to talk about types.
epalm|3 years ago
But by a large margin nothing melted my brain more than learning a pure functional language (xquery, in my case). To have to think about programming in a completely different way was extremely beneficial. I highly recommend it, given the chance.
lanecwagner|3 years ago
bern4444|3 years ago
I became interested in F# and found a F# to JS compiler.
I can write F# code and call it from JS and do it in any toy code or side project I have.
This lets me lift up any JS or TS to F# to any degree I want across any project.
That's an awesome environment to build in as I can experiment and learn more about the language just by rewriting code that is already figured out.
Tozen|3 years ago
At the very least, nothing wrong with being a bit more open-minded.
Aperocky|3 years ago
My job involves using multiple languages, our small team own packages that include java, kotlin, ruby, python, typescript. Everyone is expected to write in any language as needed.
We also conduct interview in any language a candidate would like to use.
xutopia|3 years ago
Elixir vs Javascript vs Python vs Ruby... so much difference.
aatd86|3 years ago
Existenceblinks|3 years ago
lucasyvas|3 years ago
metaph6|3 years ago
justshowpost|3 years ago
> For me, JavaScript became my primary language and stays
Oh, my God! Computer science of leftPad.js strikes back.
ftyhbhyjnjk|3 years ago
48cfu|3 years ago
[deleted]
sylware|3 years ago
A high level script language would be such "real program". Idem for a command shell.
risc-v, if successfull, will help a lot to this then remove a lot of what I consider toxic.
Jtsummers|3 years ago
That would be an awful world to live in, though more people would be employed. Less would actually get done, though.
cnt-dracula|3 years ago