What skills will dominate the software market 10-20 years from now?
- Big companies use C++ heavily, besides being the language for deep learning/GPU programming. Will Rust/Go replace it anytime soon?
- Will React still dominate front end development?
- What about Python and the data analysis ecosystem?
Python and artificial intelligence. Python is growing each year.
Functional languages might increase in popularity due to that will will have plenty of cores and they tend to make better use of many cores. In 10-20 years from now servers will have 256-1024 cores. Multi core programming will be very common.
Opensource since it will be cheaper to assemble software from open pieces than do everything from scratch.
I think that there will be a shift from making software from scratch to assembling pre-built parts. Ie market places might be integrated into IDEs. AI could match desired test functions with pre-built code/market places. I am thinking that some software is still created manually like cars was in the beginning, but in the car industry everything is mostly automated with prebuilt parts, software will make the same journey.
We will also have more power efficient chips that has replaced GPUs for deep learning. Coding these helper CPUs will most likely be required skill set.
Kubernetes and server less functions will be beyond the peak of its hype curve and at the plateau of productivity. Some found Kubernetes too complex to manage and and a new more distilled subset exists. https://en.wikipedia.org/wiki/Hype_cycle
D, Groovy, Rust and Nim is also popular.
I'd like to think that people will come to their senses about Python and use sensible languages for ML + data once they relearn all the problems that software engineers learnt about it all that time ago (fast development != reliable/maintainable development, fast development != easily-scaled development with teams of 10+ etc)
Honestly how is javascript (and thus typescript) ever going away at this point? I honestly mean _ever_. Like until the day I die. Almost the entire web is using it. Frameworks like React, Angular, Vue have made it so I basically don't care that much about javascript. Most of my code is server-side and the client is largely handled by Angular as a framework so the amount of JS I have to write in my angular components is so minimal.
All that being said, I personally am not a fan of javascript.. at all. The learning curve to know what's going on is horrific in my opinion, and code is not meant to be written clearly but have a small footprint which is terrible. It's too flexible.. though typescript has solved 90% of that.
Even if something like Blazor completely transforms the web, it seems like there will ALWAYS be the case for streamlined simple sites that only need very simple javascript transformations..
Anyway- unfortunately I think javascript is here for the next billion years!
I’ve been programming since the 80s. We had OOP shoved down our throats in college (CSU), with FP downplayed due to the runtime cost. Things have changed, and I want to move on.
I wish there was demand for ClosureScript. TypeScript has no support for partial function application and currying, unless it was added very recently.
There are better languages and worse languages. While you can apply good practices and successfully build good stuff using a language designed in 10 days (or a language that evolved accidentally from a templating system), those practices will have to work a lot harder than they would if you had used a better language.
Python has a split user base, where roughly half consists of data scientists who use it by necessity and might not always apply software engineering best practices, but many people in the other half use it by choice because it's a nice language.
I have to completely disagree with you. There is no such thing as better or worse languages in a vacuum. Languages exist in an ecosystem that you use to build things using them. Most best practices you apply as a software engineer are reasonably language agnostic. On the other hand, tooling, libraries, frameworks -- many of these things cannot easily ported over from one language to another, and moreover have taken many billions of dollars or man hours of effort from many people before us to get to where they are.
For what it's worth, you don't really make any arguments as to what makes a language better or worse, and you don't really make any arguments that "those practices will have to work a lot harder than they would if you had used a better language" -- for whom? I have worked with hundreds of talented engineers in my life building codebases that have lasted the test of time and I have never once ran into one who had difficulty making a quality codebase using whatever language they ran into.
Blaming a language for poor code is a crutch, and drawing a correlation between code quality and language is dubious. Which more likely has an outsize effect on codebase quality, that the organization that wrote the code, or the language itself? I'll go for humans as the weak link every time.
1. The quality of your software engineering practices.
2. The quality of the programming language itself, i.e. how well it fulfils its purpose as a tool for allowing the programmer to express their intention through language.
3. The context – interoperability with particular libraries or existing code, availability of programmers and support resources, etc. affects which tools are good choices.
In a particular situation, COBOL or VBA might be the best choice (3) even though they're not particularly great languages (2) and you will have to compensate by increased effort spent on good practices (1) to work around problems with the language.
So what I was trying to say is simply that there is such as thing as better or worse when considering a tool in isolation. A hammer that failed QA and was later fished out of a lake with rotten handle could be used to great effect by a skilled craftsman, but it's still a bad hammer.
For example, if Brendan Eich had six months instead of ten days to design JavaScript (ignoring the business realities of the time), with a few rounds of feedback, would it not potentially have been a better language? What if he only had one day – would the quality of the language be exactly the same?
- Web is too dynamic to say for sure but I don't think we have something that might replace React for front end on the horizon yet.
- This is where Go might catch up but I have nothing to back up this opinion.