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?

Comments

I plan on ossifying

[halivar]

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.

Re:I plan on ossifying

[Anonymous Coward]

Easy enough to move from language to language, but toolstack to toolstack less so. If you've used c++ you can "learn java" very quickly, but learning the increasingly complex libraries and frameworks that tend to accompany it can take awhile. Even if you've worked with similar tools, it can take awhile to learn all the best practices and shortcuts and little nuances.

It even extends beyond programming itself. Methodologies change and the toolstack used to implement those methodologies changes with them. We've generally migrated from bug trackers (bugzilla, mantis, etc) to project trackers (trac, redmine), and chances are in a few years we'll be doing something else.

People joke about old men stuck in their way, but as I get older I kinda get it. After a few iterations my enthusiasm to learn the next greatest thing has waned, and it feels like something I have to do rather than something I want to do, and the gain starts to feel less worth it. Is gradle really that much better than maven? Was maven really that much better than ant+ivy? Once I become a gradle guru, something is just gonna come up and replace it as the defacto, so why even bother?

The only solution is to become a manager and become the roadblock we all hated when we first started.

Re:I plan on ossifying

[Rob Y.]

It's not the language at all. It's the way to structure an application that's changed drastically. I used to write server-based apps, with a smart terminal front end. It made for a nice, simple, supportable structure, with a reasonable GUI. Recently, I've delved into web programming. Javascript is fine as languages go - though the various libraries built around it are probably more difficult to get a handle on. But the main surprise is what has come to constitute an application. To the extent that there's an application, per se, it consists of Javascript code in the browser, with data accessed via services on the back end. And mostly on a single page basis. In other words, the surprise is that there's no module that counts as an overarching 'application' that defines a structure encompassing a large set of functionality. I have no idea how this structure would scale up beyond a small set of web pages. Not scale in terms of being able to support a large number of users, but in terms of anybody knowing (or remembering) how all the bits of code fit together.

Good tool support needs "good" languages

[DaPhil]

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.

Article and comments missing the point

[bluefoxlucid]

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.

Re:10 Years [damned UI's]

[Tablizer]

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!

Re:Easy.

[PolygamousRanchKid]

Not sure how fishing rods factor in.

Fishing rod == retirement. Or at least so I'm guessing.

I'll be retired in a decade, so I'll just be programming for fun. That's how.

Re:Easy.

[hey!]

Well, as you probably guessed I've been around a long time, and this idea comes up over and over again, and it never takes off, and for a good reason. Programming is hard; it's deeply tied to logical reasoning, which in turn is tied to language and notation. Having visual representations as an adjunct often does make reasoning easier, but having only visual representations does not.

Through the years I've met a number of people who claim to be "visual thinkers", but in fact I don't think most people who make that claim are particularly good at visual thinking. What they really mean is they want things kept simple so they don't have to work that hard; when confronted with visual subtlety or complexity they're just as lost as when they are confronted with linguistic complexity. Basically they're mentally lazy but prefer to think of themselves as misunderstood.

Now there are people who are great visual thinkers. Any decent graphic designer is bound to be a strong visual thinker. But oddly enough it's not graphic designers who make this claim. It's usually managers who don't have the patience to read through pages of text; but they don't have the patience to wade through pages of diagrams, either.