I would think that the specifics of the new language would (greatly) influence the difficulty. If the languages (known vs. new) are similar, it's typographical more than anything else. How to make a code block, end statements, indicate arrays and pointers, etc. There's a vocabulary to pick up, but it should be like learning a new similar romance language when you're fluent in another.
However, if the language paradigm is different, such as vector vs. scalar or other significant differences then developers can end up wrestling the language rather than working with in. I would suspect, as it was in my case, that the more experience one has, the worse this conflict will be. I had a way of approaching and implementing code that was just not what the language wanted to see. It was rather frustrating falling into the write/tune rather than write-then-tune process. My only "solution" was to first write things the way I had internalized and then revise them into the appropriate form(s) for the new language.
Once this was done, and I would say it was a 3-6 month process, then the "normal" learning process started. Syntax, grammar and vocabulary is an ongoing process but it's easier as language familiarity grew.
I've been programming for 54 years. Languages come and go in a career. For me, each new language was an enthralling experience, an adventure. Mostly I think this was because each new language came with some valuable new insight in how to do my work. I don't know if that is true any more. I get the impression that there are too many new languages and paradigms. I suspect this is a confusing burden that detracts from the enjoyment. There doesn't seem to be a clear evolutionary path anymore. I imagine this weighs on a programmer's mind.
54 years. I can just match that if I count the very first time I wrote a line of code!
I agree with all you say and my experience was the same.
I think the current problem you describe is a disconnect between the means and the end. We lived through times when the end result was all anyone cared about. Now people have jobs where they don't really know what the end result is.
41-42 years here. My experience was right from the beginning in designing new products so for me programming languages were just tools. After a while it was not a problem for me to start a project in completely new language and get the shit done without much fuzz. Most of the general-purpose languages are more or less the same and so are the libraries. Some are great. Some are not that much.
What I see now is that programmers are often concerned with not what they deliver but how – I’ll do anything as long as it is in A/B/C. Basically means substitute goals. I find it not very healthy.
There are some exotic languages of course which could make my brain melt but since I do not need any for my projects/products I would not care.
I agree with what you say. I am a small number of years behind you professionally, and yes some come and go and a couple of languages I learned no longer exists.
But I could never grok OO, but at least in my case that is not an issue, especially these days :)
Back then, learning new languages was a non-issue, it was the logic you had to understand.
Most languages are not very different as far as the semantics go. The Algol family, for example (Pascal, C, C#, Java, Lua, Python, …) - if you know any of them well, it’s easy to pick the others up quickly.
But a language includes idioms, the eco system, and even conventions like camelCase vs PascalCase vs snake_case. Until you master these, all code you write will be alien and awkward to the natives.
C++ has become its own thing, where you have to study an awful lot just to be able to _read_ it, but it is otherwise of the same family.
I’ve only been programming for 40 years, have professionally done so in over 10 languages, and nowadays preach to only pay attention to paradigms rather than languages.
You don’t think differently when working in C# vs Java, and not materially different than e.g. C, if you are writing idiomatic code.
But Lisp, APL, Prolog, Haskell - idiomatic code in any of these languages does not resemble one in any of the others (or the Algols) - they each offer a very different way to look at things. And your C code will be Better if you grok them, even if you don’t use them.
Yes! This idea that every language learnt brings something to your programming is not really true imo, or at least barely true for many languages. You learn little picking up C# after Java, but a tonne learning Haskell after Java. Paradigm matters, syntax and conventions not so much.
For a lot of its lifetime C# has been ahead of Java, though I think as C# has matured Java has probably caught up so it may be true now.
But C# introduced e.g. runtime generics, functional style LINQ, async and also RX style programming first, though RX is not part of the language but the ecosystem.
Underlying issue to this is the "best practices" mentality.
It's an unnecessary burden to look after "the best tool for the job". In order to know "the best", you have to know all tools deeply enough to judge which is the best.
Should be able to judge whether the tools I currently have are suitable for the problem or not. If not, should be able to search efficiently for one that suits and to learn it to the degree needed.
Finding the right balance of judging, searching and learning can be a joyful adventure.
Constant questioning "is it the best" is a nightmare...
Anecdotal, but I've been learning a lot of different languages over the years, the language itself is probably less than half what makes it difficult to learn. The real difficulty comes when there's no good resource to learn the language, a poorly documented ecosystem, and a lack of good libraries (and worse, a bad standard library).
For example, languages like Rust are complex and hard to learn, yet many people get into Rust because it's easy to setup (rustup), easy to run or test (cargo, vscode), easy to compose (crates, stdlib), and easy to learn (so many online resources).
On the other hand I've been learning OCaml and suffering. I would advise anyone who wants to have real world impact in a low-level language to give a shot to OCaml, because there are just soooo many ways to influence the language. If you write a library it will be used, there's so many opportunities for creating learning resources or improving the tooling, it's uncharted territory for the most part and it's probably the functional language that has the most chance of having a real-world story.
> yet many people get into Rust because it's easy to setup (rustup), easy to run or test (cargo, vscode), easy to compose (crates, stdlib), and easy to learn (so many online resources).
All those things apply to Python too (not that I've learned Python ;-) There must be more than just these reasons why people learn Rust instead of Python.
More people would be getting in to Python every day than Rust. Python is what the universities teach now so you have thousands trying python for the first time probably daily.
Are there more people learning Rust than Python? I still felt like Python was sort of an ubiquitous language, a shared scripting language at the very least.
I'd say Python lacks a good out-of-the-box experience compared to Rust. You can't really use Python like Rust without figuring out how to install a project's dependencies, how to manage different versions of Python (which is even more of a nightmare if Python comes pre-installed with your OS), and Python's documentation kind-of-sucks in comparison to languages like Golang and Rust I find.
> Because of how batteries-included Python is, you absolutely can, because you can use it quite a bit without any dependencies outside of stdlib.
I'm not talking about stdlib. If we're talking about stdlib then Golang is the gold standard :) I'm talking about using other projects. If they use a requirements.txt and pip maybe you'll have some luck, that is if you're using the same version of python/pip.
> I find Python's documentation to be far and away the best of any language I have encountered, and that definitely includes Go and Rust.
I'd say everyone should make their own opinion on the subject:
For having written a lot of these three languages, I find python's doc an ordeal to go through. But if you're comparing Python to C, C++, and other languages like that then sure it's great :D
I mean look at Golang's. List of all the methods on the left, examples for each method.
I definitely prefer Rust's documentation to Python's, but while string is a useful example because there's a lot to talk about, it's also a problem because e.g. that Rust documentation is for a type named String, while the Python and Go documentation is about libraries of string processing functions.
So the fact Rust's String is specifically UTF-8 text is highlighted, because the documentation is about the type, presumably (modern) Python and Go also have UTF-8 strings, but that's not the context of the doc links so that's not what they're talking about.
On the other hand, some features you might expect from a string type are (at first glance) missing from Rust's String, because they're implemented on str and so you get them for free because String is Deref<Target = str>
This is also a problem looking at say, Java documentation, if you don't know that all the classes (but alas not the primitives) are sub-classes of Object then you've no reason to assume Object's methods work on them.
Documentation has to be pitched correctly and if you're the wrong audience you will struggle to make use of it. Presumably expert C++ programmers have no problem with this sort of mess:
Contrast Rust with JavaScript. It is so very easy to get started with. Then come compilers and transpilers, different ways of importing, bundling, packaging, and consuming, all the ways those things mix and interact, myriad "magic" hacks your dependencies are doing behind the scenes to monkey-patch the environment, global APIs, and even other dependencies. It's like building on top of a pile of rubble, piled over more layers of rubble, riddled every which way with critical electrical and water lines. It can be an unmitigated hellscape.
Just the other day I was working out a Java numerical-operation logic error and decided to type it out in a simple online Python shell. Unfortunately, I had forgotten that the ints and doubles I was working with in Java didn't exist the same way in python. And then I spent a few minutes trying to remember how to import the math module...
Suffice it to say that I have been away from Python too long, now it's like learning a new language all over again.
And why not? It's not even cheating in my book - if I can understand the process well enough to write a program for it, then I shouldn't have to do tedious and repetitive work.
One time, the teacher was giving out a piece of candy for every Pythagorean triple that we could name. A little brute-force program written in a couple of minutes had me with a small handful, and eventually a ban from participating :)
I'm not sure if it is "difficult," I've always found it pretty straightforward. Sure, there will be differences, like types in Python vs. say Go, but we learn to switch context pretty comfortably over time (like we switch from English to say Spanish and back). I think the bigger challenge is to write idiomatically: e.g., if you're coming from Java, your Python code may not be "Pythonic" and a class-for-everything mindset won't quite work in Go.
The language is rarely a hurdle. The (almost always bad and broken) tools, the (often misleading, as far as best-practices go, or muddled with old versions and outdated advice) documentation, and learning the culture and ecosystem ("Oh no, no-one uses that built in function since it's bad for reasons X and Y, use this 3rd party FOSS library entirely supported by one guy living in a cabin in Wyoming instead") are what make it difficult.
The language itself is often no trouble at all. It's all the stuff around it that ends up eating shitloads of time.
Kotlin is great! I enjoy it a lot and am having a fun time ramping up for my new role. But the entire Java ecosystem is a dumpster fire, and I abhor Gradle/Maven/Intellij.
It would take me an entire weekend to try to configure Sublime Text or another lightweight plain-text editor to work with Gradle to even build the project, let alone any language server features like code suggestions and debugging.
I hate IntelliJ too. I don’t like any IDE for that matter. Emacs is muscle memory and nothing can emulate how it works properly. Emacs is so much more than it’s keybinding, yet that’s the only thing IDE/text editors attempt to emulate—and they never even get that right.
Emacs was originally designed to work perfectly well with type-ahead over 300 baud modems and slow ARPANET connections, so it doesn't fuck you when you type ahead, while so many IDEs love to pop up menus that gobble and drop keystrokes and then insert random crap you didn't want (like fuzzy matched symbols and multi-line boilerplate) unless you stop typing and patiently wait for it to finish thrashing the disk and painting the screen with animated menus, and then after it finally comes to a complete stop, you have to focus your attention on the screen and visually scan through the menu and hit the arrow keys repeatedly to re-select what you already typed, or hit escape to get rid of the menu and finish typing what you really meant (while slowly popping up even more menus with pointless animation every few keystrokes). And of course escape does something completely different if there isn't already a menu popped up, usually quite disruptive, so don't ever type ahead any escapes!
IDEs should not punish you for knowing what you want to say and typing it quickly. They should be DETERMINISTIC, and you should get the EXACT same results no matter how many milliseconds of delay you wait between each keystroke, and you should always be able to insert something by typing it literally at any speed, without pausing and waiting then focusing your visual attention on the screen and then finally pressing other buttons to use the menus.
Example: It took me two hours today to figure out why “Format on Save” wasn’t working.
Turns out, Intellij’s “Actions on Save” are only triggered when a “Save All” (option-command-s) is issued, and ignores any other type of save like good-ole command-s.
It is weaker IDE in terms of what it does. Eclipse is older, look uglier and strictly superior unless you work on some kind of super large project where it is breaking.
Over the years the performance has decreased... exponentially. It is pure craziness that indexing a project takes almost a minute or even more. It's full of env bugs and configuration issues that the developer team seems to not care about. Features > Usability from the marketing point of view :P
Nowadays, given the state of LSP implementations and editors being as flexible as VSCode i.e it's hard to justify the need for an IDE... In general.
I usually use nvim or VSCode (if I collaborate with someone) for other languages. Every time I have to work on a Java project, and I have to open IntelliJ... I know it's going to be a nightmare.
In terms of a culture of over-engineering, yes, it is second to none. In Java land, even a logging library can be a serious security vulnerability. A typical Java project pulls in half the internet for dependencies, including multiple logging libraries.
Java is therefore somewhat a victim of its own success. There is no absolute "best" as you seem to suggest. Every ecosystem has pros and cons.
I've done years of Java dev at many large corporates, so there's no uncertainty. Plenty of fear and doubt though. The language is getting much better, let's hope the ecosystem does too.
Any language at a large corporation (without proper software engineering practices) would end up that way. My current employer uses golang, and you wouldn't believe the @)%(* they came up with. Such as an entire framework that spits out 80+ line stack traces for errors and panics.
A good programmer uses the right language for the task. A good language is one that doesn't need a community and a beast of an editor just to code something that compiles and runs.
An "ecosystem" is usually a sign of costly entropy.
> A good programmer uses the right language for the task.
Agreed!
> A good language is one that doesn't need a community and a beast of an editor just to code something that compiles and runs.
Hmm. [citation needed]. I'd argue the exact opposite. A robust ecosystem and community around a language are a substantial part of its value proposition. Naturally, the language's PL details are what seed and fuel its ecosystem, so I'm not claiming semantics, syntax, and zeitgeist are irrelevant.
See every "worse is better language": C, Python, Java, Javascript, English against whatever ML, Haskell, Esperanto, Lojban, etc.
I think the parent was referring to the fact that e.g Java really needs an IDE, so one can generate all the boilerplate. In Haskell, I can e.g create a new type (with equality, hashing etc) in one line. Of course, a capable IDE would be extremely useful for Haskell and there are efforts to build such a thing with refactoring and navigation/search tools, but the language isn't unusable without one.
Yes, this is what is meant by the expression, "IDE Smell".
It's a measure of a language's usability if a programmer can't use the simplest possible tools to be productive.
Education and documentation is necessary. But if you have to have an entire support channel for a technology, it isn't necessarily a positive reflection on the technology.
You're absolutely right but most developers will also have a hard time moving between language families. For example a self-taught developer may have gone though javascript, python, java, go, and swift... but then get punched in the face by Lisp or Haskell.
The reason I single out self-taught developers is that many CS paths will push though a broad degree of language, or at least interpreters and compilers, such that its less of a hill to climb.
I am a self-taught developer with this problem. But I still enjoy diving head first into new languages. It just takes awhile.
I’m self taught, have written some compilers, and have written Haskell in production. I’ve also done the better half of SICP so a bit of Lisp there too. The only way to learn a new family of languages is by writing code - I’ve not found any prior knowledge that’s really helped me go from Python to Haskell or whatever, except the general skill of writing software.
I taught myself java, go, and Scheme. Functional programming is still pretty popular among autodidacts last time I checked, mare than in formal environments I'd argue.
In my experience, people who were taught programming in uni are the ones who know fewer languages. I suspect it's due to the amount of money Microsoft put (still puts?) into making sure that C# is popular in that space. I studied maths, but informatics was in the same department and there was a lot of stuff funded by Microsoft and everyone around was programming in C#. Another popular university nearby produced mostly Java devs, judging from the people I got to know on the job coming from there. My university also had some courses with Smalltalk, OCaml etc., but these courses were not obligatory, and more geared towards people who are actively interested in programming languages.
Self-taught programmers on the other hand more often have the intrinsic curiosity and motivation to learn those topics. Also diving deep into topics is their strength, since the uni counterparts often know the names of concepts, but after a while it's quite clear that this knowledge of names is rarely coupled with familiarity with the topics they represent. I'm sure just knowing the names of things gets you far when you want to pass an exam, but for actual work it's scarcely different from knowing nothing at all. As Feynman said, there's a big difference between knowing the name of something and knowing something.
Now, those are just generalizations from experience. I've also met plenty of counterexamples in both groups.
I agree with that. I think this made me enjoy a lot learning Pharo, and admire the Smalltalk-way of doing thigs, as there's a culture of great care with the environment around the language. The tooling is a integral part of language, not just an afterthought.
I just learned a new programming language yesterday in an hour: Svelte. It's just a tiny superset of JS/HTML/CSS, but I learned it and have already produced working web application faster than with Vue / React, and it's a perfect hobby language for me to play with, and a perfect example of why new languages can still give something extra in return. I just link to the tutorial, because it's so well done:
Interesting. I don't think I've ever considered Svelte a "language" in the sense it's being used in this article. More like a compiler or maybe framework written in Typescript, which is a superset of JavaScript. I only say this because I'm not sure I'd experience the same cross-language interference with syntax and semantics described here. Not an expert, but isn't it just compiled HTML/CSS/JS with some custom components and templates?
Sure, of course there's much less change, but it's a very deliberate choice of the developer. It was much harder to keep the changes minimal than to write a new much more complex language (like Elm). Coffeescript was a similar great improvement JS that felt so natural that ES6 took a lot of the great parts of it.
C++ is treated as a separate language from C, but it just started as C with objects.
I think a lot of programmers these days just get too sucked into the tooling for their specific language. This is of course especially bad in JavaScript land.
I’ve met many JavaScript programmers who are just good at gluing together various JavaScript libraries, but aren’t really proficient generally.
For example: you might be really good with redux, which is its own confusing stringy disaster, but not really understand the fundamentals that make it function.
It makes me happy to find out that colleges mostly teach python now, although I don’t agree with the MO now being that everything lives in a venv. In my opinion, open up IDLE and get to work. Virtual environments just add another level of confusion!
GO, and C, and also JavaScript are all great too of course and I use most them in a given week. I think if you focus on programming, and look at tooling as just extra convenience, then you won’t have problems learning new languages.
- It has the complexity/expressiveness balance correct, it's not the 'point a warhead at your head' of C++, neither is it the primitive belt-and-braces approach of C.
- It has a relaxed memory-allocation model with ARC that I very rarely have to worry about, and when I do, it's fairly obvious what to do. Generally just call [object-class new] and forget about it.
- It's binary compatible with C and C++, so if I really need the speed of either of those two, I just drop into them instead for the small amount of code I need, or use a library.
- It's named-parameters to methods make it easy to understand what a method in a class will do - though it's sometimes carried to extremes I agree.
- It has a really nice standard library that comes with it, and the framework/bundle idea makes packaging things up really easy
- In the debugger, I can always call a long stream of nested method-calls and get back the expected result, because message-calls are not function-calls.
- No dependencies are needed for any produced code (well, you need the system frameworks, but that's like saying libc.so is a dependency). You don't have to worry about whether you have PHP v5,6,7,... or Python 2.x vs 3.x. Just run the app.
All that for some [...] syntax. Except that a lot of that isn't even necessary any more with the '.' property-like syntax.
No, it's not memory-safe - and that would be nice, but you'd give up the ability to just drop into C/C++, which is too high a cost IMHO.
It's just a shame ~Apple~ Lattner decided he wanted to do his own language instead of continuing to improve ObjC.
I think it's easy for an expert to pick up the shallow aspects of a programming language. For example, I've been using Python for many years, but just the other day started designing a card game using Squib (https://squib.readthedocs.io/en/v0.18.0/index.html), which uses Ruby. I've written some passable Ruby, but I feel it's very Pythonic Ruby (maybe with some Rust mixed in). I'll need to do some dives reading through the stdlib docs to discover the little tricks and cool methods that make using a language really fun and different. I've also heard good things about why's guide, which I haven't read.
(Also haven't touched metaprogramming yet, which I hear is very interesting in Ruby).
I find that outside of a handful of more difficult languages, it's rarely the language itself that makes becoming proficient in a new one difficult. More often, it's simply not having any reason or enough motivation to continue using the new language consistently. If you're a language enthusiast and just like to pick up new languages, it can sometimes be difficult to keep up enough consistency to really gain proficiency.
One way to deal with this is to set a goal to complete a project - can be something small like a little script or command line tool, but if learning the languages depends on you continuing to be maximally motivated without any concrete goals in mind, it's gonna be hard to get past the initial learning curve.
The only language I found hard to learn was Erlang. And I have learned other functional languages before. It has a runtime environment that is conceptually too different from most other languages.
I think there are different levels of "learning" or "knowing" a language. I can write some code in almost any language within a few hours but it will basically be C/C++/C# code with a different syntax. This level works for a lot of purposes. But really understanding a language and its ecosystem can take many years (with C++ several lifetimes. I wonder if anybody really understands C++).
I used to be really excited about learning new languages but nowadays I try to keep it small, focus on a few and get really good at them. Constantly switching languages feels shallow.
I have attempted learning and writing multiple languages in my career. I don't know if I have been successful, I can read and write and even criticize code in those languages but I have noticed a huge inertia.
I just don't want to write stuff that it is not JS/TS. I am so proficient in it, that any perceived advantage of other languages I have used (haskell's safety and purity, lisp's repl, C's performance) has a cost too high for me to make it a pleasant experience. Also, having invested so much energy to master TS and its tools puts me off from embracing the same journey in other languages.
I noticed I have the same issue with online games. League? Counter Strike? I'm in. But my will to go through "noob phase" in any other game is an experience I have no interest for.
That’s a good thing in it’s own way. Being a specialist can be lucrative and offer job security. I wish I could do that but I chase the shiny thing too much :)
> Learning a language is difficult when there is little to no mapping with previous languages
When I was first exposed to Scheme and Haskell, I wondered how anyone could be productive in such useless languages. Ironically, they ended up having a huge impact on my programming style and approach to software design. But I'll be the first to admit that learning Haskell was rather difficult. Or perhaps more accurately, learning the functional paradigm was rather difficult as someone who grew up using OO almost exclusively.
I am quite fluent in 5 programming languages. By this, I mean I've used them for years in a professional setting to ship real products. No dabbling, actual, deliberate time spent maintaining code in these languages over more than a decade of coding.
You get attached to the ecosystem around your code, not the code itself.
You don't actually like JS for JS sake. You like it cause of Node.js, React, Vue, Electron, etc.
You don't actually like C#. You like it cause of .NET, Entity Framework, Unity3D, etc.
You don't actually like C++. You like GNU, Qt, Boost, Unreal Engine, the WinAPI, ObjectiveC, Cocoa, etc.
These are just some examples.
If you're finding you dislike something, stop whining, stop comparing, and emulate. Do EVERYTHING the exact same way all your colleagues who like it do. You'll hate it. Wait 6 months, your brain will "get it" eventually and all the sudden now you like 2 things.
Ignore the distaste, the distaste is usually just your brain trying to force you back into your comfort zone. Comfort zones are too cozy, being always cozy will make you a bad programmer.
What on earth is wrong with pip? I've used it in some of the most constrained environments possible, and it has been fine except for one small window where trusted-host wasn't possible.
I think I remember there being a lot of hubbub over the pip/venv standard setup, which is (part of?) what prompted conda. I also seem to remember more than a few attempts to make a new Python dependency manager over the last 5-10 years.
Pip being good or bad aside, Python does have a very extensive ecosystem. It's very well equipped for many tasks, from machine learning (numpy/scipy/etc) to website creation (Django).
I don't really like Python, but I have to admit that those tools are very convenient.
JavaScript is only popular because it was forced on us by being the only option in the browser. Without that it would be as significant as VBScript is now.
They are interpreted and dynamically typed. Some programmers loathe dynamic types. JS and PHP also have quite a bit of quirky legacy code for which there are modern tools or conventions to bypass the quirks entirely (ie ES2015, prettier). However, a great number of programmers have PTSD from those early days and are weary to give them a second look.
I can't speak for JavaScript or PHP, but I hated ruby's package management. Gem dependency hell was a blight that made jumping to Golang inevitable for me personally.
Same for me. Until I learned Haskell. If you don’t know Haskell I highly recommend learning it. Even if you choose never to use it in production. It will make you a better programmer in any language and will make it super easy to learn Idris/Agda/LEAN/Coq etc.
Every year I try to pick up a new technology/language to learn (this year it’s Flutter/Dart) and create a project to get the hang of it. The language itself is never the hard part.
> A technical recruiter, having discovered that that the ways of Unix hackers were strange to him, sought an audience with Master Foo to learn more about the Way. Master Foo met the recruiter in the HR offices of a large firm.
> The recruiter said, “I have observed that Unix hackers scowl or become annoyed when I ask them how many years of experience they have in a new programming language. Why is this so?”
> Master Foo stood, and began to pace across the office floor. The recruiter was puzzled, and asked “What are you doing?”
> “I am learning to walk,” replied Master Foo.
> “I saw you walk through that door” the recruiter exclaimed, “and you are not stumbling over your own feet. Obviously you already know how to walk.”
> “Yes, but this floor is new to me.” replied Master Foo.
> Upon hearing this, the recruiter was enlightened.
That is, once you know how to program, a new language is like a new floor. Yes, it's different, but you know how to walk.
But of course, this koan overstates things. You can go from C++ to C# or golang or maybe Rust that way, but you probably can't go from C++ to Haskell that way.
Correct. That’s why learning Haskell is super useful. Even if you decide never to use it for production work. It will expand and enhance your understanding of what programming is.
Haskell is an example of actually different semantics, but in the end what non-strictness mainly gets you is space leaks and the mistaken concept that Haskell programs are bug-free because it has ADTs[1].
I think I'd recommend learning Mercury. Unification is cooler than even lazy evaluation.
> Learning a language is difficult when there is little to no mapping with previous languages.
Then they go on to describe a developer who experienced shock when transitioning between C++ and TypeScript.
How is this a shock? These are just 2 different dialects of Algol.
Programmers should expand their window of tolerance more by learning languages which are _actually_ different from each other. Such as:
assembly, forth, lisp, apl, sql, smalltalk
A few commenters here mentioned picking up new languages was easy, "except for Haskell". Well, that's probably because all the other languages you picked up were Algol dialects.
Learning another language in the same paradigm is like a native English speaker learning a new accent.
> A good programmer uses the right language for the task.
Agreed!
> A good language is one that doesn't need a community and a beast of an editor just to code something that compiles and runs.
Hmm. [citation needed]. I'd argue the exact opposite. A robust ecosystem and community around a language are a substantial part of its value proposition. Naturally, the language's PL details are what seed and fuel its ecosystem, so I'm not claiming semantics, syntax, and zeitgeist are irrelevant.
See every "worse is better language": C, Python, Java, Javascript, English against whatever ML, Haskell, Esperanto, Lojban, etc.
With a few exceptions large numbers of languages are more similar than different. When working on something in a new or unfamiliar language I usually find my difficulty is less the language itself than the (much larger) ecosystem around it. Usually it's the build and dependency management systems which end up being the biggest blocker. For newer languages lack of a mature third party library ecosystem.
Rust is an interesting example here. The borrow checker was a completely new concept to me and is definitely a challenge. But the build system is far easier to work with than the many alternatives for C/C++ so I end up having an easier time writing Rust than C or C++ despite my previous college experience with those.
Learning the language is usually the easy part. It's learning the libraries, tools, and idioms that takes a bit more time.
It's not that hard but a lot of people resist changes. Also, it takes time to get up to speed which means you are temporarily a bit unproductive. It does not combine well with a job where you are supposed to deliver stuff.
I tend to have a few languages that I favor and a few more where I can wing it if needed. Very helpful when consulting. I would never use ruby, python, javascript, php, scala, etc. on my own projects but I have consulted on projects using each of those and managed to add some value.
165 comments
[ 3.0 ms ] story [ 220 ms ] threadHowever, if the language paradigm is different, such as vector vs. scalar or other significant differences then developers can end up wrestling the language rather than working with in. I would suspect, as it was in my case, that the more experience one has, the worse this conflict will be. I had a way of approaching and implementing code that was just not what the language wanted to see. It was rather frustrating falling into the write/tune rather than write-then-tune process. My only "solution" was to first write things the way I had internalized and then revise them into the appropriate form(s) for the new language.
Once this was done, and I would say it was a 3-6 month process, then the "normal" learning process started. Syntax, grammar and vocabulary is an ongoing process but it's easier as language familiarity grew.
I agree with all you say and my experience was the same.
I think the current problem you describe is a disconnect between the means and the end. We lived through times when the end result was all anyone cared about. Now people have jobs where they don't really know what the end result is.
What I see now is that programmers are often concerned with not what they deliver but how – I’ll do anything as long as it is in A/B/C. Basically means substitute goals. I find it not very healthy.
There are some exotic languages of course which could make my brain melt but since I do not need any for my projects/products I would not care.
Languages have also gotten a lot better over the decades.
> Mostly I think this was because each new language came with some valuable new insight in how to do my work
I don't know if it's true for other people, but it's true enough for me that I gave a talk on it: https://www.youtube.com/watch?v=JgWAWwF6pNY
(note, I haven't actually watched the video yet myself....)
But I could never grok OO, but at least in my case that is not an issue, especially these days :)
Back then, learning new languages was a non-issue, it was the logic you had to understand.
But a language includes idioms, the eco system, and even conventions like camelCase vs PascalCase vs snake_case. Until you master these, all code you write will be alien and awkward to the natives.
C++ has become its own thing, where you have to study an awful lot just to be able to _read_ it, but it is otherwise of the same family.
I’ve only been programming for 40 years, have professionally done so in over 10 languages, and nowadays preach to only pay attention to paradigms rather than languages.
You don’t think differently when working in C# vs Java, and not materially different than e.g. C, if you are writing idiomatic code.
But Lisp, APL, Prolog, Haskell - idiomatic code in any of these languages does not resemble one in any of the others (or the Algols) - they each offer a very different way to look at things. And your C code will be Better if you grok them, even if you don’t use them.
But C# introduced e.g. runtime generics, functional style LINQ, async and also RX style programming first, though RX is not part of the language but the ecosystem.
Lisp basically had all of these in the 1990s. Perhaps earlier.
It's an unnecessary burden to look after "the best tool for the job". In order to know "the best", you have to know all tools deeply enough to judge which is the best.
Should be able to judge whether the tools I currently have are suitable for the problem or not. If not, should be able to search efficiently for one that suits and to learn it to the degree needed.
Finding the right balance of judging, searching and learning can be a joyful adventure.
Constant questioning "is it the best" is a nightmare...
For example, languages like Rust are complex and hard to learn, yet many people get into Rust because it's easy to setup (rustup), easy to run or test (cargo, vscode), easy to compose (crates, stdlib), and easy to learn (so many online resources).
On the other hand I've been learning OCaml and suffering. I would advise anyone who wants to have real world impact in a low-level language to give a shot to OCaml, because there are just soooo many ways to influence the language. If you write a library it will be used, there's so many opportunities for creating learning resources or improving the tooling, it's uncharted territory for the most part and it's probably the functional language that has the most chance of having a real-world story.
All those things apply to Python too (not that I've learned Python ;-) There must be more than just these reasons why people learn Rust instead of Python.
I'd say Python lacks a good out-of-the-box experience compared to Rust. You can't really use Python like Rust without figuring out how to install a project's dependencies, how to manage different versions of Python (which is even more of a nightmare if Python comes pre-installed with your OS), and Python's documentation kind-of-sucks in comparison to languages like Golang and Rust I find.
Because of how batteries-included Python is, you absolutely can, because you can use it quite a bit without any dependencies outside of stdlib.
> Python's documentation kind-of-sucks in comparison to languages like Golang and Rust I find.
I find Python's documentation to be far and away the best of any language I have encountered, and that definitely includes Go and Rust.
I'm not talking about stdlib. If we're talking about stdlib then Golang is the gold standard :) I'm talking about using other projects. If they use a requirements.txt and pip maybe you'll have some luck, that is if you're using the same version of python/pip.
> I find Python's documentation to be far and away the best of any language I have encountered, and that definitely includes Go and Rust.
I'd say everyone should make their own opinion on the subject:
* https://docs.python.org/3/library/string.html
* https://pkg.go.dev/strings
* https://doc.rust-lang.org/stable/std/string/struct.String.ht...
For having written a lot of these three languages, I find python's doc an ordeal to go through. But if you're comparing Python to C, C++, and other languages like that then sure it's great :D
I mean look at Golang's. List of all the methods on the left, examples for each method.
So the fact Rust's String is specifically UTF-8 text is highlighted, because the documentation is about the type, presumably (modern) Python and Go also have UTF-8 strings, but that's not the context of the doc links so that's not what they're talking about.
On the other hand, some features you might expect from a string type are (at first glance) missing from Rust's String, because they're implemented on str and so you get them for free because String is Deref<Target = str>
This is also a problem looking at say, Java documentation, if you don't know that all the classes (but alas not the primitives) are sub-classes of Object then you've no reason to assume Object's methods work on them.
Documentation has to be pitched correctly and if you're the wrong audience you will struggle to make use of it. Presumably expert C++ programmers have no problem with this sort of mess:
https://en.cppreference.com/w/cpp/string/basic_string/find
Suffice it to say that I have been away from Python too long, now it's like learning a new language all over again.
I started with
C++/PHP/JS
and then I started doing C# + meanwhile some Lua
I cannot use anything that has not as good IDE as at least Visual Studio
I struggle to overcome the lack of reliable IDE
I wrote little programs to work problems for me and print all the "show your work" bits.
I did it all on the device itself, since I didn't have the right cable or whatever to copy things onto it.
One time, the teacher was giving out a piece of candy for every Pythagorean triple that we could name. A little brute-force program written in a couple of minutes had me with a small handful, and eventually a ban from participating :)
Self-doubt then crept in: if I rely on the IDE as a crutch, do I really know the programming language and tools that well?
Then I put myself through the grinder and learned how to program without anything but vim/notepad and command line.
Yes, it’s hard work, but now, I can use ANY editor to learn any programming language ecosystem.
Try it, you’ll understand a lot more than what’s inside the IDE box.
When I jump into unknown code base, then having "." that displays me list of avaliable fields/properties/methods is insanely helpful.
It just speeds up whole discovery
stuff like jumping to method, showing all references, etc.
The language itself is often no trouble at all. It's all the stuff around it that ends up eating shitloads of time.
Kotlin is great! I enjoy it a lot and am having a fun time ramping up for my new role. But the entire Java ecosystem is a dumpster fire, and I abhor Gradle/Maven/Intellij.
It would take me an entire weekend to try to configure Sublime Text or another lightweight plain-text editor to work with Gradle to even build the project, let alone any language server features like code suggestions and debugging.
What do you dislike about IntelliJ?
IDEs should not punish you for knowing what you want to say and typing it quickly. They should be DETERMINISTIC, and you should get the EXACT same results no matter how many milliseconds of delay you wait between each keystroke, and you should always be able to insert something by typing it literally at any speed, without pausing and waiting then focusing your visual attention on the screen and then finally pressing other buttons to use the menus.
Turns out, Intellij’s “Actions on Save” are only triggered when a “Save All” (option-command-s) is issued, and ignores any other type of save like good-ole command-s.
It is weaker IDE in terms of what it does. Eclipse is older, look uglier and strictly superior unless you work on some kind of super large project where it is breaking.
Nowadays, given the state of LSP implementations and editors being as flexible as VSCode i.e it's hard to justify the need for an IDE... In general.
I usually use nvim or VSCode (if I collaborate with someone) for other languages. Every time I have to work on a Java project, and I have to open IntelliJ... I know it's going to be a nightmare.
Java is therefore somewhat a victim of its own success. There is no absolute "best" as you seem to suggest. Every ecosystem has pros and cons.
Rationalising a language's ecosystem is harder than building one. I suspect that this drives at least some new language adoption.
A good programmer uses the right language for the task. A good language is one that doesn't need a community and a beast of an editor just to code something that compiles and runs.
An "ecosystem" is usually a sign of costly entropy.
Agreed!
> A good language is one that doesn't need a community and a beast of an editor just to code something that compiles and runs.
Hmm. [citation needed]. I'd argue the exact opposite. A robust ecosystem and community around a language are a substantial part of its value proposition. Naturally, the language's PL details are what seed and fuel its ecosystem, so I'm not claiming semantics, syntax, and zeitgeist are irrelevant.
See every "worse is better language": C, Python, Java, Javascript, English against whatever ML, Haskell, Esperanto, Lojban, etc.
It's a measure of a language's usability if a programmer can't use the simplest possible tools to be productive.
Education and documentation is necessary. But if you have to have an entire support channel for a technology, it isn't necessarily a positive reflection on the technology.
Which languages don't need a community?
The reason I single out self-taught developers is that many CS paths will push though a broad degree of language, or at least interpreters and compilers, such that its less of a hill to climb.
I am a self-taught developer with this problem. But I still enjoy diving head first into new languages. It just takes awhile.
Self-taught programmers on the other hand more often have the intrinsic curiosity and motivation to learn those topics. Also diving deep into topics is their strength, since the uni counterparts often know the names of concepts, but after a while it's quite clear that this knowledge of names is rarely coupled with familiarity with the topics they represent. I'm sure just knowing the names of things gets you far when you want to pass an exam, but for actual work it's scarcely different from knowing nothing at all. As Feynman said, there's a big difference between knowing the name of something and knowing something.
Now, those are just generalizations from experience. I've also met plenty of counterexamples in both groups.
https://svelte.dev/tutorial/basics
C++ is treated as a separate language from C, but it just started as C with objects.
I’ve met many JavaScript programmers who are just good at gluing together various JavaScript libraries, but aren’t really proficient generally.
For example: you might be really good with redux, which is its own confusing stringy disaster, but not really understand the fundamentals that make it function.
It makes me happy to find out that colleges mostly teach python now, although I don’t agree with the MO now being that everything lives in a venv. In my opinion, open up IDLE and get to work. Virtual environments just add another level of confusion!
GO, and C, and also JavaScript are all great too of course and I use most them in a given week. I think if you focus on programming, and look at tooling as just extra convenience, then you won’t have problems learning new languages.
(Except objective C, which objectively sucks.)
Objective-C is my preferred language.
- It has the complexity/expressiveness balance correct, it's not the 'point a warhead at your head' of C++, neither is it the primitive belt-and-braces approach of C.
- It has a relaxed memory-allocation model with ARC that I very rarely have to worry about, and when I do, it's fairly obvious what to do. Generally just call [object-class new] and forget about it.
- It's binary compatible with C and C++, so if I really need the speed of either of those two, I just drop into them instead for the small amount of code I need, or use a library.
- It's named-parameters to methods make it easy to understand what a method in a class will do - though it's sometimes carried to extremes I agree.
- It has a really nice standard library that comes with it, and the framework/bundle idea makes packaging things up really easy
- In the debugger, I can always call a long stream of nested method-calls and get back the expected result, because message-calls are not function-calls.
- No dependencies are needed for any produced code (well, you need the system frameworks, but that's like saying libc.so is a dependency). You don't have to worry about whether you have PHP v5,6,7,... or Python 2.x vs 3.x. Just run the app.
All that for some [...] syntax. Except that a lot of that isn't even necessary any more with the '.' property-like syntax.
No, it's not memory-safe - and that would be nice, but you'd give up the ability to just drop into C/C++, which is too high a cost IMHO.
It's just a shame ~Apple~ Lattner decided he wanted to do his own language instead of continuing to improve ObjC.
(Also haven't touched metaprogramming yet, which I hear is very interesting in Ruby).
One way to deal with this is to set a goal to complete a project - can be something small like a little script or command line tool, but if learning the languages depends on you continuing to be maximally motivated without any concrete goals in mind, it's gonna be hard to get past the initial learning curve.
I used to be really excited about learning new languages but nowadays I try to keep it small, focus on a few and get really good at them. Constantly switching languages feels shallow.
I just don't want to write stuff that it is not JS/TS. I am so proficient in it, that any perceived advantage of other languages I have used (haskell's safety and purity, lisp's repl, C's performance) has a cost too high for me to make it a pleasant experience. Also, having invested so much energy to master TS and its tools puts me off from embracing the same journey in other languages.
I noticed I have the same issue with online games. League? Counter Strike? I'm in. But my will to go through "noob phase" in any other game is an experience I have no interest for.
When I was first exposed to Scheme and Haskell, I wondered how anyone could be productive in such useless languages. Ironically, they ended up having a huge impact on my programming style and approach to software design. But I'll be the first to admit that learning Haskell was rather difficult. Or perhaps more accurately, learning the functional paradigm was rather difficult as someone who grew up using OO almost exclusively.
You get attached to the ecosystem around your code, not the code itself.
You don't actually like JS for JS sake. You like it cause of Node.js, React, Vue, Electron, etc.
You don't actually like C#. You like it cause of .NET, Entity Framework, Unity3D, etc.
You don't actually like C++. You like GNU, Qt, Boost, Unreal Engine, the WinAPI, ObjectiveC, Cocoa, etc.
These are just some examples.
If you're finding you dislike something, stop whining, stop comparing, and emulate. Do EVERYTHING the exact same way all your colleagues who like it do. You'll hate it. Wait 6 months, your brain will "get it" eventually and all the sudden now you like 2 things.
Ignore the distaste, the distaste is usually just your brain trying to force you back into your comfort zone. Comfort zones are too cozy, being always cozy will make you a bad programmer.
Snark/not-snark: what about those languages where the fans still don't like the tooking? (looking at you, pip)
I don't really like Python, but I have to admit that those tools are very convenient.
JavaScript has been very useful for me building Node and Electron apps.
Ruby has been useful for me for building large dynamic CMS apps.
PHP largely got me into web development and is still used in Wordpress which I still maintain plugins for. Laravel seems cool too.
Everything has its merits and its environment where it shines. They’re also all imperfect, but that’s okay.
I love Clojure because of Clojure itself (s-expressions really grow on you), and not because of the JVM or java ecosystem.
Admittedly, it does help when there are good libraries.
> The recruiter said, “I have observed that Unix hackers scowl or become annoyed when I ask them how many years of experience they have in a new programming language. Why is this so?”
> Master Foo stood, and began to pace across the office floor. The recruiter was puzzled, and asked “What are you doing?”
> “I am learning to walk,” replied Master Foo.
> “I saw you walk through that door” the recruiter exclaimed, “and you are not stumbling over your own feet. Obviously you already know how to walk.”
> “Yes, but this floor is new to me.” replied Master Foo.
> Upon hearing this, the recruiter was enlightened.
(From http://www.catb.org/~esr/writings/unix-koans/recruiter.html)
That is, once you know how to program, a new language is like a new floor. Yes, it's different, but you know how to walk.
But of course, this koan overstates things. You can go from C++ to C# or golang or maybe Rust that way, but you probably can't go from C++ to Haskell that way.
I think I'd recommend learning Mercury. Unification is cooler than even lazy evaluation.
[1] recent example: https://www.costarastrology.com/why-haskell/
Then they go on to describe a developer who experienced shock when transitioning between C++ and TypeScript.
How is this a shock? These are just 2 different dialects of Algol.
Programmers should expand their window of tolerance more by learning languages which are _actually_ different from each other. Such as:
assembly, forth, lisp, apl, sql, smalltalk
A few commenters here mentioned picking up new languages was easy, "except for Haskell". Well, that's probably because all the other languages you picked up were Algol dialects.
Learning another language in the same paradigm is like a native English speaker learning a new accent.
Agreed!
> A good language is one that doesn't need a community and a beast of an editor just to code something that compiles and runs.
Hmm. [citation needed]. I'd argue the exact opposite. A robust ecosystem and community around a language are a substantial part of its value proposition. Naturally, the language's PL details are what seed and fuel its ecosystem, so I'm not claiming semantics, syntax, and zeitgeist are irrelevant.
See every "worse is better language": C, Python, Java, Javascript, English against whatever ML, Haskell, Esperanto, Lojban, etc.
Rust is an interesting example here. The borrow checker was a completely new concept to me and is definitely a challenge. But the build system is far easier to work with than the many alternatives for C/C++ so I end up having an easier time writing Rust than C or C++ despite my previous college experience with those.
File new project, add files into project, add missing dependencies via NuGET/vcpkg/conan, done.
It's not that hard but a lot of people resist changes. Also, it takes time to get up to speed which means you are temporarily a bit unproductive. It does not combine well with a job where you are supposed to deliver stuff.
I tend to have a few languages that I favor and a few more where I can wing it if needed. Very helpful when consulting. I would never use ruby, python, javascript, php, scala, etc. on my own projects but I have consulted on projects using each of those and managed to add some value.