Slashdot Mirror
Ask Slashdot: How Will You Be Programming In a Decade? (cheney.net)
An anonymous reader writes: Programmer Dave Cheney raised an interesting question today: How will you be programming in a decade? If you look back to a decade ago, you can see some huge shifts in the software industry. This includes the rise of smartphones, ubiquitous cloud infrastructure, and containers. We've also seen an explosion of special-purpose libraries and environments, many with an emphasis on networking and scaling. At the same time, we still have a ton of people writing Java and C and Python. Some programmers have jumped headfirst into new tools like Light Table, while others are still quite happy with Emacs. So, programmers of Slashdot, I ask you: How do you think your work (or play) will change in the next ten years?
With a gesture-based interface connected to my fishing rod.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Learning new languages every six months in a young man's game. As I get older, I will gravitate towards jobs where I can leverage 15+ years experience in a language to get better-paying positions.
It will all be done either in India or via automation.
I'll be programming the same except using Cherry MX periwinkle switches instead of the current blue ones I have now.
In ten years I intend to be programming in management speak, functional specifications and almost completely useless and barely intelligible pseudo code.
Poorly.
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
It seems to me that you need the languages with the right features to be able to implement good tool support. Consider the excellent IDEs that have been created for Java (Eclipse, IDEA, NetBeans) with extremely advanced refactoring capabilities, code navigation, and inline compilation with meaningful error messages. Such support requires the ability to do static analysis, which you can't do properly in some of the newly popular languages like JavaScript.
The article is like, "Hey! Look! Android! Containers! New execution environments! IDEs!"
Meanwhile I learned to code in Quick Basic 4.5 in a procedural model. I then started doing functional programming in C, and that whole "modular" thing where we break out programs into chunks. Object oriented programming was in relative infancy, and I learned that when it was just wrapping up related stuff into objects.
We now have more complex design patterns. The Gang of Four book and Code Complete are a mess to read; Tony Bevis did a better job writing a clear, concise explanation in C# and Java.
It's not the tools and the languages; it's the method of problem solving. Project Management today is not the same as Project Management in 1980 (I'm CAPM certified). Engineering isn't the same. We've created new construction techniques, not just new materials and tools. Programming hasn't just advanced in terms of languages and system platforms; we've created new methods for writing enormous programs without doing a shitton of refactoring.
I haven't assimilated the new methodologies yet. I can't plan in a grand scale using those tools; my brain knows how to use the old ones and can project at low resolution, then fill in all the gaps at high resolution. I need to burn these new abstract factories and decorators and other bullshit into my contextual thinking before I can just throw down immensely-complex, well-architected computer programs. I know the whole deal with being from the old school, and i know how hard it is to change; I also know what worked for the last set of problems doesn't fit this new set. That's sort of foundational knowledge for me: the correct approach depends on the problem, not on what your favorite tools are.
Support my political activism on Patreon.
CI/CD systems will automate the heck out of everything, and there will be less and less visibility into what's running where and how.
"Cloud Native" applications designed around microservices with well-defined interfaces and running in some PaaS "somewhere" will become the norm. I sadly foresee that developers themselves will be expected to become microservices, basically expected to do one thing only, and one thing well, and forbidden to look beyond their immediate horizon of the ever rolling Agile backlog. There will be less space for creativity at the individual level, and massive invisible machine learning software running in the back-end of the datacenters will automatically generate "facts" for the suits in charge, and possibly even stories on a backlog based on those facts. In 20 years, they'll generate their own code.
BATCH files are DOS you n00b, and they're written in EDIT for DOS!
You are behind, dude, Cherry MX Periwinkle Switches Reloaded++ is now out.
Seriously, who the hell knows what's 10 years down the road. The industry is driven as much by fads as logic, if not more.
I just hope the UI side simplifies so that one doesn't have to say diddle with the minutia of scroll-bar coordinates for everyday GUI idioms and bread-and-butter CRUD. I'd like to focus on domain logic rather than micromanage UI glitches all day.
UI's are f8cking mess unless you target a specific browser brand and version. We devolved from the desktop days. I pray the industry cleans up the UI mess created by the browser. Unfortunately the industry seems to be chasing eye candy fads instead instead of practical things, but I guess the money is in hype and flash.
In summary, get off my UI lawn!
Table-ized A.I.
Ten years ago, I was coding gnarly C++. Today it's even more gnarly because the projects are bigger and the problems more subtle. I think my only way out of this trap will be to make a conscious decision to stop, but even if I opt out, others will be in there doing the same basic stuff to make everything keep running.
The Objective-C knowledge I began developing in 1988 will probably be less useful in ten years, though. If you had asked me in 1995 if I would be intentionally avoiding Objective-C work in 2015 because of burnout, I would have laughed at you.
I hope that my Perl knowledge will be useless in ten years, but I fear that it will be the most lucrative system I know.
In the 80's, software-engineering was an optimistic industry, structured programming had helped so much, object-oriented programming seemed likely to make things easy, logic programming was going to automate a lot of stuff, we were going to move upstream to direct solvers and provers. Sometime in the 00's, everyone gave up and decided that optimism was overrated, software-engineering would never earn the "engineering" part, so instead let's just try to mitigate the vicious cycles to keep them from going too far foul. I think in ten years, things are going to look basically the same as today, with minor evolutionary additions, and we might even argue about whether things have changed enough to be worth talking about.
If you'd told me 10 years ago that I'd mostly be programming in LabVIEW today, I would have laughed. It's "not a real language". It's proprietary. Manipulating graphics takes so much longer than typing. Etc.
I still don't like that it's proprietary.
I suspect given the trends of the past decade that there will be more pseudo-code looking scripts written in language du jour, than actual code. API calls, to API calls that invoke still other APIs, without any understanding of what is actually being executed or on what platform it is executing. There has been a lot of effort put into making 'coding' simpler and more distributed which has many faults. First and foremost the simpler it is to code, the dumber our coders become. Similarly the more distributed we get, the harder it is to diagnose problems.
It used to be that a good debugger was all you needed. Now you can barely even tell what is going on without a sniffer trace, and even that will leave you wanting for some piece of the puzzle. I'm not suggesting a return to the days of COBOL, but not all advances result in better code.
>> a runtime that runs 100% the same on all platforms
(spits out milk through nose)
Random feminists do not have access to your birth records. So in the future when anyone can get a CRISPR (or whatever) genetic treatment and suddenly look like a 25-year-old male or female of their choice, this stuff will largely be irrelevant. If there's hordes of stunningly gorgeous, 25-year-old women working in tech jobs, no one will be able to figure out, without some serious digging, if they were actually born female 25 years ago, or if they're actually 75-year-olds who used to be beer-bellied, balding men.
My Scrum Lord says that I'll drive peak stakeholder value for a billion years if I but open my heart to the One True Methodology.
There's a wealth of new research going on in Programming Language Theory, with several breakthroughs in the last years bridging the gap between functional and imperative programming.
The other trend in declarative programming is reactive languages like React.js and Flux being applied to user interfaces. This allows for tools like React Native which can abstract away all the spaghetti code to handle events, providing a higher abstraction, including the "debug & rewind" and "live programming" capabilities seen in online "web embedded" environments like Github Gist or JSFiddle.
I expect that, as these techniques mature, they will settle down and allow for development techniques that allow for easy discoverability of APIs without having to learn a particular complex syntax, and better programming by connecting components without the drawbacks and limitations of classic Visual tools.
All these new techniques based in Category Theory are driving advances in mainstream languages - starting with libraries like Linq and jQuery but also Python, Javascript and even C++ adopting lambdas, advanced type systems with auto-inference of types, and libraries with constructs for declarative race-free parallelism such as promises and agent models.
The majority of those techniques are being tested first in experimental languages by researchers eating their own dog food, with Haskell often having its most pure form (see what I did there?). Anyone interested in enhancing the expressivity of PLs may lurk Lambda the ultimage, where guys much more clever than you and me hang around and can give pointers to all the relevant theoretical results.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Use my neural interface to write a program to a data crystal that can display on the holodeck. Then leave work in my flying car.
[Insert pithy quote here]
Lol.
Yep, I'll be living as a woman in 10 years, unless I die homeless in a gutter. There really is discrimination out there. It's just that it comes from management. But blame me! Sure, that's done a lot of good to fix the problem!
I will not be programming, at least not professionally. The gender insanity will continue in tech. I can't change the gender I was assigned at birth. That's a matter of public records
The requirements for changing the gender marker on birth certs, etc., has gotten a lot easier since the turn of the century. It's in recognition of several facts:
And of course there's this. Genes don't count for everything - but we already knew that :-)
I don't need to look forward to a future about arguing about whether I'm a "real" woman or just an invader with a woman-suit who's "really" just a cit het white male shitlord underneath, keeping "real" women from getting programming jobs in some vast, insane conspiracy.
... but you WILL be able to help any employer check off a few boxes in terms of diversity ... vive la difference! We have been dealt a double helping of problems, might as well take advantage of them where we can.
And most people don't really care. The TERFs (eg: Germaine Greer) are so ancient history ("what, you mean she's still alive???") that the only people who pay them attention are other TERFs and people looking for click-bait. They can go screw themselves because nobody sane would. want to.
As for Briana Wu - nobody wants to be pretty much universally known as an ID-10-T.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
I directly load programs into memory though the tape-in port by modulating my flatulence into a microphone.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
We devolved from the desktop days.
Oh yes. One of the worst things that browsers did was virtually destroy the ability to use shortcut keys to do useful work instead of having to grab mouse and irritate carpal tunnels. All the shortcut keys now either do nothing or control the browser, not the app in the browser.
Plus far too many webpage authors don't leverage what few amenities we could have. For example, how many form-based pages have you visited where there's a preselected input where you can start typing instantly instead of grab-mouse-and-click before you start typing?
And don't even get me started on the drag-resized panes where the "drag grab" area is so small that you have to have machine-like motor skills to be able to mouse over it, click down, and drag without losing the whole operation.
But when it comes to gratuitous and annoying auto-playing audio-visuals, we're great!
It was assembler first. Then FORTRAN and BASIC and assembler. Then assembler and C. Then C and Perl. Then C and Python.
It's been C and Python ever since.
The shift from assembler was forced on me because the underlying platforms began to diverge; C took care of that, while remaining low level enough not to suffer the slings and arrows of clunk, lethargy, and various types of safety nets of a hoop-jumping nature.
Perl put a moderate amount of readily accessible speed and a great deal of power on the table. That was a huge step forward and renewed my interest in interpreted languages.
Python took that speed and power and added after-the-fact comprehensibility, a much better syntax, and a brace-free indented coding style that I found very attractive and readable, which in turn enhanced the power I was able to effectively leverage considerably.
Since about 2002, when I first began seriously developing in Python 2, I have been watching for a similar gain in comprehensibility, convenience and so on as was brought to me by Python, over Perl. Nothing I've seen thus far has come even close.
As for c, it's been flat-out unbeatable at the low-level for me in my post-assembler phase. I can't imagine something that would be both as close to the metal, and yet as amenable to high level concept implementation. I'd love to see something like that, but so far, the closest attempt, C++, has not come all that close for me. Objects with built-in methods are very easily (and much more efficiently) done in c. Classes themselves are nice-ish, but certainly they are not required. Organization of functionality is what they really do for most people, but I am already pretty organized, so C++ classes don't offer me much there (in fact, sometimes C++ classes get in my way.) Most of the rest of C++ is of little interest to me.
I'm always curious. C++, Objective C, C#, Go, Swift, Java... these kind of things attract my attention like a bee to pollen. But so far... Python 2 and C remain -- by far -- the most attractive and certainly the only ones in daily use.
I understand the urge to make a new language. I've felt it and succumbed to it myself. Not once, but several times. No general purpose languages, but specialized things like macro languages and KB languages and ray tracing languages and PCB layout languages. I really, truly appreciate that so many people have actually gone ahead and created general purpose languages and made them widely and freely available. Lots of people have different tastes and interests as compared to mine, and all of those languages being out there keeps everyone thinking and the underlying tech churning in such a way as to produce lots and lots of useful things.
Personally speaking, though, it's been about 13 years since anything in this area caught my interest to the point where I actually wanted to use it in production. I would like that to happen. But honestly, barring something that writes good code for me (not in the cards quite yet), I have a lot of trouble with the idea that with all these people thinking about computer language concepts over those years, that there are many (or any!) concepts left that would result in such an advance.
C (in my case) has an advantage in that for the various concepts I've really liked in other languages, I've built those facilities in C so I have ultra fast and lean instances of those particular functionalities. List handling; dictionaries; threading; regular expression handling; PostgreSQL and SQLite interfaces; memory management; input sanitization; etc. At this point, if I like a language concept, I'm more likely to implement it so I can have it available in C than I am to adopt the language that carries it.
Python... I really, really like Python 2. The only thing I don't like about it is the inability to extend a built-in class, for instance string handling. Sub-classing doesn't help when every instance of a subclassed-string utilizes the built-in class, because inevitably, the bui
I've fallen off your lawn, and I can't get up.
After nearly 20 years doing this, I believe that what software developers actually do all day long is primarily ontology, and secondarily engineering. Conceptually fitting the real world into a little box filled with transistors is hard. You can't automate thinking (at least not yet). The computer world is a limited representation of the real world, and that translation, deciding which things to take and which things to leave, and what shape they take in the virtual, is something that a computer cannot do, and sure won't be able to in 10 years time, possible even in a 100 years time. Until then, programmers will be doing the same thing they do today, just in a slightly faster format with slightly updated tools and slightly slicker interfaces: crafting a virtual and limited representation of the real that allows modeling and the generation of knowledge and value from information from data.
Everyone is living in a personal delusion, just some are more delusional than others.