"JavaScript fatigue" is a well known concept (which also brought a lot of good) sired by the explosion of the JS community in the latest years but I would like to open a discussion about the rest of the software technologies as well.
Do we have too many programming languages? Sometimes I find myself thinking about the fact that we (as the developers on planet Earth) spend so much time writing "a date/time library" in a gazillion of languages because every new language or framework obviously needs one. I'm not arguing merits here, every language is either amazing or useful to someone but they all need the same building blocks. Will we ever find a "one true language" for each domain (I know, my reasoning is fallible) and stop rewriting functions to split a string into an array each and every time?
Are there too many technologies on the cloud? I am not advocating monopoly obviously but every time I open the AWS console (I hope I'm not the only one) I find this dashboard a bit ridicoulous:
I honestly don't know what half of those entries do.
The Google Cloud offer is also super long:
I guess the same goes for Azure.
How much cloud tech are we supposed to be familiar with?
So, am I the only one that thinks of "software developer fatigue"?
Top comments (30)
Great questions!
As far as languages, I believe that new languages will keep coming around and I think a huge part of that is figuring out the best way to write software and learning from past efforts. I look at languages like Elm, Rust, Go, Scala, and Elixir. They're all evolutions of past efforts where the language was written and designed nearly from scratch, pulling in all the best ideas currently out there.
And as they evolve, they will produce more ideas. While older languages will hang on and evolve as well. They can't start from scratch but I'd look at JavaScript, C++, and C# where they're growing and getting better with time: from performance, to library support, and much more than that.
The fatigue is real but you just need to zoom in on what really interests. I wanted to learn a good replacement for Node (for fun) and sampled Elixir and Golang. I'm using Elixir at work and Golang in my spare time because I like the way it looks and feels.
When it comes to cloud offerings, Amazon's dashboard pretty much gives me a panic attack until you realize that only a handful of services are relevant to YOU. But all of them are offerings that people use.
Looking at the list, I doubt we use more than 5 of these services at my job: S3 and IAM are the ones that come to mind immediately. However, we're planning to migrate our DB to Amazon as well, and it's possible our search will be another one.
I think many languages have become better because of other languages.
It would be entirely possible that some mainstream languages would have been worse or evolving at a slower pace if the ones on the fringe or at least less mainstream wouldn't have been there.
But that's the beauty of it. I don't have an answer but I just wonder sometimes how many times we'll rewrite "now.to_iso_8601()" and in how many languages :D
I picked up Golang recently and I loved it but I don't think it will ever become my "swiss army knife".
I'm circling, from afar, around Dart 2 because Flutter finally made me interested in mobile development but I don't have time right now so I'll wait for Flutter 1.0 :-D
I agree with what you said about the breadth of the Amazon's offer but I think that too much choice (if you sum AWS + Google Cloud + Azure) can make decisions hard sometimes.
At least it's creating a ton of articles in the style "this technology vs that technology" :-D
As far as the reimplementation goes, I'm just glad that a lot of these hardcore necessary features (eg. the iso conversion) is based on a spec which should, theoretically, make it much easier to convert. You're not reinventing the wheel, you're just building it from another material...if that makes sense.
The AWS dashboard is absolutely overwhelming and I do feel like unless you spend time researching and learning the tech, it can be nearly impossible to make a right decision and decipher what all of it means. Like Cognito. I had no idea what it was until our company started getting into authentication providers. Or what's the difference between RDS and Aurora? Etc. It's A LOT.
And yeah, on top of that, all these cloud providers call these features by completely different names.
I usually enjoy to try new stuff and build something with it just to see how it works in practice. Then, periodically I decide if that language/tool can be part of my toolbox (which usually implies excluding something else already present and study more details of the new one).
Actually my stack is:
I’m not scaried when I see a new language/stack/framework, instead I’m excited to give it a try. It might be the next entry in my toolbox. In the worst case, I can express an opinion about it ;-)
I've given up on Linux on desktop a long time ago to be honest and I've been using OSX ever since. It's not perfect but it's good enough for me and it has everything I need.
hahaha yes :-) I don't disdain new tech, I'm not a luddite, just saying out loud that sometimes I think we have too many similar technologies :-)
Yeah, me too, I use macos since 2012, I’ve been on Linux since 1999. Then, even on servers, I strongly preferred FreeBSD over the many distros available (I was Slackware and Gentoo user, switched to Ubuntu years later for lazyness). Give it a try on VirtualBox if you never used it ;-)
I mostly agree and I think there are several reasons behind this, however it’s not a concern for me. I mean, I see this as a larger pool to pick from when you’re looking for something different or better, for fun or profit, whatever 😉
I’m seeing Linux on Desktop succeed in super-linear growth, so I don’t think there is a reason to give up — we just need to have the breath to walk the long road:
(→ source)
I understand, it could also be that Chrome OS is integral part of that but I have been using OSX since 2006 and I love it. I'm honestly happy about it and I have a totally lazy approach when it comes to the operating system.
Anyhow, I'm also happy about the rise of Linux.
As I already said, I’ve started on Linux in 1999 (I mean 100%, full time, even being the only one in companies where I worked) and stopped using it in 2012. As you can imagine, I was more than patient with it, then I realized it wasn’t for me anymore (I personally think that it sucks right now for tens of reasons, but I understand and respect who uses it, of course). I don’t care if its user base is growing if it can’t offer a flawless experience. I still remember when Gnome devs were more focused on fancy (and crashing) window manager fx while as of today it still lacks a coherent desktop experience between apps. On the server side things aren’t better, considering that systemd almost ruined any chance of decent administration (such as silent fails and binary logs just to name a few examples, crazy!). Still, people uses it, I hope they’re fine, not for me anymore.
systemd is one of the reasons why I worry about GNU/Linux. At home I’m avoiding systemd completely, but I’m not happy that I have to. I understand people who use it, because I once cheered for pulseaudio — until it bit me again and again — and systemd plays the same game as pulseaudio: somewhat working tools built on badly maintainable foundation with lots of problematic politics, but "just follow us" solutions to problems many devs face. Essentially a golden trap people willingly walk into. Like OSX, but I can still avoid it.
btw @andreapavoni , do you use Elixir at work or just your personal projects?
I started with some personal projects in 2015, then I did some professional work (2 apps deployed) during 2016-2017 and continued developing a bunch of personal projects and published packages on hex.pm. Last month I’ve started working full time on Elixir for a company, I’m lucky enough to use my toolbox (well, it’s the same compared to the tools they use, except for Linux/Docker)
Nice!
Oh for sure,
This is one of JavaScripts biggest pain points right now from “outsiders” that you could honestly be only following JavaScript development and still experience developer fatigue. This is largely in part due to the fact that even though JS has been around for about a decade, it only really got most of its QoL and meta programming enhancements that make people think of it as a mature language within the that past couple of years.
Wanting to be a computer scientist has a very conflicting duality that people have to balance to do well. With CS covering almost every field of human endeavor it can be very easy to get lost in what topics to pick. But even once you pick a topic to study you must remain focused as too not experience a burnout amount of fatigue. This conflicts with many people’s curiosity that makes them want to “learn all the things”.
You must be very careful in what you learn while still “learning all the things” so that you can advance your breadth and depth of knowledge.
Yeah I feel you. I was just talking about software dev, if we include the whole CS... well, that's A LOT :D
Learning all the things (not just at work but in life) can be troublesome yes.
My main fun language nowadays is Scheme, an IEEE standard and started in 1975. I see it learning a lot from Python — the first language I really liked.
The main evolution I see is Rust, which enabled faster implementations of , but I did not play with it, yet.
I see people do interesting things with Go, but I also begin to see articles about "what Go did wrong". And Python is showing its cracks as it is pushed into more domains. And I expect many of the new languages to show cracks, too, because it is much easier to build an elegant language when you don’t want to support all domains, but once you get big, many people will either push you into those domains or abandon you for other languages which they can use everywhere.
At work I now use Java, and it’s not that bad — but it got a lot better in the past 10 years. Though I found features people wish for that are already supported in Fortran.
And in tooling I see a lot of build tools which fail at delivering what autotools already does.
The main gripe I have with this is that we as a community are investing much more into trying cool new halfbaked things than understanding what already exists.
Hi Arne, you brought up so many memories.
I still have a Common Lisp book at home though I forgot most of it. I used to play with SBCL on Ubuntu Linux.
I agree that the more domains you tend to cover the shorter the blanket is for some of them. Basically every domain has more specialized languages than the general purpose one but the power of the "good enough" is not to be underestimated, especially when it's now quite easy to have apps written with multiple languages (through embedding, FFI or client-server architectures). Let's also not underestimate the fact it can be hard finding actual developers for this or that technology (well, you can train them...)
My two cents of Java: I don't know, on the surface it seems like Java has been given a second life thanks to Android, on the long term I see it being abandoned there, though the JVM is a super solid technology and it will survive "forever and ever". I don't really follow the Java enterprise world (or what it's called now, I'm never sure) so mine it's an entirely superficial opinion, I will admit it.
Well, it's all fault of the millenials ahhahaha
Thank you for your answer! I share some worries about Java, mainly due to the breaking changes in Java 9+. But it’s what currently pays the bills, and it is much better than I had remembered from around 2004 ☺
I wish I could say that, but I used to do the same. And at some point I learned. I went from cmake over scons and waf and python build tools, until I finally settled on autotools, because all the rest turned out to be worse on the long term.
Maybe it’s more related to the massive growth of programming as a job, so organic information flow does not suffice, and those who advertise their tools a lot reach many people who don’t know the old (and free) tools.
And they build the tools you need.
I recently found the saying: "a million flies might be wrong, but they create the one-thousand tools you need".
I follow along with many programming languages, but I don't try to learn it all. I'm aware of a lot of interesting features in Rust which give me context I can bring back to some of my work. Same with Java, Go, Elixir, Elm, C++ and everything else out there. For me, fatigue sets in when I try to get into the weeds with it all.
I used to be much more loath to acknowledge I can't, and haven't, learned it all. (Or anything remotely close). I haven't explicitly specialized but I've reduced the scope of things I try to truly learn all the way through. I bite at enough to know why I might dive all the way in on something.
I do think these sorts of consoles induce some fatigue through design itself though. Info hierarchy seems to be lacking in these situations.
I used to learn languages "just because", for that very reason: new paradigms and approaches open our brains a little bit you can "bring back" stuff to use in the day do day (Haskell excluded, I gave up long ago :D).
I have to admit I do it less nowadays, mainly because I have less time and because I am more selective I guess.
This is not an issue of merits but (for example, and please Java devs don't take it personally) I don't see myself learning modern Java unless it's required for something at work (which never happened so far). The last time I used Java I was in university.
This doesn't mean I think Java is garbage, on the contrary, it's just not my favorite language and I don't have enough compelling reasons to do it (less so that Google is endorsing Kotlin and Dart for mobile dev). Same goes for other languages.
Over the years I cultivated my Python niche I guess (I had a job involving C#/.NET for a while but that's a story for another day :D): when I started using Python it was seen just as a "scripting language" (which I felt it was a compliment in disguise) by many people and only a few companies in Italy were using it "for real". I kid you not, in the country we probably all knew each other online or in person or at least knew of each other. Every Python developer was on the "python-it" mailing list :D Now Python is so widespread that the salaries are actually going down :D.
Elixir is even in my bio on dev.to, that's how much I like its premises, but I never find the time to actually learn it and use it :D It's just a wish for now, derived from my love of Erlang and declarative programming.
I'll just wait for someone on dev.to to write about it :D
That's why we should all use my favorite language for everything. *ducks*
Serious answer: I think the "problem" is that every language has its own model of the computational world, and every programmer does too. Also different people and languages value different parts of the software lifecycle, e.g. Python is supposedly optimized to be read, whereas Ruby I would argue is about writing in the most intuitive way. Java seems like it's meant to make the enterprise architect's job enjoyable.
But maybe we can all get what we want with more interoperability. Most languages have a C foreign function interface (which doesn't mean whatever library needs to be in C, it just means it needs to also support that FFI). Some have implementations for the JVM/CLR or JavaScript interpreters/compilers.
On the other hand, this might lead to everyone having to deal with codebases in five different languages. Not that hard actually, but occasionally annoying.
Over a longer term, I think there will be some language people realize is pretty good at doing everything and we'll end up standardizing on that. But then maybe some other language(s) will start eating its lunch and we'll be back where we started (but with better languages overall).
I don't know. I think we'll have software generating software by then and solve the problem at the root :D
All these languages are super fine but we talk A LOT about code reuse but then anytime there's a new language we have to reimplement all the building blocks from scratch.
Maybe the best approach is something akin to OTP, which is shared by all the languages around Erlang?
Why do we need to re-write standard libraries for each and every language? I know the answer but still, maybe one day we won't have to.
In other words we're the problem. 🤔
Not necessarily but we tend to "fork" instead of "merge" a lot.
We tell ourselves there are perfectly reasonable technical motivations for this or that new technology to be totally incompatible with the other one yet created to solve the same exact purpose :D
I'm mainly working with MS Visual Studio, and C#/Entity Framework/SQL-server at the moment.
The .NET environment encourages the development of other languages, and the reuse of "binary" (semi bianary by MSIL Vitual Machine like the Byte code in Java).
This makes it possible to seamlessly building components in any .NET Compliant (CLR, Common Language Runtime) language. The code is compiled to a DLL and is very easy to use in another lagnuage.
This has the effect that I, in my favorite language C#, can use components written in Visual Basic.NET, Visual Cobol.NET, Visual Ruby.NET, Visual PHP.NET, Visual X.NET-language .....
The CLR/MSIL/.NET aproach has made this possible, and a software company that develops a completely new language actually don't need to rewrite any of the .NET libraries that already exists. But it is still possible for the developer to use the new languages syntax to use the components. This is a really good thing!!! Ver good reuse of existing codebase, indeed!!!!
I definitly think new languages will arise in the future as well as they do today.
The learning curve will be less steep and the reuse of already written and tested code in the form of DLL components will increase amensly.
We have already seen this happen when the mono-project in Linux now is pretty good at implementing the CLR and .NET environment.
It is very easy to build my entire software with EXE-files and DLLs in an Windows 10 envisonment and Visual Studio and the just copy the files over to a mono-installation in most Linux distributions like Ubuntu, Debian and hardware like Raspberry Pi. It's not perfect yet, but most of it works pretty well.
The future problems will not be the languages but the 3rd-party or custom components, that has to be consistently documentet and maintained.
Yes, having a common runtime is very handy. It allows to share knowledge and pick your own favorite language. I think it's one of the reasons that allowed .NET to remain relevant all these years.
I guess it's more or less the same with the JVM.
It is certainly a way to settle on a common implementation of the main building blocks and focus on productivity or proposing new approaches for such building blocks.
The fact that the author has chosen to write this kind of article is an indication of the stresses, strains, and weariness that is now infesting the software profession.
The ideas that innovation is great and change is a good thing are complete nonsense as both concepts are merely buzzwords for vendors and individuals to hype their latest developments.
The problem our profession has today is that it has way too much of a good thing because it has become so easy to develop new tools and frameworks and as a result, everyone is now doing it. This has taken a sever toll on the professionals involved in our work.
It all began with the Open Source movement, and though a good thing, basically "commoditized" software development into something that should be given away freely. This in turn destroyed the flourishing "cottage business" of professional development that allowed us software developers and engineers to create new products and make a reasonable living off of them.
What do you have now? Because of Open Source, the major vendors now control who gets to make money.
Open Source paved the way for what this author is writing about where the profession has too many tools, too many frameworks, and too many languages.
There is really very little need for more than handful of languages that provide the overwhelming majority of capabilities today that application development requires. Such languages would include C\C++, Java, C#, and the venerable VB.NET. There is nothing that cannot be written with these languages and this includes everything from artificial intelligence to games alongside the massive development requirements for business as well as those for consumers. And all these languages can be used for every platform now available today.
So why do we need so many other languages, very few that will ever attain the massive community support that these aforementioned languages all have?
Human Stupidity for the most part...
Today's world, especially in the United States, is all about "ME"! How do I feel better about myself? How can I create something that I will be proud of? How will doing so affect my presence in the world? ME! ME! ME!
And it follows consequently, to our profession as well. This has been all brought about as a result of the maturing Open Source Movement and the "junk technologies" that infest everyone's daily lives; from smart-phones to smart refrigerators. Not a single decision needs to any longer be made using simply one's own brains; we have technology for that.
This social devolution plays out quite seriously on the pathetic social networking platforms where everyone is allowed to expose themselves to their heart's desires while demanding of all things that the platform vendors for these stupid tools provide privacy for everyone's exposures.
Human Stupidity at its most paradoxical.
The outgrowth of all this has been the constant barrage of new languages and tools to promote a microcosmic society within our own profession that is all about the disjointedness that all the previous creations mentioned have developed for the world today.
It is no longer "cool" to turn to a standard 3rd generation language for our work. We now need some new, "cool" language that has a unique feature or two to create our next great, development effort. We need a myriad of tools and frameworks so we have a variety of choice to decide, which one would be the best for the job. And yet, who any longer really does any in depth analysis as to the feasibility of so many tools? No one really.
Instead, we have JavaScript and its many foundations flushed into the profession as some type of "go to" resort for just about anything that can be produced for the web.
And yet at the same time, people scream for performance. How is that supposed to work when using interpretive JavaScript in an application infrastructure that doesn't even have proper and compartmentalized tiers implemented.
In addition to this, our profession stuffs everything it can on the Internet, whether it needs to go there or not. To develop an efficient client-server application is almost taboo since it is not "cool" as it is not on the web with all its interdependent complexities.
After 42+ years in the profession, from which I retired from in 2014 to continue with my own development efforts, I saw what was once the "crown jewel" of the US economy spiral down into nothing more than a profession flooded with "gibberish" replacing hard won knowledge bases with levels of standardization that were implemented by the vendors to a good degree to what we have now where there seems to be nothing but buzzword terminology to replace hard-core understandings as to how high quality applications are to be built. We have Agile, Scrum, DevOps, design patterns, and god knows what else to push any rational decision processing into the realms of fantasy since all the necessary design foundations were already there founded upon decades of research and experimentation that proved their worth.
This is not the first piece to ask such questions about the realities of our profession and most certainly will not be the last.
And will be up to the younger professionals to determine what type of profession they really want. One that is continuously flooded with junk technologies each and every day or one that has a sense of sanity and purpose that is encompassed by a standardized set of practices and tools so that quality application development can be produced instead of what is good for "ME"!
I think one of the reasons for these problems is the way information flows: Via talks and advertisements instead of via investigating options in depth.
haha very pragmatic :)
Here, we will talk about all the accessible under graduate course programs in designing one by one.
View more