Why is it difficult for developers to learn another programming language? (2020)
cacm.acm.org
cacm.acm.org
I have been programming since quite young age, used more than 15+ different languages (Basic, Aseembly, Pacal, Delphi, DOS .bat, Javascript, Word Basic, Java, C#, C, shell script, EL, xslt, SQL, etc., and I can 'read' quite a few more). This is the 1st time I have heard learning a new language is 'hard'. Most of my team uses at least 3 languages and most of folks have learned at least 2 on the job. That being said - one of the languages would be primary but learning few to a level to be able to do your job in a decent fashion is just 'normal'.
The only hard thing I'd consider is switching to a pure functional language (for whatever reason) - the paradigm is very different. Other than that, most languages are pretty much the same - for quite a few I tend to have an idea what they machine code should compile to as well. Learning APIs/libraries is another matter but it's not difficult, either.
Besides, the determined Real Programmer can write Fortran programs in any language.
This is less true for something like PHP that was just cobbled together from whatever was to hand with no aesthetic or design principle but that's a rare case, I actually can't think of any other widely used language that exhibits this behaviour.
I would guess I was maybe 80-90% productive in C# after only a few months with it, because of existing familiarity with a bunch of semi-colon languages including Java. Certainly enough to keep up with people who'd used it for years but for whom programming isn't a passion.
Things I would expect from a consistent standard library are stuff like how identifiers are used, it makes sense that this.contains("clowns") and this.begins_with("Seven") and this.matches(a_regex), whereas it's weird if this.contains("clowns") but this.BeginsWith("Seven") and a_regex.matchedON(this)
Or familiar patterns, if I can write stack.len() then vector.len() and array.len() and string.len() should exist and do what you expect, it's weird if instead there's stack.size() and vector.len() and array.width() and string.length()
And things should compose nicely. If one part of the stdlib offers to Reverse and Shuffle things, and another offers me groups of IP addresses, I should logically be able to Shuffle the IP addresses without needing to build an adaptor, if I can name Files and I can name Users, I ought to be able to name some Files after Users without learning about how strings are conventionally encoded on the operating system I'm using. If there's a way to talk to a Database, and a way to talk about Dates, somebody else should have done the work to ensure that the date queries I run in the database work with the Dates from the same stdlib.
I had some hardships understanding the concept. I used and liked Pascal. Turbo Pascal 6 & OOP - not the most elegant combo. Managed to grasp how it worked: imagine the entire method surrounded by "with" (with in javascript does the same) - I looked at the assembly and the virtual method dispatch and it all became super clear and obvious. Pretty much learned OOP by looking at the disassembled code compiled with Turbo Pascal.
Hard or easy is a matter of perception, and everyone sees things different.
I have had my fair share (100+) of interviewing developers too - hired people w/o any experience in a specific language and they have been productive in a short time frame - learning the environment and the business domain has always been the slow, laborious process, not switching to a different language (again - never had to use purely functional language for real - SQL doesn't count)
It was mentioned the "idiomatic use" - that's trivially caught in a code review/pair programming - you see it once, remember/understand and move on.
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...
Learning new languages isn't that bad. It's learning whole new tech stacks, that often don't add all that much, that is the painful part. This is doubled by the general shallowness of private-sector work (read: bureaucratic nonsense we are forced to do, on the behalf of very rich people who despise us, because we have failed thus far to forcefully remove them) because there is a very low embarrassment threshold. Just not knowing something can lead a boss or (gag) product manager to "flip the switch" on you, and now you're seen as a non-serious player. Every technical change threates to shuffle the perceived "performance" ordering on the team. The bosses aren't going to invest in your learning, or even let you invest your own working time into it--you're expected to throw down extra hours and weekends into picking up the new tech stack.
Learning new languages isn't hard. It's fun, actually. Learning a bunch of libraries that were invented three years ago, under adverse political circumstances, is considerably less fun.
For example: C's malloc vs C++ new
And due to these interactions, languages that look superficially similar can end up feeling very different, like C# and Java seem pretty similar but having programmed in both of them, the subtle differences and their network effects cause the code to look very distinct.
Differences can exist within a single language, like for C++, C-with-classes, std heavy C++ and Qt-flavored C++ feel like different languages.
malloc is a typically C very low level allocator feature, actually it's barely even a whole feature, it's just the memory allocation step when you're presumably going to want to put something in this expanse of emptiness. Or maybe being C you will forget to do so and then be astonished it's nonsense.
new is a C++ operator that either does the allocation and calls a constructor for one or more objects to fill that newly allocated space or it runs constructors on memory you already got from somewhere else (this use of the same operator is called "placement new" because C++ cannot get enough overloading)
It is very strange to assume allocation in your operators, no other examples beyond C++ come to mind, but most of new's work is running constructors, which don't exist in C.
However, C++ doesn't have a single base class, so by making new an operator, it has a default implementation in every type whereas there is nowhere to write a function with that behaviour.
This doesn't matter for malloc because C doesn't have a type hierarchy.
Edited to add: std::make_unique always makes the thing std::make_unique wants to make, you can't overload that for your new type where it should do something else.
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.
Learning new paradigms are harder than learning a new language. Example (functional vs OOP)
YouTube is a great resource to give you "overview". Notice I didn't say do a youtube course (although if that is your jam go for it). I found the YouTube "programming tutorials" is a great way to just start filling in the "outer leaves of the knowledge tree" for a particular language/paradigm/framework.
I've also over the years, "conditioned myself", by telling myself learning a new lang/paradigm is not "hard" it's just "pain in the arse / time-consuming", but not "hard".
YMMV
I would guess it's pretty difficult to learn all of the idioms, tooling, community, etc of the first language for most programmers as well?
It can be easy to forget your struggles with something when, years later, you've become comfortable with it.
Learning language to OK level isn't usually that hard. The rest of which makes an effective developer able to deliver useful products is another story.
Back in the 80's and 90's, people who started by dabbling around with shell scripting and then discovered Perl (which proudly touted its similarity to shell scripting as a "feature" instead of a "liability") tended to think that Perl was incredibly powerful just because it had hash tables and regular expressions, which the shell didn't support at the time (and was a major source of frustration). And they ascribed the power to Perl itself, instead of hash tables and regexps, because C doesn't have hash tables and regexps built in, so it's "hard" to do what they do in Perl, and they assumed it was something special about Perl itself, not just its hash tables and regular expressions that are totally independent of the language, which other languages like Python and JavaScript and even C++ finally now have (which all eventually became much more popular than Perl).
Finally there are enough popular languages with hash tables and regular expressions and all kinds of other data structures and libraries that Perl doesn't seem like such a unique special magical language any more. But for many programmers decades ago, Perl was a mono-linguistic dead-end black hole that made them afraid of learning any other language for quite a long time, and they'd fervently evangelize Perl as the solution to every problem, without recognizing how badly designed and hard to learn and maintain it was (while celebrating and cultivating its write-only aspect and fetishizing its arcane line-noise syntax and TMTOWTDI-oriented programming in the name of job security), and without bothering to learn any other more powerful, better designed languages like Lisp or Python or even Java or C++ to compare it with.
I think that effect of ascribing all that magical power to the surface features of the first language you learn instead of realizing that it's just the abstract data structures and libraries is still common with newbie programmers, but just not as intense and pathological as it was with Perl back in its heyday in the 90's.
Now we have cross-language data description languages like (dare I say) XML and JSON, so it doesn't matter so much what language you write stuff in, and they can all interoperate easily, and you can mix and match the languages that support the libraries you need, so professional programmers should be comfortable writing in several languages (and data formats) at once, including non-programming languages like JSON, XML, HTML, CSS, YAML, etc. The mono-linguistic mindset is a huge liability these days.
I've also taken this lesson to heart with non-technical things - young me didn't have the patience to learn to play the guitar, but old(er) me now sees learning the guitar for what it is - a journey of exploration and continuous learning. Before I was far too focussed on the "end game" of mastering something (i.e., being a master) rather than appreciating the progression of being a student.
However now jump into IDE, build tooling, package managers, standard library, implementations (compilers/interpreters/runtimes), common set of third party libraries that always get used (e.g. boost, qt, rayon, tokio, wpf, forms, spring,....).
And naturally a deadline to deliver something into a couple of weeks.
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.
There was one moment where I was standing across the room from a colleague, and just from the syntax highlighting colour scheme combined with the blockiness of the code I could tell they were writing PowerShell with a "VB script accent". Upon closer inspection the script totally looked like someone thinking through the problem "in VB" and then translating that statement by statement to PowerShell.
I've seen people try and shoehorn LISP into vanilla Java, which is just hilarious.
The most common example where it causes a real issue is people writing SQL with a "procedural style". This kills the database server and makes the DBA cry.
Another striking example is this example of JavaScript written with the accent of a mathematician: https://raw.githubusercontent.com/enkimute/ganja.js/627711f9...
You're not obliged to implement a type straight after defining the type itself, so without repeating that identifier Rust has no way to be sure which type it is you want to implement. You particularly might want to define several types up front, and then write impl blocks for them later.
> have a look at what it takes to refactor even trivial pieces of code in Rust
For many similar refactoring jobs Default is adequate. Here Default's derive macro obviously won't guess that you think "blah!" ought to be the default string for some reason (or that miraculously a few lines later now "test" is the default). However it seems like the correct choice here is to implement Default for your new struct ? And you do eventually get to that.
But on the way there you go off on a tangent to provide implementations for any arbitrary AsRef<str>, a feature the "equivalent" C# code didn't offer but which apparently was a compelling need for this "refactoring". The types change radically too.
If you don't go off on that tangent, you can use Self as you expected, and your solution is much shorter and more robust but does the same thing as the C#.
Or, you could modify the C# so that it is fully generic like your Rust solution, after all the Rust solution is able to take any string-like parameter type and the C# only works with the language's built in strings.
While you're in there remember that C# "Strings" aren't like Rust's strings, they're just Vec<u16> in Rust terms. There's no promise that these are actually Unicode text. They probably are text but they're only promised to be some even number of bytes presented as ostensibly UTF-16 code units for your convenience.
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.
> 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/
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://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:
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.
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.
C++ is treated as a separate language from C, but it just started as C with objects.
(Also haven't touched metaprogramming yet, which I hear is very interesting in Ruby).
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.
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.
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.
Easy: To learn a language with the same paradigm as a language you know, e.g. JS -> Python (both are procedural and dynamic); Java -> C# (both are procedural and static)
Medium: To go from dynamic to static typing, e.g. Python (dynamic) -> Java (static)
Hard: A new language that requires learning many new concepts unfamiliar to you before, e.g. Java/C# (with GC) -> Rust (no GC, borrow checker, RAII); Java (eager, OOP) -> Haskell (lazy, functional)
Super hard: A new language that hardly has anything in common with languages you know, e.g. SQL (query language) -> Rust (systems programming language); Python (procedural, functional) -> Prolog (logic)
If all you know is OOP, dependency injection and inversion of control patters, interfaces, and the like then functional languages oriented around functions as first class constructs, often immutable data processing, and a focus on pure functions is not going to make sense to you. It takes time to "unlearn" previous idioms and grok the culture and idioms of a new language.
I also think a lot of people are closed off to new ways of doing things. If you switch to a different language and framework and then immediately search for a library that allows you to do things the same way as in your old language then you're not really embracing that new language and should just stick to your old language.
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.
The latest language I learned was solidity and I was yo and running in under a day with a few more days learning about the different smart contract techniques and the standards that exist. The language itself was super easy to pick up.
I plan on learning Idris when I get the time for side project aiming I can think of one that would suit.
E.g. learning your second web framework.
Routes are now called actions.
Whatever you wrote in a route is now called a controller.
A controller calls different things that has different layers of abstractions, most have to do with business logic.
You can take a guess which language ecosystems I'm talking about.
Of course, the experience is subjective and people were also using controllers in my former language ecosystem, but I never truly got to that point.
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.
Saying learning a new programming language is hard because of that is like saying that English is hard to learn specifically because some verbs have exceptions for past tenses. I see no reason why that would be a predictor for how learning English is hard in general.
Same can be said for programming languages, I see no reason why how someone deals with peculiarities of a language says anything about that language being hard to learn, in general.
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 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.
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.
Joining a new cargo cult can be difficult.
There is spectrum of software developers out there ranging from some know and understand programming through some who know a programming language to some who know an application.
The one that did burn me was learning JavaScript after python. Uncanny valley: there are idioms that are close but not exactly the same between the two languages. It was easier for me to move from c++ to python then from python to JavaScript.
I'm currently learning Dart Flutter because it is like C syntax with JavaScript. I know 38 programming languages since 1986. Most of them are obsolite.
The way that every programming language has decided it needs to reimplement make, badly, several different times, is one of the worst things about programming.
Teach Yourself Programming in Ten Years, by Peter Norvig.
But if the paradigm is very different, say from Java to Haskell, OK this is pretty tough.
At least not if the developers didn't live in a bubble only caring for and looking at one language for most of their carrier.
Suffice it to say that I have been away from Python too long, now it's like learning a new language all over again.
Right now I’m dabbling with Go, and trying to figure out whether or not I should use a Context to propagate my log instance. These are design choices, trade-offs, that you can only fully make once you’re properly familiar with the language’s idiomatic approach to solving problems.
Otherwise you’re just shipping poor quality code.
Totally disagree. The main principles are quite the same - most of the stuff is either a datastructure (that you already know how it works/performs/complexity) or it translates to an OS call. Now, there are frameworks with their own caveats. In the end all languages must end up in machine code one way or another. There are not many ways to make the latter work in an efficient manner, so you get a pretty decent expectation what it should be happening. On top of that most of the frameworks and languages do have source code that can be checked too.
Logging in most languages is per class/namespace/package and tends to be a static one (static in Java/C#/C version).
If you’re claiming someone is perfectly able to learn all this in a few days of time, then what makes the difference between that person and someone with a few months of experience? What about a year or two?
About being perfect - I'd not claim that even after many years of experience, yet to do a decent job a week is more or less enough. Productivity might suffer, if changing the IDE/toolchain drastically, but that's a learning process and nothing hard either.
... but not the ways to write them. Idiomatic use is a thing. You see this all the time, people come from Java and try to write Kotlin/Go as if it were Java and that results in a code thats hard to understand and inefficient.
As for log, you shouldn't, assuming the reason for passing it around is testing. Go and Elixir use a similar idiom in that case where mocks aren't used, so in the case of a log library, the direct dependency with an option to disable logging in tests is preferable