Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Technologies Changing What It Means To Be a Programmer

Posted by samzenpus on from the keeping-up-with-the-times dept.

snydeq writes Modern programming bears little resemblance to the days of assembly code and toggles. Worse, or perhaps better, it markedly differs from what it meant to be a programmer just five years ago. While the technologies and tools underlying this transformation can make development work more powerful and efficient, they also make developers increasingly responsible for facets of computing beyond their traditional domain, thereby concentrating a wider range of roles and responsibilities into leaner, more overworked staff.

11 of 294 comments (clear)

  1. Not changed much by jmyers · · Score: 5, Insightful

    I don't see many changes. Vendors, managers, and salespeople change the buzz words every few years and talk of great paradigm shifts. Programmers continue to write code and produce actual results. In a perfect world the programmers get to choose their own tools. In the real world we have to use whatever buzz word compliant tools are thrown in the mix each year. They never actually live up to the hype and you have to dig in and find the code buried within and build stuff that works. I remember when the salespeople were touting dBase II and how programming would be completely changed. Right.

  2. COBOL was better than JavaScript. by Anonymous Coward · · Score: 5, Insightful

    As a former COBOL programmer way back when during the mainframe era, and as somebody who has had to develop and maintain JavaScript code over the past several years, I can say without a doubt that I much preferred using COBOL.

    Although COBOL is a verbose language and not always the easiest to use, at least it isn't shit-for-brains stupid like JavaScript so often is. When I use JavaScript, I often sit there wondering, "What the fuck was Eich thinking when he came up with this stupidity?" and then I wonder, "Why the fuck hasn't the JavaScript community fixed these fucking stupid misfeatures?"

    So many things about JavaScript are just so stupidly broken, and there's absolutely no reason why they should be like that. They're so idiotically wrong that it's totally worth breaking compatiblity with existing code if it means fixing these problems. COBOL, while not the best language, was never anywhere near as fucking moronic as JavaScript usually is.

    1. Re:COBOL was better than JavaScript. by Anonymous Coward · · Score: 5, Informative

      Someone who writes JavaScript every day and claims that "nothing at all" is broken is either lying or a real moron. There is plenty wrong and "broken" in JavaScript, primarily the retention of exceptionally poor design decisions that have carried all of the way through to today. Reliance on global variables, indeterminate behavior of "this", semicolon insertion, only having support for IEEE floating point numbers, lack of block-scoping, the syntax for the with block, two sets of comparison operators (one of which makes PHP seem coherent), over 50 reserved words of which maybe 20% are actually used and of those the language isn't smart enough to parse them only in their appropriate context.

      There's a reason that nobody sane (or intelligent) programs in JavaScript without tools that tell you that your syntactically legit code is a disaster and that there are so many languages that transpile to JavaScript specifically to remove the stupidity.

    2. Re:COBOL was better than JavaScript. by Jeremi · · Score: 5, Funny

      To someone who writes Javascript code every day, like myself, nothing at all is "broken" with the language (though obviously, like any language, it could use some improvements).

      Ah, good old Stockholm Syndrome. Don't worry, I feel the same way about C++ ;^)

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
  3. Re:Some of us do still assemble, even now by khasim · · Score: 5, Insightful

    What's not modern about using assembler where it's appropriate to do so?

    Because it is InfoWorld. Seriously.

    Here's item # 3.

    Developer tool No. 3: Libraries

    Do you remember the first time you used a library? But they're new because programmers 5 years ago did not have libraries.

    It gets better:

    Developer tool No. 4: APIs

    Yeah. That's a radical new concept there.

    Fuck it.

    Developer tool No. 6: Browsers

    Tonight we're gonna party like it's 1995.

    And, finally:

    The work involved in telling computers what to do is markedly different than it was even five years ago, and it's quite possible that any Rip Van Winkle-like developer who slept through the past 10 years would be unable to function in the today's computing world.

    No it is not. Not they would not. Windows XP was released in 2001 and there are still people using it. That's 13 years ago.

    InfoWorld sucks.

  4. what a load of utter bullshit by sribe · · Score: 5, Insightful

    I've been doing this full-time since 1985, and the most distressing part is how little real change there has been in all that time!

    1. Re:what a load of utter bullshit by Tablizer · · Score: 5, Interesting

      The hardest part is trying to get a web browser to act like a desktop GUI, which is what customers want. We have to glue together a jillion frameworks and libraries, creating a big fat-client Frankenstein with versioning snakes ready to bite your tush. Great job security, perhaps, but also an Excedrin magnet. What use is lining your pockets if you die too early to spend it?

      It's time for a new browser standard that is desktop-GUI-like friendly. The HTML/DOM stack is not up to the job.

      Dynamic languages (JavaScript) are fine as glue languages and small event handling, but to try to make them into or use them for a full-fledged virtual OS or GUI engines is pushing dynamic languages beyond their comfort zone. Static typing is better for base platform tools/libraries. You don't write operating systems in dynamic languages.

      Somebody please stab and kill the HTML/DOM stack so we can move on to a better GUI fit.

      --
      Table-ized A.I.
  5. No retarded like clickbait retarded by 0xdeadbeef · · Score: 5, Insightful

    The work involved in telling computers what to do is markedly different than it was even five years ago, and it's quite possible that any Rip Van Winkle-like developer who slept through the past 10 years would be unable to function in the today's computing world.

    This is quite possibly the stupidest article ever posted to Slashdot.

    Ok, this month.

  6. Re:We only use JS now? by machineghost · · Score: 5, Insightful

    Yeah, it only runs the front end of EVERY WEBSITE IN EXISTENCE (which includes tons of "serious" SaS applications, and more and more "thick client" sites where the bulk of the code is in JS and the server is just used for database work). But yeah, other than that nothing mission critical at all.

  7. Not that simple by fyngyrz · · Score: 5, Interesting

    While the technologies and tools underlying this transformation can make development work more powerful and efficient

    ...and they can also bury them in irrelevancy. It can make them depend on debuggers instead of good coding practices and skills and self-checking that tend to make the debugger an uncommon go-to. It can isolate them further from the hardware so that the difference between what is efficient and what can only be said to work becomes a mystery to the new-style programmer. It can turn what should really be a one-programmer project into a team effort, where "team" should carry the same negative connotations as "committee." It can move critical portions of projects into the black boxes of libraries and objects sourced from outside the primary development effort, and in so doing, reduce both the maintainability and the transparency of the overall result. Languages with garbage collection can create much looser coupling between performance and system capacity, reducing the range of what can actually be done with them. Worst of all, with all the wheel spinning and checking code in and out and the testing methodology of the month, it can make them feel like they're really doing something worthwhile in terms of time spent and results obtained, when what it really boils down to is something far less efficient and effective overall.

    There's another factor, too; the industry really wants young programmers. The costs are less for remuneration, insurance, and vacation; the families are smaller or non-existent, and these people will work much longer hours based on nothing more than back patting and (often empty) promises. One of the consequences here is that some of the deeper skill sets are being lost because they simply aren't around the workplace any longer.

    I think there is no question that all of this has changed the face of coding. An interesting exercise is to ask yourself: When was the last time you saw a huge project hit the market. Now ask yourself how many little does-a-couple-of-things projects you've seen hit the market in the same time frame. My contention is that there are very few of the larger projects being undertaken at this point, or at least, being finished.

    Just one (retired) guy's opinion. :)

    --
    I've fallen off your lawn, and I can't get up.
  8. Moar old man complaints by istartedi · · Score: 5, Funny

    If you're not writing x86 assembly by hand, you have no right to complain. Then an even older guy goes, "if you're not punching cards, you have no right to complain". Then an even older guy goes, "If you're not flipping switches and soldering wires you have no right to complain". Finally, the oldest man in the room stands up and says: "Before there were machines called computers, there were people who did calculations by hand. They were called computers. Most of them were women. If you didn't marry her, you have no right to complain".

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?