• Please review our updated Terms and Rules here

Future of Programming

ziloo

Veteran Member
Joined
Feb 7, 2006
Messages
990
Location
in the basement
With all the humongous/giant/multi billion liner programs in every field/area
already developed, what is the future of programming if not patching the existing
programs together for a new application?

ziloo :mrgreen:
 
IMHO people hardly will program using language like C, C++, Java anymor but will only be busy connecting blocks of pre-programmed modules. Just like quite some nowadays programmers have no idea what ML is or how a CPU works.
 
They are already doing this; look at all the prebuilt library code in many languages (VS C# as one example) - google anything you want to do and there is probably a built in way to do it. This has even made it down to embedded development where they have tons of modules and library code that is supposed to help you put something together "faster". Faster once you learn how to use their code and all of its pitfalls that is.
 
It depends on the problem domain.

A huge chunk of what people want is just business databases, and it has been possible for a long time to create a simple usable database application with just point and click, no code required. For many databases, C, C++, Java, C# and such would be an overkill.

Now, for OS level stuff and applications like word processors, databases, presentation programs, web browsers, and such, that is where you will always need C, or C++.

There are domain specific scientific and statistical programming languages.

It should be about finding the right tool for the job. However, many programmers and managers prioritize job security. So that program that could be written in 5 lines of code using EasyTool has to be a billion lines of uncommented code in C++. And don't get me started about HTML - it's dumb that people want to code or "program" documents manually like a 1970s type setting system.

The future of programing is [Insert your favorite explicative here].
 
Somehow, after almost 40 years of trying, I haven't managed to obsolete myself, or anyone else, as a programmer.

C, C++, Java aren't going anywhere. As they say, Java is the new COBOL, and C/C++ is the mainstay of pretty much everything else.

Javascript is in a honeymoon period, both because of the client browser side and server models, but it's no panacea. It could be argued that Javascript is the second most target as a language to be compiled INTO, behind C and assembly. But Javascript has, and does, suffer in many environments.

Python just nudged Java out of second place in one of the computer language surveys, but I think that's fleeting. As I said, Java isn't going anywhere, the amount being invested in that platform, along with the maturity of that platform give is vast momentum. Java is keeping up with the Joneses.

What is new ("new") is the abundance of readily available infrastructure, notably in the Cloud space. The AWS and Azures offer a host of services that rely on the programmers to knit together with little bits of code.

But, this only goes so far. It wasn't much different before. Theres has been off the shelf infrastructure for ever. The whole "serverless" model that's being promoted to glue the pieces together is not a new model, it's just deploy differently. The difference between a Java Servlet, an AWS Lambda, or a PERL CGI routine is really, really thin. But at the same time, if you want to turn 10 lines of simple code that convert X to Y to one of the most complicated beasts you've ever seen, deploy it to AWS. All of that knitting together can be very complicated and very fiddly. We have people dedicated to doing all that fiddly stuff, and they struggle with it all the time, and it takes forever. Routes, networks, privileges, logging, storage, etc. etc. etc.

Modern developers tend to rush to the internet to solve problems. We're always seeing "How do I do XXX in YYY" questions on technical forums. And what they're asking is not how to do it (write code, duh!), they're asking what library solves their problem and how to make IT do it.

And that's alway a balance. Some times, yea, a library is a really good idea, especially for complicated, edge case stuff. While a simple HTTP request is, well, simple, HTTP, as a whole, is not. Add in HTTPS, and also the modern HTTP/2 and HTTP/3, and it gets very complicated. So it makes sense to find a library that can do the heavy lifting to operate with that protocol well, especially for performance sensitive applications.

But at the same time, for example, I just linked to a library for a simple application that I'm writing. It's one we use the abstracts out AWS, etc. I needed it for a single call, to get a single string from an AWS service. And it gorged my deployable from 5M to 35M. At 5M, it was already "crazy big", but this is downright offensive. But this once dependency is dragging the kitchen sink in along with it. And with modern systems, and modern networks, it's kind of a "35M, who cares!", but I do care and I'll try to cut it down. The thing is, long run, my time to do that is likely worth more than the resources this is consuming.

What many haven't learned, is that even though you found some library to solve some simple problem in your code, they have to realize that they're responsible for all of that code that's coming along. Not just the little routine that they're using. But many don't realize that and can get in to trouble.

Computers have been inscrutable since day one. They're still inscrutable. Computing is inscrutable. Computers are the most pedantic and pig headed creations on this Earth.

Computers today are even worse. What is a computer today? With VMs, emulators, containers, storage arrays, etc. It's not a cpu, memory chip, and a floppy disk, I can tell you that. Even the modern CPUs, with their "machine language" aren't the bottom rung of the device. They run in their own managed environments within the CPU. Heck, there's an OS running on modern CPUs that we don't even see.

There is definitely blue collar assembly level work being done today in the computer space. Folks bolting things together at a high level that they may well not understand.

But you can't keep the pig headedness of the underlying machine from poking through. It's always there, always annoying, always in the way, and it's takes an understanding and special kind of patience to wrangle these beasts in to cooperation (but never submission, good luck with that).

I've always been against the whole "anyone can code" mantra, because I don't believe its the case. It's not some elitist stance, heck no, it's just truth. Not everyone is wired to deal with these awful things. At the same time, it IS much more accessible. End user programming is riding high right now. The things folks can bolt together are truly amazing. But, in the end, they will always rely on thick headed people like me when the computer itself breaks through and rears its ugly head through all the layers of code and abstraction and other stuff piled on to make it easy to use. You can coo coo and feed and train the tiger all you want, but in the end, it's still a tiger, and sometimes the tiger growls, snarls, or attacks.

So, programmers aren't going anywhere. We're the ones with the gun, whip, and the chair.
 
The "silver bullet" of being able to construct a provably correct program hasn't moved much in 30 years has it?

So long as there are bugs, there will be programmers. And vice-versa.
 
Very nice dissertation. Eventually the programmers will be replaced by the machines they serve. I've been involved in some form of electronics all my working life, and have spent as much time in various technical schools and classes as some spend earning their basic college degrees. With all that knowledge and training I'm now a dinosaur in my field. I've seen my profession evolve through vacuum tubes, electro-mechanical positioners, transistors, solid state hybreds, analog/digital whatnots and so forth. It's simple evolution and it can be found everywhere. The craftsman automobile worker now points a robot in the right direction and soon another entity will take its place. But, someone will most probably have to push the buttons to make it all happen, and if I had to jump back into the job market, I'd want to be that person.
 
Back
Top