I'm fascinated by this idea of deciding when it's the right time for a new language. Like, what extra factors go into choosing between the benefit of Java and Python's wide adoption for the better performance of, say, Kotlin and Go?
And I know the answer is sometimes that you have to roll with the language and codebase that your team or company has already invested time into. But what would drive you to advocate for an upgrade, and what benefits would entice you to undertake the porting, rewriting, and rebuilding that would be necessary with moving to a new language?
Have any great anecdotes or advice on this topic? Please share them in the thread here. Your comments could be featured in an upcoming newsletter edition.
At work, the biggest thing to pay attention to is the availability of libraries. Go has a lot of great libraries for writing infrastructure code, for example, but it's not so easy to write a GUI desktop app in Go.
For personal enrichment, listen to Alan Perlis who said, "A language that doesn't affect the way you think about programming is not worth knowing." So learn Smalltalk.
Each time when I look for job and see that some framework or language is popular and on demand, I attempt to learn that language or framework. I am against practice of not hiring veteran programmers (who on old jobs had jquery or Delphi) as "inexperienced" ( without counting that they actually do know new stuff like Angular or React from following online courses and tutorials) and denying employment on that basis
As I ramped into software development as a profession, I had learned procedural languages like C, rendering like HTML, set-oriented processing like SQL, and even encamped myself strongly in Microsoft COM followed by .NET (while secretly also using Java), but had not experienced in the language/framework space as a radical departure from the multi-threaded viewed from the perspective of single-threaded until I Learned Me Some Erlang ( https://learnyousomeerlang.com/ ) and met the Actor model that had also emerged in the Java world via Scala, Akka, and Spark and its framework friend Mesos (powered by an actor model in C).
Along the way from early days to twenty some years later, there has not been as much oh my goodness am I going to grok this fast enough nor joy of discovery as Erlang brought because so much else had been the same models mostly with different syntax and runtime and/or developer workflows that they are optimized for.
That that optimization can be encapsulated within the language implementation and rise the developer into the protocol-development and implementation space helped me have a greater appreciation for the wisdom of the developers of languages+frameworks, but especially Joe Armstrong and the Erlang/OTP development team, and also reconsider how I can bring such joy to those who develop on the codebases that I contribute.
There are lots of languages out there, in some cases the function of the language has been conflated with with that an IDE and source code management system should be doing. Apple has mad a confusing mess out of their system by heavily push swift, which has a few nice features taken from modern languages but had the hidden agenda of renaming all the API that Mac OS and iOS has been using since it was built out of NeXTStep and Mach. Their idea of simple" means "fewer characters', but as a guy who's worked with tiny character languages like APL and FORTH , compactness doesn't really lead to clarity. Swift has the disturbing tendency to not be backward compatible with releases from a few months before. Like iOS's painful suppression of the idea of a file, swift and a few other languages like to pretend there isn't such a thing as "pointers" and if you ever really need to use them, you have to bend over backward.
And that really brings out the real problem: languages are actually quite stable compared with APIS, which is where the real action is. Also, lots of things are relegated to libraries that should be built into languages. Is there any reason to ship a Python without Math and Numpy built into it?
Apparently, you can do anything with llvm. I'm a huge fan of "little languages", allowing domain specific work to proceed unencumbered by the assumptions of a more general purpose language.
Where do I see it going though? The only language left will be Cucumber - or I hope a better testing framework than that - since an AI will use it to gen code complete llvm byte code directly from the tests. No source, no linking,lots of inline code, GPU and other parallelization, and of course, being an AI, self optimizing and automatically adapting to new APIS, frameworks, deprecations, filesystems, screen layouts, accessibility and all the other things a modern application needs to build and maintain.
At work, the biggest thing to pay attention to is the availability of libraries. Go has a lot of great libraries for writing infrastructure code, for example, but it's not so easy to write a GUI desktop app in Go.
For personal enrichment, listen to Alan Perlis who said, "A language that doesn't affect the way you think about programming is not worth knowing." So learn Smalltalk.
Each time when I look for job and see that some framework or language is popular and on demand, I attempt to learn that language or framework. I am against practice of not hiring veteran programmers (who on old jobs had jquery or Delphi) as "inexperienced" ( without counting that they actually do know new stuff like Angular or React from following online courses and tutorials) and denying employment on that basis
As I ramped into software development as a profession, I had learned procedural languages like C, rendering like HTML, set-oriented processing like SQL, and even encamped myself strongly in Microsoft COM followed by .NET (while secretly also using Java), but had not experienced in the language/framework space as a radical departure from the multi-threaded viewed from the perspective of single-threaded until I Learned Me Some Erlang ( https://learnyousomeerlang.com/ ) and met the Actor model that had also emerged in the Java world via Scala, Akka, and Spark and its framework friend Mesos (powered by an actor model in C).
Along the way from early days to twenty some years later, there has not been as much oh my goodness am I going to grok this fast enough nor joy of discovery as Erlang brought because so much else had been the same models mostly with different syntax and runtime and/or developer workflows that they are optimized for.
That that optimization can be encapsulated within the language implementation and rise the developer into the protocol-development and implementation space helped me have a greater appreciation for the wisdom of the developers of languages+frameworks, but especially Joe Armstrong and the Erlang/OTP development team, and also reconsider how I can bring such joy to those who develop on the codebases that I contribute.
I burned through languages early in my career, and test new ones frequently for taste.
But I’ve noticed that I do tend to focus on a single language for 6-10 years at a time when a new one really grabs my attention.
Currently 5+ years into a love affair with Go.
There are lots of languages out there, in some cases the function of the language has been conflated with with that an IDE and source code management system should be doing. Apple has mad a confusing mess out of their system by heavily push swift, which has a few nice features taken from modern languages but had the hidden agenda of renaming all the API that Mac OS and iOS has been using since it was built out of NeXTStep and Mach. Their idea of simple" means "fewer characters', but as a guy who's worked with tiny character languages like APL and FORTH , compactness doesn't really lead to clarity. Swift has the disturbing tendency to not be backward compatible with releases from a few months before. Like iOS's painful suppression of the idea of a file, swift and a few other languages like to pretend there isn't such a thing as "pointers" and if you ever really need to use them, you have to bend over backward.
And that really brings out the real problem: languages are actually quite stable compared with APIS, which is where the real action is. Also, lots of things are relegated to libraries that should be built into languages. Is there any reason to ship a Python without Math and Numpy built into it?
Apparently, you can do anything with llvm. I'm a huge fan of "little languages", allowing domain specific work to proceed unencumbered by the assumptions of a more general purpose language.
Where do I see it going though? The only language left will be Cucumber - or I hope a better testing framework than that - since an AI will use it to gen code complete llvm byte code directly from the tests. No source, no linking,lots of inline code, GPU and other parallelization, and of course, being an AI, self optimizing and automatically adapting to new APIS, frameworks, deprecations, filesystems, screen layouts, accessibility and all the other things a modern application needs to build and maintain.
That was in '95, when Java first came out, the main reason I learned it was "Write once, run everywhere" ! That was attractive enough for me ^_^ ! This is my latest work done with Java Swing : https://gatecybertech.com/Dir_GATE_For_PM_Pages/gateforpm_download.html