Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Technologies Changing What It Means To Be a Programmer

samzenpus posted about a month and a half ago | from the keeping-up-with-the-times dept.

Programming 294

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.

cancel ×

294 comments

Sorry! There are no comments related to the filter you selected.

moar idiot coderz (0, Troll)

Anonymous Coward | about a month and a half ago | (#47650889)

"The compiler should write my codes for me," the coder whined. "I don't want to deal with all this technical crap! I have business logic to implement and my roadmap to synergy is on a deadline. I know! I'll use clang. The pretty colors will tell me what to do."

Not that simple (5, Interesting)

fyngyrz (762201) | about a month and a half ago | (#47651971)

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. :)

First post! (-1)

Anonymous Coward | about a month and a half ago | (#47650905)

Suck my dick, bitches...

Re:First post! (0)

Anonymous Coward | about a month and a half ago | (#47651137)

And yet, you weren't first.

We only use JS now? (1)

Anonymous Coward | about a month and a half ago | (#47650917)

now it's all done in JavaScript. The browser, of course, still speaks JavaScript, but so do the server layer (Node.js) and the database layer (MongoDB and CouchDB). Even the HTML is often specified with JavaScript code for a framework like Ext JS or jQueryMobile that generates the HTML at the client.

Really? It's ALL done in JS? As a J2EE/SQL developer, I'd tend to disagree, and so would many, many F500 companies. Yes, JS is awesome, but it is not the tool for every problem.

Re:We only use JS now? (-1)

Anonymous Coward | about a month and a half ago | (#47650957)

Yes, JS is awesome, but it is not the tool for every problem.

If you ask Slashdot, Linux is the solution to every problem.

Re:We only use JS now? (0)

Anonymous Coward | about a month and a half ago | (#47651299)

If you are a nail, the hammer is the solution to every problem.

There, FTFY.

Re:We only use JS now? (4, Funny)

rogoshen1 (2922505) | about a month and a half ago | (#47651411)

Yes,much like with Regex, you now have 2 problems.

Re:We only use JS now? (1)

Anonymous Coward | about a month and a half ago | (#47651805)

and mysql, ooops... not anymore since oracle bought it up...

Re:We only use JS now? (0)

Anonymous Coward | about a month and a half ago | (#47651025)

Yes, JS is awesome

JS is the vehicle for return to the mainframe era. How the fuck is that awesome? All I see is further evidence that human active lifespan means the mean time between repeating precisely the same mistakes is about 40 years. At least this one's about silicon rather than war, I guess.

COBOL was better than JavaScript. (5, Insightful)

Anonymous Coward | about a month and a half ago | (#47651091)

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.

Re:COBOL was better than JavaScript. (1)

machineghost (622031) | about a month and a half ago | (#47651117)

One man's "stupidly broken" is another man's "feature".

Re:COBOL was better than JavaScript. (0)

Anonymous Coward | about a month and a half ago | (#47651141)

No, it's "stupidly broken" in all cases, and when viewed from all perspectives. None of JavaScript's language bugs can be considered "features" at all.

Re:COBOL was better than JavaScript. (3, Insightful)

machineghost (622031) | about a month and a half ago | (#47651379)

To you, someone who obviously isn't a Javascript programmer, maybe. 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).

But I'm sure if I started writing COBOL I'd think plenty was wrong with it ...

Re:COBOL was better than JavaScript. (1)

Anonymous Coward | about a month and a half ago | (#47651163)

OK, I'm going to have to agree with you there. I entered computing at the end of the COBOL era, and it felt like - for all its awkwardness - it was actually written by adults with a particular need, for adults with a particular need. It was designed. It was serious.

Javascript feels like it was written by children who like playing about, and who have genuinely smart guys in the office next door who know how to sell toys to adults.

Re:COBOL was better than JavaScript. (0)

Anonymous Coward | about a month and a half ago | (#47651173)

Other than the "this" misfunction, which is rememdied by the hack defining "that", what are the terrible misfeatures of JS?

Re:COBOL was better than JavaScript. (2)

machineghost (622031) | about a month and a half ago | (#47651407)

Other than the "this" misfunction, which is rememdied by the hack defining "that", what are the terrible misfeatures of JS?

It's not like C/Java/COBOL/FORTRAN/whatever other language someone is used to using.

Re:COBOL was better than JavaScript. (2)

jrumney (197329) | about a month and a half ago | (#47651865)

Worse, it looks like C/Java/whatever, and even references Java in its name. But it is nothing like those languages unless you restrict yourself to a very limited subset.

Re:COBOL was better than JavaScript. (3, Informative)

dbraden (214956) | about a month and a half ago | (#47651293)

Also keep in mind that Eich was given only 4 days to create the language. I agree that things should have been fixed long ago, while the changes would have been less disruptive.

Re:COBOL was better than JavaScript. (3, Interesting)

Anonymous Coward | about a month and a half ago | (#47651371)

I don't think that the 4-days claim is a valid excuse. Eich should have known better. It was the middle of the 1990s, for crying out loud! Tcl was well established as an embeddable scripting/extension language by that time. He should have just embedded that. Fuck, he could have also gone with Perl, which was well established at that point, too. Sonofabitch, he could have even gone with one of the newcomers like Lua or Python. Even going with a simple Scheme implementation, like every undergraduate Comp Sci student will develop at one point or another, would have been better than JavaScript. No matter how you spin it, JavaScript is a humongous screw up. It's perhaps the worst thing ever to have happened to the computing industry, the worst thing to have happened to the Web, and the worst thing to have happened to the charge level of batteries in mobile devices. JavaScript is a total disaster, and it never should have even happened in the first place!

Re:COBOL was better than JavaScript. (4, Funny)

jrumney (197329) | about a month and a half ago | (#47651877)

he could have also gone with Perl

Thank you for your contribution, but if you'd been paying attention, you would have realized that we are looking for ways it could have been done better here.

Re:COBOL was better than JavaScript. (0)

Anonymous Coward | about a month and a half ago | (#47652011)

Yes, Perl is better than JavaScript. That's just how fucking bad JavaScript is. Even Perl, the pile of shit that it is, is more consistent and less-broken than JavaScript. I've maintained a lot of shitty Perl code in my career, and I've also maintained a lot of shitty JavaScript code. Give me the Perl code any day! It may be an unholy mess, but at least it has an inkling of sensibility to it. JavaScript has none of that.

Re:COBOL was better than JavaScript. (4, Insightful)

Snotnose (212196) | about a month and a half ago | (#47651837)

I've used a lot of languages in the last 35 years, I've only actively hated 1. That would be Javascript. I find it amazing you can test your code for weeks, but as soon as you let someone else run it everything breaks in mysterious ways because they have a different environment than you do.

Javascript needs to die, and I'll find another job before I waste any more time programming this POS "language".

Re:We only use JS now? (1)

wiredlogic (135348) | about a month and a half ago | (#47651059)

Silly me. Wasting all day writing m4 macros to preprocess an assembly language. Should be doing it all in Javascript according to Slashdot wisdom.

/. hates JavaScript. reddit and HN love it. (-1)

Anonymous Coward | about a month and a half ago | (#47651119)

Hold on a minute, son. I don't think I've ever seen any /. native express anything but total disgust with JavaScript. It's hated when it's used client-side, it's hated when it's used server-side, and it's especially hated when it's used on the /. website.

The only people who really like JavaScript and promote it are the Silicon Valley weenies who infest reddit and Hacker News. You know, the kids who were only a few years old when /. was created and became popular, assuming they aren't actually younger than it. They might sometimes post here, too, but they aren't /.ers in any sense of the word. They're visitors, not natives.

(And anyone who wants to bring up "No True Scotsman" bullshit, you can shove it right up your arse! Keep your stupid shit like that over at reddit and HN.)

Re: We only use JS now? (1)

dilvish_the_damned (167205) | about a month and a half ago | (#47651609)

Depends, how long did you spend on the assembly language?

Re: We only use JS now? (-1)

Anonymous Coward | about a month and a half ago | (#47651077)

Same her but PHP/SQL. Until js speaks server side... I call BS.

Re: We only use JS now? (1)

Anonymous Coward | about a month and a half ago | (#47651601)

Someone didn't rtf list. Node.js is a runtime environment for running Javascript outside of a browser, like on a server.

Re: We only use JS now? (1)

TheRealMindChild (743925) | about a month and a half ago | (#47651699)

Pfff. Node.js is functionally:

MyString = MyObject.ToString;
eval("MyObject = " + MyString + ";");

and a few bits to deal with different date formats. Nothing about a runtime environment or browser. Simple class serialization

Re:We only use JS now? (1, Insightful)

gweihir (88907) | about a month and a half ago | (#47651319)

No mission critical stuff is done on JS anywhere. This joker confuses GUI scripting and programming. And sorry, JS is a real piece of trash. The only "awesome" thing about it is how wrong it gets most things. Of course, when your comparison is PHP, then JS may look pretty good.

Re:We only use JS now? (5, Insightful)

machineghost (622031) | about a month and a half ago | (#47651423)

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.

Re:We only use JS now? (1)

mjwalshe (1680392) | about a month and a half ago | (#47651447)

so js is basically a vt100 or a 3790 then :-)

Holy old news Batman! (-1)

Anonymous Coward | about a month and a half ago | (#47650933)

That article was brilliant and cutting edge ... well cutting edge ... well cutting edge 5 years ago. Way to give coverage to a crappy article.

Some of us do still assemble, even now (2)

wonkey_monkey (2592601) | about a month and a half ago | (#47650943)

Modern programming bears little resemblance to the days of assembly code

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

Sometimes I do it just because I like it...

Re:Some of us do still assemble, even now (-1)

Anonymous Coward | about a month and a half ago | (#47650967)

I would fire you immediately if you tried to use assembler on my project. Gone.

Re:Some of us do still assemble, even now (0)

Anonymous Coward | about a month and a half ago | (#47650993)

You, sir, will never be a Tycoon of Roller Coasters.

Re:Some of us do still assemble, even now (0)

Anonymous Coward | about a month and a half ago | (#47651009)

Tell us more about yourself and said project so we can effectively blacklist you.

Re:Some of us do still assemble, even now (1)

GiganticLyingMouth (1691940) | about a month and a half ago | (#47651309)

The assembler? Then how do you intend to compile anything into machine code? Must be quite a project you have there

Re:Some of us do still assemble, even now (1)

angel'o'sphere (80593) | about a month and a half ago | (#47651961)

For "compiling" to machine code, there is a 1:1 mapping of assembler, unless you count macros as something fancy.

Re:Some of us do still assemble, even now (1)

Darinbob (1142669) | about a month and a half ago | (#47651365)

What about reading assembler? How do you deal with core dumps? These still exist, and they still exist on new and modern projects. Apparently you don't do systems software or you'd be hiring someone who knows assembler, someone who can write a run time library, someone who can do board bring up, someone who can modify the OS, etc.

Re:Some of us do still assemble, even now (1)

LifesABeach (234436) | about a month and a half ago | (#47651049)

How about the the 200,000 more H1B's showing up each year? I question its impact upon this great nation.

Re:Some of us do still assemble, even now (4, Interesting)

asmkm22 (1902712) | about a month and a half ago | (#47651097)

Just because you can doesn't mean you should. 30 years ago, applications were built with long life-spans in mind, so dropping into very low-level code could make financial sense. Today, programs are generally designed for adaptability and compatibility. The target is constantly moving for the vast majority of applications out there. Dropping into assembly rarely makes sense anymore, because the mantra is "good enough" rather than "best" because even the "best" won't stay that way for long.

Of course, different industries will have different mileage. If you do most of your work for embedded devices or industry-niche things like robotics or satellites, then by all means dive into the 1's and 0's.

Re:Some of us do still assemble, even now (3, Interesting)

Kjella (173770) | about a month and a half ago | (#47651897)

Just because you can doesn't mean you should. 30 years ago, applications were built with long life-spans in mind, so dropping into very low-level code could make financial sense.

No, it was utter necessity. For 30 years ago I hadn't even gotten my C64 with all of 65536 bytes of RAM yet, 38911 of which would be left available once BASIC was loaded. Store one uncompressed screenshot of the 320x240x4 bit (16 color) screen and 38400 of those was gone. If you tried storing the Lord of the Rings trilogy in memory - compressed to ~12 bits/word, you'd get about halfway into the Fellowship of the Ring. True, today we waste space but back then we lacked essential space. Every corner was cut, every optimization taken to avoid using any of our precious bytes. See the Y2K problem.

For a more modern but similar issue, I used to have the same attitude to my bandwidth. It used to be slow, costly (pay per minute) and it was important to use it as a precious resource. Today I might end up downloading a whole season of a show after watching the first episode, go bored after three and delete the other twenty. It's there to be used, not to sit idle. I've got 16GB of RAM, there's no point to waste but there's nothing to be gained by hiding in a 1GB corner. If it makes life easier for developers to pull in a 10MB library than write a 100kB function, do it. If you can get it working, working well and working fast then maybe we'll get around to the resource usage.. someday. It's not a big deal.

Re:Some of us do still assemble, even now (5, Insightful)

khasim (1285) | about a month and a half ago | (#47651161)

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.

Re:Some of us do still assemble, even now (3, Funny)

Darinbob (1142669) | about a month and a half ago | (#47651375)

There is a very tiny overlap between software developers and journalists. And yet the number of software development journalists greatly exceeds the size of that overlap. The only explanation is that there are people who don't know what they're talking about who write these articles.

Re:Some of us do still assemble, even now (1)

disambiguated (1147551) | about a month and a half ago | (#47651953)

They problem is not that they don't know what they're talking about. The problem is that they think they do. There's no excuse for it. Journalists aren't expected to be experts in the things they write about. They're just expected to not be full of shit.

Re:Some of us do still assemble, even now (1)

styrotech (136124) | about a month and a half ago | (#47651689)

Yeah, I skimmed the list and there were only a few things that were newer than 5 years old. Docker definitely, node.js is maybe 5yrs old already (but that looks like it peaked - the cool kids have already moved on). Chef is already about 5 years old and Puppet is already much older (and that's ignoring much older config management tools).

Re:Some of us do still assemble, even now (4, Insightful)

Dutch Gun (899105) | about a month and a half ago | (#47651769)

It's pretty obvious this is written through the lens of a javascript-focused web programmer. Seriously, libraries are a hot new trend? That's hilarious stuff. Read each item in this list as "From the viewpoint of a Javascript/web developer...", and it seems to make a bit more sense.

It's pretty clear he only has a vague notion of game development either (my profession), and gets some basic facts wrong. He calls Unity a library (it's a game engine, better categorized as a framework). In a different article, he claims that game frameworks are in, while native development is out. The first part is true, but the second part certainly is not. C++ is still used almost exclusively for large-scale AAA game development. Unless by "native development" he meant "roll your own game engine", in which case he's using the wrong terminology.

Re:Some of us do still assemble, even now (2)

gweihir (88907) | about a month and a half ago | (#47651283)

The problem is that not that many people are able to use assembler these days, because they do not get it. It is still needed in numerous places and if you cannot even do small stuff with it, then you are not a professional programmer.

Re:Some of us do still assemble, even now (1)

angel'o'sphere (80593) | about a month and a half ago | (#47651951)

Sorry,
that is a misconception. "They do not get it" is certainly wrong.
Assembler is the most simple programming "language" in existing, everyone gets it.
... and if you cannot even do small stuff with it, then you are not a professional programmer.
Like you I guess, post your last assembly code otherwise I would say: you are a liar ;D and regarding your post you are an idiot anyway, so who cares.

Re:Some of us do still assemble, even now (1)

Darinbob (1142669) | about a month and a half ago | (#47651355)

C, assembler, VHDL, it still all gets done. But the people who do that sort of work does not have much overlap with the sorts of people who write blogs or articles about how programming has changed over the years.

Reading this article, it's just stupid. Ie, some of these "new" technologies changing how we program: libraries, APIs, virtual machines, developing tools to help development, and performance monitoring. That stuff has existed since the first decade of programming. "New"s stuff includes social media portals. Wow, I don't even know what that is, but it sounds web-ish.

Re:Some of us do still assemble, even now (1)

Obfuscant (592200) | about a month and a half ago | (#47651591)

"New"s stuff includes social media portals. Wow, I don't even know what that is, but it sounds web-ish.

I think that means that modern programming is done via crowd-sourcing, kickstarter, and mechanical turk.

I seem to recall having these modern things called "libraries" when I was programming in small C on CP/M.

Not changed much (5, Insightful)

jmyers (208878) | about a month and a half ago | (#47650955)

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.

Re:Not changed much (4, Interesting)

digsbo (1292334) | about a month and a half ago | (#47651167)

I'm not sure I agree 100%.

As a senior engineer today, I'm responsible not only for knowing the primary back end language (C#) for my web application, but also HTML5, CSS3, JavaScript, and the UI toolkit library. I'm also expected to understand database design, including being able to have an intelligent conversation about the physical schema, and I'm expected to be able to design tables, indexes, and optimize queries. I also have to know security, build tools, the automation scripting language for my platform (now PowerShell), and the deployment system (WiX to create MSIs). I'm also the source control administrator (Subversion).

I also have to read requirements that are maybe 5% of the value of those I got 15 years ago, and be a business analyst to figure out the rest.

Now fifteen years ago, I could probably have gotten away with knowing C/C++, a little scripting in Perl/Bash, and be decent at a CLI. I can probably write a multithreaded TCP/IP server in C without need for Google, which I haven't done in at least 12 years, but have to constantly Google things for what I now do daily.

I don't think things have changed fundamentally, but they haven't stayed the same. We're getting shallower, broader, and less efficient for it.

That's you. (2)

khasim (1285) | about a month and a half ago | (#47651233)

As a senior engineer today, ... those I got 15 years ago ...

That's because you are now holding the position of a senior engineer with 15 years of experience.

Look at what someone who is just starting needs to know. How much different is it than what you needed to know when you started 15 years ago?

Re:That's you. (0)

Anonymous Coward | about a month and a half ago | (#47651807)

Basically, there's no difference: You need to do whatever it takes to fulfill requirements, and you better cut every corner you can because there's never enough time to do it right.

What has really changed?

Re:Not changed much (1)

mjwalshe (1680392) | about a month and a half ago | (#47651461)

So when I worked for BT in the 80's we had to do all that

Re:Not changed much (4, Insightful)

mrchaotica (681592) | about a month and a half ago | (#47651325)

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.

In hobby programming, which is not the real world, the programmers get to choose their own tools. In the Silicon Valley startup bubble, which is also not the real world, programmers have to use whatever buzz word compliant tools are thrown in the mix each year.

In the real real world, programmers use C, C++, .NET, Java, or some other constantly-claimed-by-idiots-to-be-dead language. (And they usually use it to write boring, vertical-market billing software.)

Re:Not changed much (1)

theshowmecanuck (703852) | about a month and a half ago | (#47651477)

I'm not sure I get this need to bash hobby programming. I believe Microsoft and Apple started with hobby level programming. You could say they were 'professional' at the beginning because they started a company, but seriously the only difference at the beginning was the fact they incorporated a name. Some very big things, some very big concepts can come out of "hobby programming". Many people's next big business venture come out of it. I think it is poor thinking to outright slag people's small scale projects they start at home. I think one should at least look at what someone has done before it is trashed.

Re:Not changed much (1)

mrchaotica (681592) | about a month and a half ago | (#47651529)

Where was I "bashing" hobby programming?

If anything, you're the one "bashing" hobby programming by implying that it is at a lower "level" or at a "small scale" compared to professional programming. As far as I'm concerned, the only difference between it and "professional" programming is profit motive (which is also what makes it not "real world," because "real world" refers to the need to earn a living).

Re:Not changed much (1)

tepples (727027) | about a month and a half ago | (#47651615)

As far as I'm concerned, the only difference between it and "professional" programming is profit motive

That and on which platforms people are allowed to do it. The video game console makers have made it clear that their platforms are not intended for hobbyists.

Re:Not changed much (1)

Darinbob (1142669) | about a month and a half ago | (#47651383)

I even remember the days before the word "paradigm" existed.

(yes it's sarcasm you annoying downmodders!)

dBASE [Re:Not changed much] (1)

Tablizer (95088) | about a month and a half ago | (#47651709)

They never actually live up to the hype...I remember when the salespeople were touting dBase II and how programming would be completely changed. Right.

For custom biz app programming, dBASE and clones did live up to most of the hype in my opinion. I was able to crank out small-to-medium CRUD apps pretty damned quick compared to using Pascal or MS-BASIC or C (of the day), and users were quite happy.

True, you were limited on UI conventions, and if you didn't follow certain code conventions, dBASE's loosy-goosy scoping rules would byte you in the ass. But the tight integration between the language and the data simplified a lot of CRUD idioms. And its command-line prototyping was magical.

dBASE got a bad reputation when people started trying to scale its source code size, UI, and market (packaged/box apps) beyond its original niche. If you use a Toyota Corella to haul big trailers, it will indeed fail. Use the right tool for the job and know its limits rather than force things.

I was programming circles around everybody else with dBASE for smaller apps, even against MS-Access (and more reliable). It did well what it did well. Good Times; I miss it.

My list (4, Informative)

Dutch Gun (899105) | about a month and a half ago | (#47651999)

How about we make a list of the technologies that have actually impacted us in a real way over... hmm, let's say the past ten or fifteen years? I assume that everyone will have slightly different items, because we all work in different areas. I'm a game developer and use C++, so my perspective will reflect that. Listed in no particular order of importance:

1) C++ 11/14 - It's transformed the language in a fairly dramatic way, making it much safer and convenient to use, while leaving legacy code completely compatible. Modern C++ code feels a lot more like C# at times, just a whole lot uglier.
2) Mobile Platforms - Mobile platforms (smartphones and tablets) as a rising contender has caused a fundamental shift in the balance of power among platforms.
3) Online Gaming and Integration - MMOs and other games are taking advantage of the ubiquitous connectivity to the internet most of us now enjoy.
4) Distributed Version Control Systems - Modern source control systems such as Git and Mercurial (my favorite) are a boon not only to large distributed projects, but even for smaller developers. Traditional development house, for the most part, still use Perforce, though, which works much better for asset management.
5) Online distribution - The ability to quickly and easily download and update games from vendors like Steam, Gog, and Origin are opening up the market to indie and traditional developers alike, and will eventually kill physical distribution channels.
6) Online resources - Better search pioneered by Google teams up with incredibly knowledge-rich sites like StackExchange.com. The result is that damn near any question you have is likely to have already been asked and answered. If not, ask away, and you have a good chance of getting some real help.
7) GPU programming - More and more visual programming is being off-loaded to the GPU, and those have developed into full-blown programming languages of their own.
8) Parallel programming - With the advent of ubiquitous multi-core / multi-threaded processors in the past decade, game developers had to start getting serious about multi-threaded programming, making an already demanding job even tougher.

That's about all I can think of offhand that's really changed over the last fifteen years. Libraries, frameworks, and APIs are not some new phenomenon. They've been around since I started professionally programming, so it's ridiculous to include those. You might as well add "source code", "compilers/linkers", and "editors" to the list if you're going there.

What about in other professions?

Programming evolves. News at 11. (2)

gregmac (629064) | about a month and a half ago | (#47650985)

I'm struggling to understand the point of this article. May as well have titled it "You won't believe these 15 new tricks for programmers. The shocking truth the devops guys don't want you to know"

Some quotes:

* "Back to work, slave, the continuous build machine has new tasks for you."
* "You're not a craftsman -- you're a framework-tweaker."
* "It's so much easier, but these IaaS administration Web pages won't buy you a drink after work."

Re:Programming evolves. News at 11. (1)

Ungrounded Lightning (62228) | about a month and a half ago | (#47651987)

I'm struggling to understand the point of this article.

It's Infoworld.

The point of the article is twofold:
  - To convince Pointy Haired Bosses that they understand what's going on and are riding the cutting edge.
  - To sell them new products, implementing new buzzwords, which they can then inflict on their hapless subordinates, making their life hell as they try to get the stuff working and into production.

That's the first two lines of the four-line Slashdot meme. The remaining two are:

(3. Bill the advertisers.)
(4. Profit!)

No Assembler? (2)

Ozoner (1406169) | about a month and a half ago | (#47650999)

I think it's the exactly opposite.
The modern programming environment is trying hard to lock the programmer into a box where he can't do much harm...

No one has more control over the computer than an Assembler language programmer.

And there's still lots of Assembly programming going on today.

Re:No Assembler? (1)

Darinbob (1142669) | about a month and a half ago | (#47651405)

Yup. Everyone's amazed at the exciting new worlds of mobile phone apps. And yet, assembler exists underneath that. Someone wrote it. Maybe not the people who responded to the "be a web app developer and earn pennies from your own home!" advertisements. But it exists and those web apps would not exist without it and the people who understand it.

But this is nothing new. Go back 30 years. The vast majority of Unix programmers didn't know assembler either. They were just your 9 to 5 programmers getting the work done on some high level application, leaving the assembler to the mysterious cabal who know the combo to the computer room. However those programmers probably weren't so naive as to claim that no one uses assembler any more merely because no one in their social group did.

Yes, no, maybe, potato salad (2)

jd (1658) | about a month and a half ago | (#47651073)

Modern programming languages are a fusion of older programming languages, with chunks taken out. Often, it's the useful chunks.

There is no table, that I know of, that lists all the features ("significant" depends on the problem and who cares about solved problems?) versus all the paradigms versus all the languages. (Almost nothing is pure in terms of paradigm, so you need a 3D spreadsheet.)

Without that, you cannot know to what extent the programming language has affected things, although it will have done.

Nor is there anything similar for programming methodology, core skills, operating systems or computer hardware.

Without these tables, all conclusions are idle guesses. There's no data to work with, nothing substantial to base a conclusion on, nothing to derive a hypothesis or experiments from.

However, I can give you my worthless judgement on this matter:

1) Modern methodologies, with the exception of tandem/test first, are crap.
2) Weakly-typed languages are crap.
3) Programmers who can't do maths or basic research (or, indeed, program) are crap.
4) Managers who fire the rest of the staff then hire their girlfriends are... ethically subnormal.
5) Managers who fire hardware engineers for engineering hardware are crap.
6) Managers who sabotage projects that might expose incompetence are normal but still crap.
7) If you can't write it in assembly, you don't understand the problem.
8) An ounce of comprehension has greater value than a tonne of program listing.
9) Never trust an engineer who violates contracts they don't like.

Sensationalist BS? (3, Insightful)

Anonymous Coward | about a month and a half ago | (#47651093)

I don't see a single point in the article that would represent any profound change in how programmers work. In fact, points like 1 or 4 are laughable simply because even though these are true, they also happened decades ago. Point 9 is exactly like programming in Lisp (do everything in a single generic language), the only difference being using Javascript instead of Lisp. Others are of interest as deployment techniques, not as a programming workflow change. Etc.

Re:Sensationalist BS? (2, Informative)

Anonymous Coward | about a month and a half ago | (#47651207)

If containers, continuous integration, Iaas, Paas, and other "deployment techniques" aren't dramatically impacting your workflow as a developer, then you're almost certainly wasting a lot of time.

Vagrant + Puppet/Chef = clean new test machine, configured & installed exactly the same way... every time.
Docker = "all my dependencies always travel with my application."
IaaS + PaaS = "if I need a bunch of test nodes to work with, or prototype something, I push a few buttons and wait 20 minutes, at which point my completely fresh test nodes are ready to use."
Continuous Integration = "I can tie all of this stuff together in an automated fashion, so that I don't waste a shitload of time... I commit my code, and elt the automated system run it through all the test cycles it needs."

If you're not taking advantage of a lot of these techniques & methods, then you really are missing out.

Re:Sensationalist BS? (-1)

Anonymous Coward | about a month and a half ago | (#47651671)

Vagrant + Puppet/Chef = clean new test machine, configured & installed exactly the same way... every time.
Docker = "all my dependencies always travel with my application."
IaaS + PaaS = "if I need a bunch of test nodes to work with, or prototype something, I push a few buttons and wait 20 minutes, at which point my completely fresh test nodes are ready to use."
Continuous Integration = "I can tie all of this stuff together in an automated fashion, so that I don't waste a shitload of time... I commit my code, and elt the automated system run it through all the test cycles it needs."

I work for a consulting company, we do the above daily for businesses you most likely know from the online world. This is exactly how we enable higher developer velocity and shorten the Agile release cycle. Whoever down-modded the parent is a dinosaur or an idiot.

Re: Sensationalist BS? (1)

Anonymous Coward | about a month and a half ago | (#47651297)

I agree. I wrote C code running on UNIX then, and I wrote C code running on UNIX now. From the command line and with vi. Fancy visual programming tools are not the revolution the author thinks it is.

What has changed (1)

Anonymous Coward | about a month and a half ago | (#47651115)

Hmmm, I have been in the industry for 30 years and nothing has really changed from where I sit. Yes technology and languages have move and changed, some have gone out of favor and others have come in but the end of the day I am still processing the flow of data and through rules applying transformations over it.

This is all programming is and if you step back and realise that you will have a happier life at the code face lol

Another Silver Bullet? I don't think so... (4, Insightful)

bobbied (2522392) | about a month and a half ago | (#47651135)

Here we go again with another silver bullet?. It seems that every generation of noobs comes to this same conclusion and are just as wrong as we where when we said the same thing. It's almost a rite of passage, just like the rebellious teenager or terrible twos kids go though.

Yes, programming has changed some since I started doing it. However, in the long run, nothing has really changed. Programming is Programming, the same skills I used to need when doing assembly, are useful when I dabble in Java. What HAS changed is the programming model and the languages we use. Yea, we can automatically generate a boat load of code and come up with stuff that would have taking years to do in assembly in a few hours, but nothing is really new. When we went from Assembly to C, we could do things in C so much faster than in assembly, but programs only got bigger and slower. C to C++ bumped that up again, but not that much. Java bumped that up, adding mufti-platform capacity, slowing the programs down and making them take more memory. That's how this goes, new tools, bigger programs that run slower, but still requires a programmer to make useful things using those tools.

Truly there is nothing really new for programmers, the job still requires the same kinds of skills and still requires that you know the programming model. Yea, we can pull ready built stuff off the shelf more easily, but like before, new advances really only make programs bigger and slower and still require programmers who know how to design and implement. We keep trying, but this will not change.

So, nice try there syndeq, I think you are wrong. My generation of programmers thought we had achieved the same things you are claiming when we where noobs. We where wrong too. There may be new tools, but you still need a skilled craftsman to use those tools or you get garbage for a program.

I strongly recommend you go get and read "The Mythical Man Month" by Frederick P. Brooks, Jr.. In my day his experience and insights where eye opening for us, and it will be for you too. You don"t have to make the same mistakes we did. I've met some of you guys/gals you can do better, just take my advice.

Re:Another Silver Bullet? I don't think so... (2)

gweihir (88907) | about a month and a half ago | (#47651259)

I agree, Brooks is as relevant today as it was when it was written. People are still making the same stupid mistakes and still believe that technology can fix their inadequacies. It cannot.

Re:Another Silver Bullet? I don't think so... (1)

lgw (121541) | about a month and a half ago | (#47651571)

There's nothing really new for programmers because, if you're doing it right, everything is really new for programmers all the time. Once anything becomes routine, we turn around and automate it, so the work is always this set of tasks we haven't figured out how to automate set.

Re:Another Silver Bullet? I don't think so... (2)

bobbied (2522392) | about a month and a half ago | (#47651729)

There's nothing really new for programmers because, if you're doing it right, everything is really new for programmers all the time. Once anything becomes routine, we turn around and automate it, so the work is always this set of tasks we haven't figured out how to automate set.

If you look at the effects of automation tools, you discover that they really don't didn't fix anything, they just change the specifics of the problem. You are still going to need a programmer to learn the new tool and make your desired program work. That is the point of Chapter 16 and 17 in "The Mythical Man Month" I told you to read....

Re:Another Silver Bullet? I don't think so... (1)

lgw (121541) | about a month and a half ago | (#47651797)

That's just what I was saying. The programmer's task is always "automate what was new 3 years ago, and routine 1 year ago, using what got automated last time to help." It's a never-ending cycle, as automating X just allows you to do Y, which eventually becomes straightforward enough to automate.

Re:Another Silver Bullet? I don't think so... (0)

Anonymous Coward | about a month and a half ago | (#47651883)

What page says when they fire the programmer? Oh right, they never fire the programmer? Except... How many in-house programmers do you have today? Not so many? Where did they go? Not even in your country? But still companies expect governments to pay for foodstamps when their workers earn too little?

There's much more going on than technology. What's sad is that the programmers who are left think they and what they believe is significant..

Basically, the really smart people built the nuclear holocaust the idiots someday will let afire. All for paper.

Legacy... (0)

Anonymous Coward | about a month and a half ago | (#47651145)

You code today the legacy code of tomorrow... Remember that before you type any more code! Think of the children!

Re:Legacy... (1)

Tablizer (95088) | about a month and a half ago | (#47651829)

JavaScript is the new COBOL already? Damn, I'm gettin' old. (At least COBOL works :-)

Not a revolution, progression (1)

roman_mir (125474) | about a month and a half ago | (#47651177)

Developer tool No. 1: Continuous integration ...your phone starts pinging you with new emails or text messages from the continuous build mechanism telling you what needs to be fixed. Back to work, slave, the continuous build machine has new tasks for you.

- some sort of flamebait right there, in TFA. If you have something checking your code and raising flags before the code goes into testing (which may or may not catch the errors) and production, you may be spared very unpleasant production issues. When do you feel more like a 'slave', when you are asked to fix the bugs during your normal work hours or when you are woken up at night, and you have to figure out what the hell happened in production, while new transactions are coming through and you have to fix live data?

Developer tool No. 2: Frameworks ...Very little programming begins from scratch these days...
Sure, you could be pioneering and build everything from scratch, but that would be suicide.... You're not a craftsman -- you're a framework-tweaker...

...

Developer tool No. 3: Libraries

- let's hope that you don't have to write everything from scratch, you are much more productive as a developer if you don't have to write everything you need but can use libraries written and tested by others. As to frameworks, nobody from the outside world really forces you into any framework, it's a decision internal to the project, don't have to follow anything you don't like.

Developer tool No. 4: APIs ...The old game of counting bytes has been replaced by parse-able data structures such as JSON or XML...

- not that much different from header files in C, except XML is a dumb way to move data between components in the same application.

Developer tool No. 5: Platform as a service
Who builds their own website anymore? Instead, create an account on someone else's website and customize it.

- Geocities? How is this a new development?

Developer tool No. 6: Browsers
There was once a time when people wrote software for desktops, software for servers, and software for devices, and it would all be different.... Now everything goes through the browser.

- yeah, the browser used to be a dumb terminal and now it is getting more and more 'intelligent'. The browser of today is just a computer, it is the VM itself running your code in it. The browser is the computer and the code you write in it is now as complex as full clients of the past.

Developer tool No. 7: Application containers
Building a server used to be hard work...
  most of the incompatibilities between our desktops and the server are gone.

- many apps are just written for VMs (like JVM) that's not a new development, WAR files allowed this for over a decade now.

Developer tool No. 8: Infrastructure as a service
Did I mention the teams of server curators? Those guys were fun to hang out with at lunch or after work, but now they've been abstracted away into the cloud layer..... these IaaS administration Web pages won't buy you a drink after work. Of course, that saves you from ever having to get the next round.

- seriously? That's a concern?

Developer tool No. 9: Node.js and JavaScript
Now it's all done in JavaScript. The browser, of course, still speaks JavaScript, but so do the server layer (Node.js) and the database layer (MongoDB and CouchDB). Even the HTML is often specified with JavaScript code for a framework like Ext JS or jQueryMobile that generates the HTML at the client.

- yeah, yeah, Javascript. I'll be using Node.js in 5 years maybe, when it is already used by a ton of real world services that act as a proof that this wondrous tech can actually pull this off. As to MongoDB and CouchDB, I guess when I lose my mind I'll switch from a relational database to these...

Developer tool No. 10: Secondary marketplaces ...go shopping at secondary marketplaces like the Unity Asset Store and buy up all the pieces you need...
Who needs developers or artists with prices so low?

- sure, unless you actually want to develop or design something of your own.

Developer tool No. 11: Virtual machines ...The Java Virtual Machine, the C#/.Net Virtual Machine, and now JavaScript engines end up being the main target for code... ...Clojure, Scala, Jython, JRuby -- they're all piggybacking off Sun's (now part of Oracle) great work in building the VM....
you could create your own browser and language, or you could cross-compile it to be emulated in JavaScript. That's what the folks did when they built cleaned-up tools like CoffeeScript. If this isn't confusing enough, Google produced GWT (Google Web Toolkit) to convert Java to JavaScript.

- language to language translation, what a concept.... it's only as old as the compilers.

Developer tool No. 12: Social media portals ...Web is being absorbed into big silos like Facebook and Salesforce... all of humanity is clicking away in Facebook or Salesforce...You're either a lackey to the big portals or you're listening to crickets.

- or you actually end up building something that people want to use and not yet another photo wall.

Developer tool No. 13: Devops tools ...Chef and Puppet designed to maintain these servers for you. Push new software to the cloud and these tools handle the job of keeping all the computers running the same code....
Some services such as Google App Engine already handle this internally. All you need to do is give it your app, and the provisioning is automatic. You don't even know what's going on in the background; you merely get a bill for the amount of CPU cycles consumed.

- the amazing world of timesharing.... where have I heard of that one before? Oh yeah, mainframes and supercomputers.

Developer tool No. 14: GitHub, SourceForge, and social code sharing ...Sites like SourceForge and GitHub post all the code for everyone to see and update.... projects see tens or even hundreds of thousands of downloads each week? That would never be possible with the old model.

- sure. I suppose the media is the message, but people used to list their source in computer magazines in the older times. The difference of-course exists, it's your ability to modify the code and the modifications becoming public immediate, so this is a great way of sharing.

Developer tool No. 15: Performance monitoring ...Modern tools track the network calls for the network of software as well as the performance of individual modules. This is the only way to understand what is going right and going wrong....

- the computer is the network, now the network is the computer, distributed logging is useful, no doubt.

My point is, the more things change the longer the articles, the more the things stay the same or almost the same.

what a load of utter bullshit (5, Insightful)

sribe (304414) | about a month and a half ago | (#47651181)

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!

Re:what a load of utter bullshit (5, Interesting)

Tablizer (95088) | about a month and a half ago | (#47651795)

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.

Re:what a load of utter bullshit (2)

sribe (304414) | about a month and a half ago | (#47651991)

Yes. Writing desktop apps in web browsers is a nightmare. I agree with that. It's just that it's not all that different than the nightmare of gluing together incompatible libraries and various GUI/desktop managers from long ago. No matter what decade you talk about, there were always a bunch of idiots pushing a new "paradigm" that was extremely poorly thought out and a huge pain to deal with ;-)

Re:what a load of utter bullshit (1)

Anonymous Coward | about a month and a half ago | (#47651859)

The biggest change I've seen since the 1980s is that you can hire H-1Bs (or just totally offshore the dev house), so a programmer in the 1980s was earning more than one today on average... 30+ years later... and that is not factoring inflation, where $1 back then is worth $3.03 now.

Explains a lot (0)

Anonymous Coward | about a month and a half ago | (#47651221)

Crap like this sure explains a lot about why it's near impossible to hire halfway decent programmers anymore.

Second Verse: (1)

Narcocide (102829) | about a month and a half ago | (#47651225)

... same as the first, a little bit louder and a whole lot worse.

Somebody is projecting their delusions... (4, Interesting)

gweihir (88907) | about a month and a half ago | (#47651237)

Quite frankly, I just finished a larger project for a customer and what I did strongly resembles what I would have done 30 years ago: Define what the solution must do, do an architecture, a design, define interfaces, and then code the thing. The only thing that is different is that the C code was a web-server module and that the in-memory database may go up to 10G instead of the 100k or so it would have 30 years ago.

Really, nothing has changed much, unless you are at the very-low skill end of things, where you can now produce bad code in ways you could never before.

Re:Somebody is projecting their delusions... (0)

Anonymous Coward | about a month and a half ago | (#47651505)

Do you remember Powerbuilder or Delphi?

Nothing has really changed, only the names... to protect the guilty.

completly useless article (0)

Anonymous Coward | about a month and a half ago | (#47651239)

none of these things were new a decade ago.

snydeq = InfoWorld shill (1)

Anonymous Coward | about a month and a half ago | (#47651241)

When will the /. editors wise up and realize that snydeq is just trying to drive traffic to InfoWorld? Or does InfoWorld helps fund /., so they need to keep posting this drivel? Either way the problem will eventually fix itself: Either the editors grow the balls needed to ignore this twerp, or enough /. readers will leave that this site dies. Let's see which happens first...

No retarded like clickbait retarded (5, Insightful)

0xdeadbeef (28836) | about a month and a half ago | (#47651265)

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.

What? (0)

Anonymous Coward | about a month and a half ago | (#47651275)

I use assembly often for optimizing hotspots in code and to support new hardware platforms. And why do people say "why reinvent the wheel" as an argument against redeveloping parts of a system? It's not like wheels weren't redeveloped for modern automobiles--I'm not seeing too many cars sporting the classic wooden wagon wheel these days.

hype (1)

knightghost (861069) | about a month and a half ago | (#47651403)

The only differences I've seen the last 20 years are:
1. VMs
2. Average developer skill getting worse

By Neruos (0)

Anonymous Coward | about a month and a half ago | (#47651499)

Web Development != Software Development, even if both fall under the "programmer" umbrella.

The more it changes this thing never changes (2)

AlanObject (3603453) | about a month and a half ago | (#47651575)

My experience reaches back to the toggle-and-punch cards days and I don't want want to bore anyone with stories about that.

But one thing I have noticed in all those years a I cannot recall a single year where it wasn't proclaimed by someone that software engineering would be dead as a career path within a few years.

Academia and Industry is actually pretty good at coming up with new and better ways to program. Hundreds if not thousands of new languages, frameworks and tools have appeared over the years and an amazing number of them were designed with the idea that "you don't need a programmer anymore." They're still doing it.

If you have been around long enough, you realize it will never happen.

YOU FAIL IT. (-1)

Anonymous Coward | about a month and a half ago | (#47651767)

Work that you lesson 4nd development model contact to see if As it is licensed never heeded lube or we sell

Was the author even around 5 years ago? (0)

Anonymous Coward | about a month and a half ago | (#47652029)

They're certainly showing their ignorance with that list. Most of those things were around and heavily used 5 years ago and a lot of them were around 10 years ago.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>