The Technologies Changing What It Means To Be a Programmer

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.

Comments

moar idiot coderz

[Anonymous Coward]

"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."

Re:moar idiot coderz

[pete6677]

Sadly, this should be modded Informative.

Re: moar idiot coderz

[Anonymous Coward]

Yay, for the pretty colours!

We only use JS now?

[Anonymous Coward]

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?

[Anonymous Coward]

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.

Re:We only use JS now?

[wiredlogic]

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

Re:We only use JS now?

[Anonymous Coward]

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

There, FTFY.

Re:We only use JS now?

[gweihir]

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?

[rogoshen1]

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

Re:We only use JS now?

[machineghost]

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?

[mjwalshe]

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

Re: We only use JS now?

[Anonymous Coward]

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?

[dilvish_the_damned]

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

Re: We only use JS now?

[TheRealMindChild]

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?

[Anonymous Coward]

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

Re:We only use JS now?

[msobkow]

...and the server is just used for database work.

And that mentality is precisely why so many web applications suck farts off dead chickens for performance and scalability.

The first step to designing a scalable application is designing a scalable and flexible database model. The database is not an "afterthought", it is the heart of an application.

The code which accesses the database can be tweaked and fiddled, but once you've created your database, it becomes very expensive to change it in the future because of the costs of changing not just the code, but creating and testing database migration scripts to move the data to a new model.

But you go pat yourself on the head that you're a 'leet programmer because you know a scripting language.

And then hang your head in shame when you realize that JS runs in the browser and is only a presentation layer, not the application itself. Only a fool puts the business logic in the client if they have any understanding or concern for transaction consistency and application reliability. You have to assume the presentation client is going to break half way through processing something and leave the database in an inconsistent state if you put the business logic in the front end.

Re:We only use JS now?

[Anonymous Coward]

I can't even begin to tell you how many times I get a question on stackoverflow like "I'm having trouble with my regex to find the first occurance of '=' in a string..."

Like anyone who's just been introduced to a hammer, all their problems look like a nail; or, in modern terms, like anyone who's been introduced to a regex, all of their problems look like a match string.

Re:We only use JS now?

[Anonymous Coward]

It is used in mission critical stuff, that's true. But also consider some of the other real dogs used in mission critical stuff: ASP (pre ASP.net), PHP, VB6, Excel Macros, CMD BAT scripts, etc. Mission critical use isn't a very good ruler for better, it is probably a decent ruler for cheapest to roll out a half-solution.

As soon as you need to maintain it, Javascript starts to show it's warts. That's ok, many other languages have warts too. The only saving grace for Javascript is that it is in every web browser, and due to some really stupid "security" practices of the past, the only port everyone agrees will be open in a firewall is port 80.

Re: We only use JS now?

[Anonymous Coward]

Great! Now You can use a really shit language on BOTH the client side and server side!
Why in mercifuls Satans name would anyone want to do that, except being a crap frontend developer pretending to be a backend developer, but without any actual skills to learn a second programming language?

Re:We only use JS now?

[darkain]

Yes, yes it is!

https://code.google.com/p/shel...

(and yes, this is used in production on mission critical systems)

Re:We only use JS now?

[Anonymous Coward]

The first step to designing a scalable application is designing a scalable and flexible database model. The database is not an "afterthought", it is the heart of an application.

While I agree on your assessment of 'scripting languages'; I disagree with this part of your post. Your storage mechanism should not be your first step; in fact, I consider it ancilary and an implementation detail... Look up the Onion pattern...

Re:We only use JS now?

[gidyn]

JS is used by EVERY WEBSITE IN EXISTENCE because it runs on EVERY BROWSER IN EXISTENCE except lynx. I use it for my websites because it's the only choice, and hate it with a passion. See the entry for 1995.

Re:We only use JS now?

[Anonymous Coward]

If you've got a string and you want to find the first equals sign, does that not sound to you a bit like a string-matching problem?

Re:We only use JS now?

[Lennie]

They are obviously talking about in generalities.

That doesn't mean everyone is doing it. Or that it fits every task.

Here is some random survey from 2012 as an example:

58.9% Javascript
58.9% sql
51.1% jquery
37.6% java
37.6% c#
28.9% php
23.4% python
21.1% c++

The year after:

57.9% Javascript
53% sql
37.9% java
37.6% c#
26.2% php
22.5% python
21.7% c++
18% c
10.3% objective-c
9.8% node.js
9.1% ruby

http://blog.stackoverflow.com/...

I don't know how representative Stack Overflow is or what it means, I just know Javascript is used a lot.

If that means they are using Javascript only on the website front-end or also for other things. Who knows.

Node.js is listed as 'most exciting new technologies':
38.4% node.js
36.1% arduino /raspberry pi
28.4% angular js

So maybe it's used on the server too.

Re: We only use JS now?

[Anonymous Coward]

So Node.js is JSON? Go figure.

Re:We only use JS now?

[RabidReindeer]

Only a fool puts the business logic in the client if they have any understanding or concern for transaction consistency and application reliability. You have to assume the presentation client is going to break half way through processing something and leave the database in an inconsistent state if you put the business logic in the front end.

Actually, while that's a valid concern, a much bigger reason for not putting the application logic in the client is that anything in the client can be hacked for malicious purposes.

Server-side code may not be as immediate, but at least access to the code is restricted to functional invocations and not inherently at risk at the instruction level.

Re: We only use JS now?

[Anonymous Coward]

Sure, it's a string-matching problem -- one that would be solved ever so much better with "string.indexOf('=')" than "re.search(string, r'(=)').start()"! (And that's Python-style pseudocode -- imagine how much more inscrutable it would have been if I'd written it in Perl/PCRE!)

Clearly, there *are* use cases for regular expressions, but the *vast* majority of the time they are either inapplicable (for example, someone else posted about processing things like HTML, which can have recursively nested tags) or a needless over-complication of the problem (like the one the parent mentioned).

Friends don't let friends write unmaintainable code ;-)

Re:We only use JS now?

[Anonymous Coward]

Actually, while that's a valid concern, a much bigger reason for not putting the application logic in the client is that anything in the client can be hacked for malicious purposes.

Pfft... in theory, maybe! Next you'll be telling us that we have to generate all the database modification and update SQL query strings on the server rather than creating them on the client browser and passing them to the server for direct execution, or that embedding the database username and password in browser-side .js files is a "horrendous security hole and you are clearly a f***wit".

Re: We only use JS now?

[Anonymous Coward]

> Sure, it's a string-matching problem -- one that would be solved ever so much better with "string.indexOf('=')"

while (string[i] != null) if (string[i] = '=') return i;

I love simple code, but this C is so loaded with assumptions it makes me lightheaded... :)

Re: We only use JS now?

[Anonymous Coward]

Plus it doesn't work if you don't increment i. C is a footgun - it will happily compile and run buggy code like this.

Re: We only use JS now?

[Anonymous Cod]

And... even if he were incrementing i it wouldn't matter, because the 'if' expression will be true due to being an assigment statement. What an utter failure. That guy just proves the point that he would not be able to produce working code without a compiler/debugger.

Re: We only use JS now?

[Anonymous Coward]

God, I love C! :)

Re:We only use JS now?

[Anonymous Coward]

All that means is there's a lot of script kiddies using JS asking for help on Stack Overflow because they can't or won't figure it out for themselves.

Re:We only use JS now?

[david_thornley]

It doesn't run mine, which is written in strictly compliant HTML 3.2. I could relax the restriction to the old Netscape color palette, though.

Re:We only use JS now?

[david_thornley]

That's one of the reasons I sometimes use lynx.

Re:We only use JS now?

[gweihir]

Not really. The web works pretty well with JS turned off. It is just a minority of pages that need it. And on the SaS-side: You have read too much marketing material. Most of these things could be done a lot better without MBs of JavaScript just to render a few tables. The prevalence is dues to incompetence, not due to any technological need.

Re:We only use JS now?

[gweihir]

I completely agree. Whether you have a JS-monster or a vt100 at the front-end is immaterial. (Well, the JS monster eats cycles. I have seen "professional applications" where it took the browser seconds to parse the JS mess in there.) It is easily replaced. The application-layer is more critical, but the database-design is what rules performance (or lack thereof) and what you can do in the first place.

Re:We only use JS now?

[gweihir]

You should talk to the IT departments of some large banks or insurances. The database-backend is what decides everything. Everything else is immaterial and can be changed at need. Not the backend.

Re:We only use JS now?

[gweihir]

Nobody, except the insane and the utterly clueless put application logic in the client. For some industries it may even be illegal to do so due to the data that would be exposed at the client and due to audit-trail requirements. Even sending data to the client to merely be echoed back (i.e. client-side state) is extremely problematic.

Re:We only use JS now?

[gweihir]

Does not run in links either or when you have no-script active (as I do frequently).

Re:We only use JS now?

[Anonymous Coward]

many web applications suck farts off dead chickens for performance and scalability.

Still trying to wrap my head around that one

Re:We only use JS now?

[Anonymous Coward]

I still occasionally do consulting work maintaining VB6 and MSAccess applications which run core business processes within a very large industrial company (no, almost none of you would recognize the name). They've been talking about replacing them for at least a decade now...

The term "mission critical" often means "we're not exactly sure how it got this way, and all the people who might remember are long gone, but we're stuck with this beast until the company hires someone to cut off all the heads at once while reliably cauterizing the neck stumps".

- T

Re:We only use JS now?

[Pherdnut]

If he knew what he was talking about he wouldn't be lauding Ext JS as if it was something that shouldn't be compared to a hate crime. I say that as a primarily JS developer.

Some of us do still assemble, even now

[wonkey_monkey]

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

[Anonymous Coward]

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

Re:Some of us do still assemble, even now

[Anonymous Coward]

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

Re:Some of us do still assemble, even now

[LifesABeach]

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

[asmkm22]

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

[khasim]

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

[gweihir]

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

[GiganticLyingMouth]

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

[Darinbob]

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

[Darinbob]

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

[Darinbob]

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

[Obfuscant]

"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.

Re:Some of us do still assemble, even now

[styrotech]

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

[Dutch Gun]

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

[Kjella]

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

[angel'o'sphere]

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

[disambiguated]

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

[angel'o'sphere]

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

[Anonymous Coward]

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.

Hey guys, over here! It's one of those fucking lazy programmers who would rather suck up 10 MB libraries instead of learn how to write a 30 line function. No-one ever goes back and cleans up these sloppy, dependency laden, resource wasting messes. With your priority of quantity over quality, I seriously doubt you ever write anything that works well and fast. You solution to fast is to just make the end user buy more expensive hardware to run software that used to run just fine on a Pentium II.

On one hand, with the plethora of crappy programmers maybe it's better that they are just sticking existing libraries together. On the other hand, this is the exact approach that lead to the OpenSSL fiasco. Crap quality, quick written software that never got looked at again.

Re:Some of us do still assemble, even now

[istartedi]

, go bored after three and delete the other twenty.

Don't worry. Soon permanent storage space will be so big that nobody deletes anymore. After a while, rm will be removed from Linux distros. You'll just revision the data on your drive, never actually deleting anything. Ha-ha, only serious.

Re:Some of us do still assemble, even now

[phantomfive]

Don't worry. Soon permanent storage space will be so big that nobody deletes anymore. After a while, rm will be removed from Linux distros.

LOL. I'm laughing with the vague worry that you're accurately predicting the future.

Re: Some of us do still assemble, even now

[Anonymous Coward]

I would but my employer made me sign an NDA. I work professionally on operating systems.

Re:Some of us do still assemble, even now

[Anonymous Coward]

I would post my last assembly program that I wrote but I would have to find a 5-1/4" drive to retrieve it first.

Re:Some of us do still assemble, even now

[Anonymous Coward]

I'll agree that there is a tiny overlap between developers and journalists; however, Infoworld holds a special place in that Venn diagram. They're like the FOX News of technology reporting. You have a better chance of getting correct information out of their articles by negating most of the sentences.

Re:Some of us do still assemble, even now

[volovski]

True. Next they will say bytes , nibbles, and bits are EVOLUTIONARY. Terabytes, zettabytes , yottabytes must really be confusing. What a trend setting article.

Re:Some of us do still assemble, even now

[Anonymous Coward]

That's what we do with Git right now - nothing's ever truly deleted from a repo without some significant effort.

Now if I can only find the idiot who checked in a 5 gig VM image into our code repo ...

Re:Some of us do still assemble, even now

[Anonymous Coward]

the lens of a javascript-focused web programmer. Seriously, libraries are a hot new trend?

JQuery is almost 8 years old by now, even web developers don't have that excuse.

in which case he's using the wrong terminology.

I think its a combination of two things, namely playing buzzword bingo for his target audience while having no clue what he is talking about. After all his job is to attract readers, knowing what he is writing about isn't even a secondary objective.

Re:Some of us do still assemble, even now

[wonkey_monkey]

Just because you can doesn't mean you should.

Just because you shouldn't always doesn't mean you shouldn't ever.

Re:Some of us do still assemble, even now

[wienerschnizzel]

Unless by "native development" he meant "roll your own game engine", in which case he's using the wrong terminology.

Maybe he means that because of outsourcing, more and more applications are being developed in India by the "natives" rather than in the US by H1Bs

Re:Some of us do still assemble, even now

[Anonymous Coward]

Why would you store a 320x240x4 bit screenshot on a computer that could only display 320x200x1 bit or 160x200x2 bit plus a "palette" of 2 colors per 8x8 or 3 colors per 4x8 pixels (the 00 bit combination selected the background color)?

A hires (320x200x1) picture would take 9 KB, and a multicolor (160x200x2) would take 10 KB, of which the last 1 Kb only 4 bits of each byte was used, and was actually stored in a special 1KB RAM area that had only 4 bits per byte (the upper 4 bits were always 1).

You remember the 38911 BASIC BYTES FREE correctly, though, and the 65536 bytes of RAM does not include that 1KB of 4 bit RAM (though I'm not sure if the real RAM at the same address are was accessible).

Re:Some of us do still assemble, even now

[ultranova]

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.

Especially since linking to a 10MB library isn't going to pull it all in, it's going to demand-load only the parts you need, and into shared memory at that. So multiple applications using the standard 10MB library is likely to actually end up consuming less memory than each developer making their own routine in hand-optimized assembler. It might even be faster, since it's more likely to be in a cache.

All of which leads to the fact that messing with low-level details is usually not worth it, so most programmers aren't really familiar with them, so they're unlikely to get any benefits even when significant ones might theoretically be had.

Re:Some of us do still assemble, even now

[RabidReindeer]

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

However, there is no longer a 1:1 mapping of machine code (assembler or not) to internal machine operations. Well, for some machines, like IBM's microcode-based mainframes, there hasn't been for quite a long while, but they were still one machine instruction = a predetermined number of microcode cycles.

At one time, machine language was more or less determinate. You knew precisely how long each instruction would take to execute and you could add it up on your HP calculator. Even into the early 1980s, DMA and interrupt services could have impact on execution time, but they could be allowed for.

Modern processors are heavily pipelined, use predictive methods have multiple cache levels, and so forth. Computing the execution time is essentially impossible except as a statistical exercise unless the code is very short and you know precisely what all the data is.

This is why assembler is no longer widespread in applications. Functionally speaking, it's considered a general rule that it takes on average 5-10 assembler instructions to do what a single line of almost any high-level language code can do, but the amount of time it takes a programmer to create and debug a single line is roughly the same, whether they're assembler lines, COBOL lines, or C++ lines. Practically speaking, computers (compilers) are much better at the tedious job of tracking minutae and selecting the (presumed) optimal rendition of higher-level functions into hardware-level fundtions.

Re:Some of us do still assemble, even now

[ultranova]

C++ is still used almost exclusively for large-scale AAA game development.

Many (most?) AAA games use C++ to build a specialized runtime and the actual game logic is implemented with scripts running on it.

Re:Some of us do still assemble, even now

[RabidReindeer]

Even in COBOL, core dumps are not the ideal diagnostic tool and haven't been for a long time. Most high-level languages have their own more developer-friendly means of presenting failure information. A core dump for Java is only produced if the JVM itself fails. Street-level programmers work with stack traces and stack and heap dumps.

Most developers I know couldn't read a core dump at gunpoint. The ones that can are working mostly with pure compiled languages such as C/C++ or (rarely) assembler. But since the current fad is heavily biased towards scripting languages, there aren't that many younger people I know who deal with static compiled languages.

Even a bytecode dump is beyond most of them.

Re:Some of us do still assemble, even now

[RabidReindeer]

Developers 20 years ago "did not have libraries". Meaning that you had math function libraries (dating back to the 1960s or before) and you maybe had a semi-standard high-level library or 2 such as Microsoft's MFC, Borland's OWL, the C++ STL.

However, the rise of ecosystem languages such as Java - with its rich set of built-in packages, Python, with its cheese store, even Perl's often-dodgy CPAN has caused modern programmers to consider libraries as more the rule than the exception.

Even JavaScript has libraries. So many libraries!

Re:Some of us do still assemble, even now

[Frederic54]

True, I still do x86 on a (emulated) VAX and also AVR8 assembly, when you have a few kB of flash, nothing better than assembly language!

Re:Some of us do still assemble, even now

[Archtech]

The problem is that they are expected to keep writing new articles about (more or less) fresh topics. Thus guaranteeing that they never learn much about anything.

Re:Some of us do still assemble, even now

[dkf]

Many (most?) AAA games use C++ to build a specialized runtime and the actual game logic is implemented with scripts running on it.

If you're lucky, the scripts are in Lua (or possibly even one of the other embeddable scripting languages). If you're unlucky, they're in something custom...

Re:Some of us do still assemble, even now

[angel'o'sphere]

Ofc that is the reason why assembler is rarely used.
A better optimizer usually outperforms a human.

However if you like to program in assembler (for what ever obscure reason ;D ) get an ARM. I believe Raspery PIs are ARM based. Similar fun is a SWEET16 emulator. Even SPARC or PowerPC is no longer interesting in manual programming, but perhaps MIPS, did not try that yet.

5-10 assembler instructions to do what a single line of almost any high-level language code can do, but the amount of time it takes a programmer to create and debug a single line is roughly the same, whether they're assembler lines
Half correct, it is more like assembler < C < Java < C++ < Lisp/Prolog/Groovy/Python ... where you have a slight increase from language to language. So a 20 lines Lisp program might be equivalent of 1000 lines of Assembler or 20 lines of Prolog something like 10k of Assembler. Of course that is a bit inaccurate and outdated, the power of those languages often comes from a library, and at least in C++ nothing speaks against having similar powerful libraries as STL and BOOST shows. Also processors became more powerful, but well on the other hand a line of IBM Mainframe Assembly can invoke one of those macrocode super instructions which are as complex as two nested loops in C.

Re:Some of us do still assemble, even now

[Anonymous Coward]

C#/unity != native development

Re:Some of us do still assemble, even now

[AlphaBro]

An assembler is a program that translates assembly into object code. Assembly is the language.

Re:Some of us do still assemble, even now

[Darinbob]

Core dumps aren't ideal, but often it is the only possible debugging tool. Embedded systems, dump memory to flash and reboot.

Re:Some of us do still assemble, even now

[lisaparratt]

I see someone doesn't know about the trick modes. http://www.studiostyle.sk/dmag...

Re:Some of us do still assemble, even now

[Anonymous Coward]

Top 100 H1B Visa Sponsors -2014 H1B Visa Report

Re:Some of us do still assemble, even now

[sillybilly]

I disagree. In 2005 the only practical alternative to Visual Basic Classic 6.0sp5 I found to be wxWidgets, (I wish I had known more about Delphi 5 and 7) as the dotnet versions of Delphi, VB, C# all pretty much sucked. The showstopper with wxWidgets was the c++ library size, as a hello world program in it compiles to 1MB, which is a whole lot more than I find safe, I think it should compile to 5 KB, but I'd be willing to live with 16KB that straight, laborious Win32 API produces. In fact the vbrun60.dll that's non multithreated soo too simple by the way, is a very small sized thing, on top of which runs your almost on the fly editable if you have the source handy interpreted code like compiled executable, of say 3 KB, or 16KB. When it comes to security, or ability to guarantee that something will function, it's a life and death situation, a make or break for a business when they have to sell 1MB executables instead of 16KB ones. Humongous libraries keep programmers out of business, because they cannot assume the risk of what all can go wrong in 1 MB complexity, while they might be willing to assume it with 16KB, and even stoop down and willing to hand troubleshoot it at the assembler level in the future, if push comes to shove. But it's superhuman to debug in assembler a 1MB C++ library artifact that's crapping out on you. I chose not to take the risk with wxWidgets, but I'm using a program right now, called glGo, written in wxWidgets, cross platform. Other people under less attack than me can assume the risks that I am unwilling to assume.

Re:Some of us do still assemble, even now

[sillybilly]

I'm a natural born hoarder, I don't like to get rid of anything that might come in handy later, especially when it comes to data that fits in a small space. However, even I find it necessary to discard stuff sometimes, that I don't want to save. There is balance even in hoarding, as in theory, there is nothing ever that should be discarded, but in practice, there is.

Re:Some of us do still assemble, even now

[sillybilly]

I'm typing this on XP, on an HP Mini that originally came with Win 7, but was too slow with Win 7, so I downgraded it to XP and it's like such a breath of fresh air, speed, performance, usability, looks, everything's better, even if Win7 was a massive good, massive improvement to the "vista sucks" slogan. (Btw, who in the world still uses Vista? I know, business stuck in a slow cycle.) The Intel Atom gets great battery life and low power consumption, and I can't afford anything Win 8 right now, nor are there anythings with faster performance and lower battery life than the HP Mini Atom that run Win 8 at performance better than XP, last time I looked when I could afford it, nor can Win 8 run stuff I'm used to, such as the EULA-less candy of software called The American Heritage Dictionary for Windows 95. That's my favorite piece of software ever. It sucks, but at the same time it beats paper books hands down. Unlike spreadsheets for instance, a 3M yellow sticky note and a pencil leaves a smartphone spreadsheet in the dust in a lot of respects. For one, you can stick it on things, it has an adhesive strip. And for a new computer, I'm interested in something that I can unplug from the network, and it will still function, and that excludes smartphones. It's like one of the prerequisites of constant government surveillance and snooping in the inability to run your computing device, such as a cellphone, standalone, off the network, for simple things like capturing images with the camera. There is no option in cellphones that says disconnect and stay off network, but if you leave the SIM card out, it will whine and moan, and go into 911 mode, but not let you use the camera and built in software to transfer images out of the camera.

Re:Some of us do still assemble, even now

[david_thornley]

That's only true if you're looking at standard libraries, and even so Java's was large 15 years ago (particularly if you include EE). The article says nothing about the libraries being standard, and I assure you there were plenty of libraries to do all sorts of things in 1994, and frameworks (I used one C and one Common Lisp around then).

Re:Some of us do still assemble, even now

[david_thornley]

Which one do you want? I've programmed in half a dozen, most not in general use today.

People keep talking about assembly language as if there could be only one. It used to be IBM 360/370, and now it's x86/x64.

Re:Some of us do still assemble, even now

[gweihir]

Well, as you are clearly more interested in insulting people than rational discussion, you do not qualify for a replay. Anyways, you do not get it even one bit either.

Re:Some of us do still assemble, even now

[gweihir]

Well, people that talk about assembly language as if there is only one are generally clueless and not aware of that. I have done 6502, 68k, x86 with the 68k syntax (gas) and some fragments on several different MCUs, and they are all pretty different. Even more different when you take into account that you need to understand the CPU as well, not just the language.

Re:Some of us do still assemble, even now

[angel'o'sphere]

So you feel insulted?
Perhaps word your meaning a bit more polite and the answer will be more polite.
But looking back the the discussion I see no possible point where I could have insulted you. Must be a geek vs. nerd thing.

Re:Some of us do still assemble, even now

[Anonymous Coward]

You must be new here. angel'o'sphere is one of our local Dunning-Krueger poster boys.

Re:Some of us do still assemble, even now

[Art3x]

InfoWorld sucks.

We've been snydeq rolled. This story was submitted by snydeq, whose every link points to InfoWorld.

Re:Some of us do still assemble, even now

[RabidReindeer]

Java isn't merely object-oriented, it's object-based, just as Smalltalk was. It may be possible to have an object-based system with no standard functions in it, but I'm not sure I'd want to meet it. And yes, Java's was exceptionally large.

I'm afraid that C resources back then were much dicier. As mentioned, there were a few vendor-specific libraries, some user-group libraries, and some commercial libraries. But no real common denominator libraries beyound the Unix basics like stdlib. If you wanted to produce an open-source C/C++ project or if you worked for employers too cheapskate to buy commercial libraries, it was pretty much roll-your-own and one-off. Fortunately, gnu/Linux/BSD has filled in some of those gaps since then.

I worked with GNU even before Linux came out - a lot of GNU was adopted for CP/M while Linus Torvalds was still practically a toddler. But it was mostly complete programs, so doing things like extracting the pattern-matching logic from grep to use in a different app could require a certain amount of work.

Re:Some of us do still assemble, even now

[Dutch Gun]

In a large percentage of the projects I've worked on, most of the game code was in C++ too, with scripts used for more specialized tasks and customization. The trend of writing large portions of game logic (like AI) in scripts has fallen out of favor for the projects I've worked on, for a variety of reasons. That's not to say we didn't use them extensively in more focused areas though.

Re:Some of us do still assemble, even now

[david_thornley]

Back about 20 years ago, I was able to find good C libraries for a whole lot of things, a whole lot free for academic work (which is what I was doing at the time). It took more looking than it does now.

Re:Some of us do still assemble, even now

[Anonymous Coward]

> I worked with GNU even before Linux came out - a lot of GNU was adopted for CP/M while Linus Torvalds was still practically a toddler.

Really? GNU on CP/M? That's...surprising. Linus was 13 in 1983 when RMS started GNU, and CP/M was mostly out of the picture by then. I had the impression that GNU basically didn't run on x86 until Linux came along. Cygwin wasn't around then or Linus would have used it.

Not changed much

[jmyers]

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

[digsbo]

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.

Re:Not changed much

[mrchaotica]

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

[Darinbob]

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

(yes it's sarcasm you annoying downmodders!)

Re:Not changed much

[mjwalshe]

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

Re:Not changed much

[theshowmecanuck]

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

[mrchaotica]

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

[tepples]

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

[disambiguated]

As a senior engineer today, I'm responsible not only for knowing ...

I thought the exact same thing when I started as a software engineer in 1996, almost 20 years ago. Only back then we actually generated HTML in C++ on the server (with home-brewed "html template" processors.) And we had to deal with things like COM, and browsers were far less standardized. We also had to deal with database design, only we had to make home-brewed Object-Relational Mappings, because the frameworks for that weren't that good either. Marshalling an object from the database through the business logic and onto the client and back required all kinds of hand-written code. We also had to worry about deployment, but we could only dream about something like WiX. I don't want to hear any complaining about build systems if you haven't been subjected to the horrors of makefiles. We had source control way back then too, but it was less flexible, less salable, and more difficult to use.

And check this out. If we didn't know a tool or API or algorithm or data-structure (oh yeah, we wrote our own back then), you couldn't just google the answer. You had to actually find it in a book, or learn it from a friend or colleague.

Re:Not changed much

[Anonymous Coward]

The Idiots part of "constantly-claimed-by-idiots-to-be-dead language" tend to be people trying to market their new language as a buzzword.

Re:Not changed much

[BitZtream]

So basically you just learned how to do a full application (web server and GUI via html) and you think its new. Funny that just happens to be 20 years old as well, and its certainly not the first type someone wrote client server applications.

Nothing you're doing is new other than you're doing it now instead of someone else.

You just learned to do the 'full stack'. I've been doing it for over 20, before the web existed. Different languages, different layout engines, different libraries, same process.

Re:Not changed much

[tlhIngan]

The video game console makers have made it clear that their platforms are not intended for hobbyists.

Sony maybe, but Microsoft has long had the Xbox Live Indie Arcade where for $99 a year you can code up something and play it on an Xbox360 and even sell it on an Xbox360.

And Sony did at one point too when the PS3 ran Linux.

Microsoft has/had plans for bringing the program onto the Xbone as well.

Re:Not changed much

[Hypotensive]

If you go back 30 years you'd probably have had to write the language you were going to use and an interpreter or compiler for it. You would absolutely have had to know about the database design, although the database would have been made up of byzantine interrelated b-trees rather than intuitive SQL tables. You'd have had to write everything from scratch for each task rather than leveraging huge libraries for everything. Things are many times easier these days yet you still find articles like this that bemoan how complicated everything is.

Re:Not changed much

[Anonymous Coward]

If you go back 30 years you'd probably have had to write the language you were going to use and an interpreter or compiler for it. You would absolutely have had to know about the database design, although the database would have been made up of byzantine interrelated b-trees rather than intuitive SQL tables. You'd have had to write everything from scratch for each task rather than leveraging huge libraries for everything. Things are many times easier these days yet you still find articles like this that bemoan how complicated everything is.

Nah, you used "4th Generation Languages" like Convergent Solutions Incorporated's ADS (Application Development System) on B/CTOS, and RM-COBOL or Informix on Intel or SCO XENIX to build your applications; the database was handled by the 3/4GL (usually the vendor's ISAM tables). Maintaining the tables could be painful, but you could always do an RSAM->SAM, edit the tables then do a SAM->RSAM and reorganize the tables to rebuild indexes.

In a lot of ways, though limited to the included embedded functions, the 3/4GLs of yesteryear were easier to work with than the languages of today. Building and extending applications was a snap. Porting to new hardware or operating systems was a crap shoot.

Get off my lawn.

Re:Not changed much

[tepples]

for $99 a year

Which turns a $300 console into a $900 console. Now I know where Apple got the idea.

Re:Not changed much

[tlhIngan]

So basically you just learned how to do a full application (web server and GUI via html) and you think its new. Funny that just happens to be 20 years old as well, and its certainly not the first type someone wrote client server applications.

Nothing you're doing is new other than you're doing it now instead of someone else.

You just learned to do the 'full stack'. I've been doing it for over 20, before the web existed. Different languages, different layout engines, different libraries, same process.

One small difference - PCs were a lot less capable 20 years ago, and it was possible to know the whole stack much easier back then when "whole stack" didn't do much. I mean, it was the dawn of the GUI age with Windows 95 on the horizon, so most apps were DOS or Windows based and fairly basic at that. It was a lot easier to understand purely because when you're running in 4MB of RAM, there's not a log you COULD do.

If you needed to do anything more complex like query a shared database, you shelled out to a terminal program that connected to a database and re-ran the query there on the mainframe.

for $99 a year

Which turns a $300 console into a $900 console. Now I know where Apple got the idea.

And what aspect of "hobby programming" implied zero cost? Back then you could pay thousands for an IBM PC which had BASIC, for which you could just've bought a cheaper Apple or Commodore or many other more popular computers. And if you wanted to do assembly, well, ante up $200 for an assembler. C? Well, another $400 for the software, and make sure you upgrade to dual floppy or harddrive/floppy ($thousands) and have tons of memory.

Hell, Borland was popular because their compiler suite was not only fast, but cheap - for $200 you could get a full featured C compiler that didn't require you to shell out and run the compiler, assembler and linker manually.

Re:Not changed much

[Anonymous Coward]

There are more c++ jobs then c AND asm...

Re:Not changed much

[Anonymous Coward]

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

Really? It's been around for a Kuhn's age!

Programming evolves. News at 11.

[gregmac]

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.

[Ungrounded Lightning]

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!)

Re:Programming evolves. News at 11.

[phantomfive]

* "Back to work, slave, the continuous build machine has new tasks for you."

Has anyone ever, anywhere, gotten a task assigned to them by the continuous build machine?

Re:Programming evolves. News at 11.

[Anonymous Coward]

* "Back to work, slave, the continuous build machine has new tasks for you."

Has anyone ever, anywhere, gotten a task assigned to them by the continuous build machine?

all the time.

No Assembler?

[Ozoner]

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?

[Darinbob]

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.

Re:No Assembler?

[volovski]

I agree. The IT managers think everything is a web App. They like buzzwords. They buzz like bees with agile - creating metrics, charts, graphs, slides, meetings for meetings. Can we outsource the Troll managers ? Or insource the troll managers. Maybe have 3 managers where 1 is needed ? Or a study for a study. Tell your managers and InfoWorld the wrong info so they skrew themselves- they will not know the difference.

Re:No Assembler?

[Anonymous Coward]

I would be surprised if Windows 7 or Windows 8 or Windows 8.1 uses ASM.

Yes, no, maybe, potato salad

[jd]

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.

Re:Yes, no, maybe, potato salad

[phantomfive]

1) Modern methodologies, with the exception of tandem/test first, are crap.
2) Weakly-typed languages are crap.

I would only add, "All Languages are Crap. Programmer skill makes the difference."

Re:Yes, no, maybe, potato salad

[cheekyboy]

Managers how fire staff, then outsource work to their own shell company at 3x the hourly rates to pocket their own wallet are FRAUDSTERS.

Assembly is nothing more than the core basics of a language, maths on values, moving numbers, function calls, branch on logic. Everything else is just a combination of the basics, but re-useable in more apps/libs/frameworks.

Infact, everything comes down to just an conditional ADD instruction.

What it all comes down to is this, can you or your team finish the project, before a competitor, so you can seal the deal and make the cash.

Re:Yes, no, maybe, potato salad

[dkf]

There is no table, that I know of, that lists all the features versus all the paradigms versus all the languages.

That would be a very large table indeed, as there are a lot of critical nuances and a lot of languages (even if we exclude the ones without the ability to do a useful subset of all system calls).

Re:Yes, no, maybe, potato salad

[jd]

Very true, but without it, we're doomed to reinventing wheels, redoing research and coming up with suboptimal solutions that are harder to program, harder to maintain and bloated with helper functions that would have come as standard otherwise.

Such a table can be written once then updated every 5 years. Reading it simply amounts to feeding into a parametric search routine what you know you will need to be able to do. You will then get a shortlist of languages ideal for the task.

Now, it comes down to two simple questions: are your requirements ever stable enough or clear enough for such a shortlist to be useful? Do you risk overoptimizing on a set of criteria that may have no resemblance to the reality of the problem or the reality of any solution the customer will sign off on?

If the answers are "yes"and "no" respectively, I'll start the list today.

COBOL was better than JavaScript.

[Anonymous Coward]

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.

[machineghost]

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

Re:COBOL was better than JavaScript.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[dbraden]

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.

[Anonymous Coward]

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.

[machineghost]

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.

[machineghost]

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.

[Snotnose]

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:COBOL was better than JavaScript.

[jrumney]

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.

[jrumney]

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.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Why the hell was this comment rated insightful!! What insight does it give? Just sounds like a JADED old programmer having an angry rant!!

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Sonofabitch, he could have even gone with one of the newcomers like Lua

Somehow I never thought about that before, but damn. That would have been something. I have to go lie down now. That's a very sad and heavy "what could have been" thought.

Re:COBOL was better than JavaScript.

[Alan Shutko]

Block scope doesn't exist. That's broken.

Re:COBOL was better than JavaScript.

[phantomfive]

If only COBOL didn't have problems with re-entrancy........

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Guess what. I've maintained a lot of shitty C code in my career, so I guess by your logic, that makes C a shit language that is horribly broken.

Re:COBOL was better than JavaScript.

[Jeremi]

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++ ;^)

Re:COBOL was better than JavaScript.

[narcc]

indeterminate behavior of "this"

So what you're saying is that you don't even understand the basics of the language. That's your fault.

Re:COBOL was better than JavaScript.

[narcc]

Why?

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Jesus Christ, I hope that you're not a professional programmer. I even hope that you're not a hobbyist programmer.

Be honest, can you not see the problem with a lack of block scoping?

Are you honestly unable to figure out on your own the massive problems that JavaScript's broken approach results in?

I really do hope that you're just trying to be argumentative, that you actually aren't as stupid as you currently appear to be, and that you do realize how flawed JavaScript's approach is. God, do I hope that's the case.

Re:COBOL was better than JavaScript.

[narcc]

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.

He wanted to do exactly that. Then someone at Netscape found out what Scheme was and put the kibosh on that plan. (Learn a little history, kid.)

In a way, we were really lucky. What we got was MUCH better. It's a rotten shame so few people here have actually taken the time to learn the language. It's really quite good. The "bad parts", interestingly enough, are the bits Eich was told to include to make it look more like Java (new, constructor functions, etc.)

It's perhaps the worst thing ever to have happened to the computing industry, the worst thing to have happened to the Web

There's a good chance that, without JavaScript, the web would have vanished. You probably don't remember all the hype surrounding the "x internet" back in the early 2000's, but the web was on it's way out. If not for JavaScript (and XHR) the web would likely have been replaced by some other set of technologies.

Re:COBOL was better than JavaScript.

[narcc]

Try learning it before you use it next time.

Given that the few *actual* complaints about it (not empty 'it sucks' rhetoric) seem to be simple misunderstandings about the language (this, classes, etc.) I'm willing to bet that the problem is the user, not the language.

Really, it's not complicated. It's really very simple. It's different, yes, but far simpler than other, less sophisticated, languages. Take a few days to learn and understand the language. You'll be impressed. It's remarkably well-designed.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

LOL

Re:COBOL was better than JavaScript.

[Anonymous Coward]

because you can't limit the scope your variables live in, without wrapping in a function scope.

although, the new Harmony JS has let/const block scoping.

Re:COBOL was better than JavaScript.

[Dutch Gun]

C++ is the programming language equivalent of a powerful but touchy sports car that's almost guaranteed to crash and burn in the hands of novice drivers, but can perform beautifully in the hands of an expert. C is that same car with the mirrors, safety belts, and airbags removed.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

It sounds like you haven't tried to program in COBOL, so you really are not in a position to refute the man.

I've programmed in COBOL, Java, C, C++, FORTRAN, Lisp, Scheme, Tcl, Prolog, PHP, Scala, and a few other even lesser known programming languages. Oh, and I took the time to learn Javascript too (although I readily admit I'm not a Javascript Guru).

Many of the language features that I like the most in the easier to maintain languages, the ones that I've found time and time again have saved me from really nasty bugs, are missing in Javascript. Many of the features I have found can save me tons of lines of code are present in Javascript. So now I have a pretty dense language without safety features. To my eyes, that's more latent bugs per lines of code. I'll take a verbose language that leaves nothing to chance over a terse language where many of the nasty bugs cannot be isolated until I run through the exact scenario in a debugger. That doesn't just apply to Javascript, any two languages that fit the two descriptions will similarly be ranked in my eyes.

Re:COBOL was better than JavaScript.

[toejam13]

There's a good chance that, without JavaScript, the web would have vanished. You probably don't remember all the hype surrounding the "x internet" back in the early 2000's, but the web was on it's way out. If not for JavaScript (and XHR) the web would likely have been replaced by some other set of technologies.

We probably would have ended up with some variant of REXX or TCL on the client-side. Thankfully we didn't end up with Perl.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

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".

yep snotnose sound like one

Re:COBOL was better than JavaScript.

[Anonymous Coward]

> Be honest, can you not see the problem with a lack of block scoping?

Hmmm... you have to declare your variables at the beginning of the function? K&R worked that way for years and nobody suffered too badly. They added block scoping later, but only because programmers used to other languages whinged about it.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Dude, JavaScript *is* a simple Scheme implementation. The marketing guys said "make it look like Java", but at it's core the underlying semantics of JavaScript are much closer to Scheme than just about anything else.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

C is that same car with the mirrors, safety belts, and airbags removed.

...and only four wheels and no house trailer.

Re:COBOL was better than JavaScript.

[PC_THE_GREAT]

Javascript makes your browser a fat cow.

Re:COBOL was better than JavaScript.

[sjames]

And yet C ends up being safer because C++ deploys the airbags at random and makes you crash it....:-)

Re:COBOL was better than JavaScript.

[Anonymous Coward]

But unfortunately C leaks everywhere

Re:COBOL was better than JavaScript.

[Archibald Buttle]

Two words:
"use strict";

Put that at the top of a JS program or function and most of the "stupidly broken" parts of JS are disabled when you're in an ECMAScript 5 environment (i.e. any modern browser).

Most of the remaining complains about JS (like function scope, or prototype-based inheritance) are IMHO not problems at all, but rather reflections that people are far more used to class-based inheritance systems and how other languages work.

Yes, the language design isn't perfect. It was clearly rushed. It is by default too tolerant of dodgy syntax. There's loads of bad code out there written by second-rate programmers. Use a decent linter, read Crockford's "JavaScript: The good bits", and you'll find it can be a great language to work with.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

I'm pretty sure that's not one of the things a COBOL programmer would find broken... ... when he likes a language where the first 50 pages of a program is the variables. Because they are all global, and all declared at the top of the program (in the "DATA DIVISION").

Re:COBOL was better than JavaScript.

[serviscope_minor]

C++ is the programming language equivalent of a powerful but touchy sports car that's almost guaranteed to crash and burn in the hands of novice drivers, but can perform beautifully in the hands of an expert. C is that same car with the mirrors, safety belts, and airbags removed.

Not to mention the starter motor. And the distributor too. However cranking round the destributor by hand can give you a slight performance boost if you learn to hear the enging just right and can lead or lag by ear. Of course the novice gets electrocuted frequently and even the seasoned pro's can't often get it right but you're really in control whether you like it or not.

Re:COBOL was better than JavaScript.

[rdnetto]

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

What's not to love about a language with 3 different types of enums?

Re:COBOL was better than JavaScript.

[Archtech]

"There's a good chance that, without JavaScript, the web would have vanished".

How amusing - but quite untrue. Haven't you noticed how, throughout the history of computing, old standards regularly become unfashionable but virtually never disappear? Now consider that the Web was originally designed purely and simply to let people read hyperlinked documents - an extremely useful and indeed fundamental capability. It wasn't meant to display moving pictures, or serve as a virtual shop, or allow people to keep the world updated with what they have eaten or worn.

Without JavaScript, none of that would have been lost. Possibly, a new standard would have been invented to support all the trivial, self-indulgent uses, leaving the real Web unpolluted, efficient, and secure. Pity.

Re:COBOL was better than JavaScript.

[RabidReindeer]

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.

Ironically, COBOL was designed by a committee (CODASYL) for the government.

By all that we are constantly being told, that means that JavaScript, lacking such encumbrances, should be light-years better.

Re:COBOL was better than JavaScript.

[RabidReindeer]

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.

Well, there's that whole "null", "nothing", "empty string" crapshoot.

Re:COBOL was better than JavaScript.

[Drethon]

Only when you drill holes in it to make it lighter.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

> the web would likely have been replaced by some other set of technologies.

A dream. I can no more stand this pile of crap.

The Web, [...], is a joke. The Web was done by amateurs -- Alan Kay

Re:COBOL was better than JavaScript.

[Anonymous Coward]

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.

It also references "script" in its name, which should be a clue as to how and when to use it. Select the right tool for the job, is all I'm saying.

Re: COBOL was better than JavaScript.

[Anonymous Coward]

JavaScript is nothing like Scheme. This is obvious to anyone who has actually used both.

They have very different syntax. They have very different semantics. They are nothing alike.

Re: COBOL was better than JavaScript.

[Anonymous Coward]

I only know about enums and c++11 enum classes. What's the 3rd type?

(If you mean defines, the problem is with you, not c++.)

Re: COBOL was better than JavaScript.

[rdnetto]

'The C++ Programming Language' refers to plain enums, enum classes, and unnamed enums. Unnamed enums are just anonymous plain enums stored as integers though, so it's arguable whether or not they count a third type or not.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

That's not what I stated at all. My retort is specifically against this notion that nothing is broken with JavaScript. I've given various examples of what is broken with the language due to the lack of time and care (and appropriate management support) that went into the language. You may argue with my various individual examples but if you think that none of those are examples of how the language is broken then I think that you either don't understand the language or are just delusional. There are good JavaScript programmers and there are good JavaScript programs in spite of the sloppy language.

Re: COBOL was better than JavaScript.

[Anonymous Coward]

I wouldn't go so far as to call JS a "Scheme implementation," but it is indeed somewhat like Scheme.

Re:COBOL was better than JavaScript.

[genner]

......but speed holes make the car go faster.

Re:COBOL was better than JavaScript.

[genner]

Without javascript, vbscript and activeX would have gone unchallenged and the world would be a darker place.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Increased likelihood of programmer error as program size increases. Eventually unavoidable programmer error results due to the inability to keep track of minutiae.

Expectation of perfection leads to error, even if we raise the stakes to death:

http://en.wikipedia.org/wiki/Pilot_error

When the stakes are "This crappy site doesn't work properly" we can expect the error rate to rise accordingly. Good design dictates reducing the chance of error. Javascript lacks this philosophy.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Any weakly typed language needs to die. It's designed for people who think casting is difficult.

Re:COBOL was better than JavaScript.

[dkf]

We probably would have ended up with some variant of REXX or TCL on the client-side.

Almost certainly Tcl; the right engineers knew it at the time, but JS managed to get to a shipping browser slightly sooner.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Yes. Shame on you all for not realizing that Javascript behaving differently between environments is actually a feature and you all are just old men not embracing new technology if you don't like it that way.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

Without Javascript it's not all that likely that VBScript would've come into existence, at least as a web language. ActiveX definitely, but only because it's purpose is reusable components which just made it readily usable for a plug-in system in Internet Explorer.

The interesting thing about VBScript is that it was just one of many scripting languages that could be used with the Windows Script Host, which was used for automation scripting as well as web scripting. JScript, the Microsoft dialect of JavaScript, was the only other language that Microsoft themselves shipped out of the box but there were a variety of other languages available through third parties, including perl, python and tcl. All of these languages could also be used within the web browser. I think that, while messy, it would have been much more interesting to allow a plurality of web languages compete rather than allowing JavaScript to become the defacto standard.

Re:COBOL was better than JavaScript.

[eric_harris_76]

In his defense, I've heard that he cobbled it together pretty quickly for a demo/deadline/proof-of-concept, and was only after he delivered it did it transpire that what he delivered was what was to be used in the real world. Oops.

As I recall, this story came from Crockford, who I'm given to understand is not the most mellow of folks. If he's cutting Eich some slack, it's likely deserved.

Re:COBOL was better than JavaScript.

[LWATCDR]

I think that is the reason why we do not have a single programing language.
Cobol or Ada is for code that must work 24/7 365 perfectly.
Javascript for code that must work today.

Re:COBOL was better than JavaScript.

[Anonymous Coward]

but the web was on it's way out

"its".

Sensationalist BS?

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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.

Re:Sensationalist BS?

[Anonymous Coward]

As the GP poster, I suspect it's a combination of idiots and dinosaurs. :)

I actually work with a guy who actively resists using these technologies, despite my team's decision that "these are tools we will embrace and use where it makes sense."

As a result, nearly every time he delivers code, there's a flurry of "oh forgot this, oh forgot that, oh I forgot I fiddled this bit on my dev system and now it won't run on the test systems..." commits because he refuses to take advantage of a cleanly-rebuilt test environment. The sad thing is, we continually share vagrant files and puppet manifests with him, too. He could have a clean test env identical to the ones everybody else uses for the cost of 'vagrant init $box-name && vagrant up', but instead, he likes playing in his own little world.

What has changed

[Anonymous Coward]

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

[bobbied]

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:First post!

[Anonymous Coward]

And yet, you weren't first.

Legacy...

[Anonymous Coward]

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

Re:Legacy...

[Tablizer]

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

what a load of utter bullshit

[sribe]

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

[Tablizer]

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

[Anonymous Coward]

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.

Re:what a load of utter bullshit

[sribe]

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

[clockwise_music]

Please upvote this a million times.

Re:what a load of utter bullshit

[SimonInOz]

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

Re:what a load of utter bullshit

[Jeremi]

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

Hmm, perhaps Qt running in a NaCL environment? The only fundamental limitation would be that it's Intel-only, but then again so are most desktops these days.

Re:what a load of utter bullshit

[Anonymous Coward]

Or... we could just run Java.

Re:what a load of utter bullshit

[Anonymous Coward]

Or just use emscripten-qt.

Re:what a load of utter bullshit

[Lennie]

Actually, the limitation would be that it only works in 1 browser, Chrome.

Re:what a load of utter bullshit

[Anonymous Coward]

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.

Hence, Dart.

Re:what a load of utter bullshit

[Anonymous Coward]

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

Hmm, perhaps Qt running in a NaCL environment? The only fundamental limitation would be that it's Intel-only, but then again so are most desktops these days.

Does PNaCl help? (Portable Native Client)

Re:what a load of utter bullshit

[Tablizer]

Partly true, but the out-of-the-box widgets and feature set generally covered many more of the common GUI idioms than out-of-the-box HTML/CSS/DOM/JS. Those desktop kits generally handled about 85% of what you needed without requiring add-ons or additional big libraries, but with HTML/CSS/DOM/JS it's more like 30%. You gotta include a lot of stuff just to get GUI basics. Those common GUI idioms should be built into HTML (or equiv) in my opinion so that we get most of them declaratively. Combo boxes, sub-window resizing, most drag-and-drop, form field validation by reg-ex and/or types, partial/incremental-page "in-place" refreshes etc. should be commodity attributes and features by now. It's not like I'm asking for flying cars.

Re:what a load of utter bullshit

[Tablizer]

Part of the problem is that the default Java GUI framework is a bit awkward, and partly that applets don't solve the middle-ground between web-page and CRUD gui's.

Applets and Flash showed hints of what a better standard could be like from a developer perspective, but are sort of a walled garden away from the rest of the web, and tangled up in proprietary interests.

A good standard that fits well into both worlds would probably have to look like or extend HTML with common desktop-like GUI idioms already built in.

Explains a lot

[Anonymous Coward]

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

Second Verse:

[Narcocide]

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

That's you.

[khasim]

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.

[Anonymous Coward]

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:That's you.

[digsbo]

I disagree. Back then, we had dedicated people for source control, test automation, QA, build management, and so on. Now, that's been added to the senior engineer responsibilities. I do not believe that it was nearly as common to require senior developers to do all of that and still build systems 15, 20, 30 years ago.

Re:That's you.

[david_thornley]

Where I worked 15 years ago, that was pretty much additional tasks developers did. I administered the CVS repository, for example.

Somebody is projecting their delusions...

[gweihir]

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

[Anonymous Coward]

Do you remember Powerbuilder or Delphi?

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

Re:Somebody is projecting their delusions...

[Tough Love]

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

Only one difference: you get paid a lot more now.

completly useless article

[Anonymous Coward]

none of these things were new a decade ago.

snydeq = InfoWorld shill

[Anonymous Coward]

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

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

[gweihir]

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.

No retarded like clickbait retarded

[0xdeadbeef]

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.

Re:No retarded like clickbait retarded

[Trailer Trash]

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.

I hate it when I have mod points and comments like this are already at 5.

Re:No retarded like clickbait retarded

[volovski]

It is amazing that computers change every five years. Quite insightful. Who is the audience ? . What were the developers doing if they were sleeping ? Working on a health care website ?

What?

[Anonymous Coward]

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.

Re:What?

[Bengie]

Speaking on the topic of post optimization of hotspots, architectural design optimizations are important before any code is written for anything that may require performance. Some performance issues cannot be fixed after, and in many cases that I have witnessed, you could not phase in changes because the bad code design that led to the slow performance also limited refactoring, such that phasing in the changes would be worse that waiting for the entire rewrite to be completed.

To anyone who thinks they can start coding and fix/optimize their design mistakes after, ignorance is bliss. Design optimizations are one of the few premature optimizations that are almost a requirement for anything that requires scalability.

Profiling the kind of issues I deal with doesn't help much. Low CPU, low IO, low system call, low kernel time, low lock contention. Choose your poison. Many people are left scratching their heads wondering why the profiler doesn't show almost any hot spots, and the few hot spots yield little gain once optimized. Yet I get in there and tear things apart and can gain at least factors and many times magnitudes because the designer didn't understand how the entire system works as a whole.

hype

[knightghost]

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

Re:hype

[Bill_the_Engineer]

I seem to remember those two existing prior to twenty years.

Re:hype

[Tough Love]

I seem to remember those two existing prior to twenty years.

Indeed. 1972.

By Neruos

[Anonymous Coward]

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

Re:By Neruos

[Anonymous Coward]

In my experience, developers who say ignorant shit like this have never worked on a serious web app before.

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

[lgw]

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.

The more it changes this thing never changes

[AlanObject]

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.

dBASE [Re:Not changed much]

[Tablizer]

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.

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

[bobbied]

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

[lgw]

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

[Anonymous Coward]

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.

Not that simple

[fyngyrz]

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

Re:Not that simple

[Anonymous Coward]

Your comment has nothing to do with the one you're allegedly replying to, and nor does the quote.

Realised you'd left it too late to get the prominent position your comment obviously deserved, so you felt entitled to place it ahead of everyone else's by using the old "reply to the highest-placed leaf comment with something that has nothing to do with it" trick to jump the queue? Sleazy.

Re:Not that simple

[JimNoord]

Actually could not agree more. Our main professor in college in the 1980's told us if we wanted to be programmers, wed better be positione permanently by 1999-2000. As he said after that time programming would begin to become a lost art. This is the man that had us using "c" less than 5 years after k&r first edition was out. We had no )language courses). Our classes were "yada yada" using "c" or such and such with assembler. I ca say I learned "c" first because i was assembly cballenged, and seconccas a guinnea pig to test courses then taught with PASCAL with C. C++ was a direct response for people who couldnt understand pointers and linked lists, b-trees, etc. VISUAL BASIC was is a feel good approa h to coding.....draw the frm then copy some macros. Sorry that is not coding it is data entry. State of IT coders at resent is dismal. Without microsoft they are helpless.

Re:Not that simple

[Pherdnut]

Ironically a lot of JavaScript developers would tend to agree with a lot of your points. When you come to programming writing code for six to 20ish at least mildly disagreeing interpreters of the very code you're writing, many of them with their own proprietary versions of an essential API, you develop a healthy respect for reducing baggage, avoiding needless dependencies, and thinking very carefully about how to keep your code legible and easy to modify. I absolutely think over-reliance on IDES/tooling to read and fix the code for them has made a lot of Java and C# devs weaker programmers than they could be and that a side benefit of being able to execute code instantly is that JS devs were less interested in tools that did the work for them. I actually had a guy on StackOverflow tell me to stop joshing about actually writing reusable/portable code as if he couldn't imagine somebody doing something loosely coupled enough to make that possible no too long ago.

But don't be too quick to get on that garbage collection bandwagon. In many ways, the more dynamic scripting languages, JS in particular IMO, are closer to C in spirit than C# or Java because they are (JS in particular) informed by a design philosophy that doesn't give a rat's ass about protecting you from yourself or any B-grade programmers on your team. It is exceedingly flexible, will let you do spectacularly awful things to yourself and you get burned. And you learn. And you stop. And it happens pretty fast. What a concept. Power, flexibility and willful incompetence either adjusts or will want to show itself the door. I don't ever want it any other way. One of my favorite frameworks hinges on the concept of matching URLs with regular expressions. It's amazing how many useless jagoffs that knowledge requirement eliminates.

But there's really not much in the way of limits on performance in a language like JS or Python where you can very easily bind to C or C++. IMO, it's the perfect combination. All the higher level concepts and flexibility to build APIs that help you keep things lean and understandable and easy to modularize/reuse with all the performance you need when it becomes critical. I'm still a rank noob at C/C++ but the more I read up on C the more of a natural fit it feels like in tandem with JS. I couldn't write a maintainable app with it and I wouldn't have the first clue how but the JS, IMO is probably better suited to gluing things together. Or at the least I seem to have a hell of an easier time of it than the Java or C# devs and those were supposed to have an easier time of it than C/C++ but mostly I think they wandered off of that path and landed in this weird place where it was more about making sure you could still pull things off that were adequate with a bunch of mediocre programmers. And gee didn't that set the bar high. Most Java web devs at the median skill-level can't even be bothered to learn HTML.

I'm definitely not sure what you mean by large projects though. Do you mean like say... OS/2? Okay, maybe that was cheap but MMOs are certainly large projects. Windows finally got a near-total rewrite. Complex applications are constantly producing new versions with new functionality. The folks in Silicon Valley are doing very complicated things with very large sets of data nowadays. Larger, complex apps might be less representative in this latest technology explosion but I doubt there's fewer of them per capita than there were in your day.

Just because smartphones and the web have made smaller projects much easier to distribute, market, and profit from, doesn't mean people forgot how to write larger, more advanced apps, or got any less worse at making complete disasters of them for that matter. One thing I would say has dramatically improved is turnaround time on the UI side of things. With web technology and many other mostly-non-Java solutions we can knock out robust GUIs almost instantly compared to what I've heard from more veteran devs I'm friends with from the late '80s and '90s..

But seriously, if you still code for interest, give the JavaScripts and the Pythons a chance. You might find them surprisingly agreeable.

My list

[Dutch Gun]

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?

Re:My list

[Anonymous Coward]

Sure, why not. I work with avionics. Embedded engineer. We sell the the US Air-force and Navy, as well as other nations like Turkey, Korea, and Britian. Usually there are plenty of hops before you get to the end customer. Most of my co-workers are electrical engineers that picked up coding on the side.

Technology changes that have actually impacted us:
1) 16-bit architecture. We're STILL getting away from the 8051. The lasted "next gen" project using an actual microprocessor with glorious 32-bits was hideously mismanaged and everyone agrees we shouldn't use it's codebase for anything ever again.
2) Source control. I shit you not. They only started using a real code repository 4 years ago. It was one of the things I made sure to ask about during my interview, they didn't mention they only had it for a year and that half the engineers are still wary of it.
3) Bug Tracking. On a webpage rather than a physical piece of paper. It may seem like a no-brainer, but it blew their minds a few years ago.
4) Unit Testing. Trying hard to convince people that unit-testing is a good idea. Management keeps wringing their hands about any proposed change to software. And rightly so.

If that sounds like a blast from the past, well, it is. With legacy products that are being maintained from 30 years ago (and we're still considering software upgrades to fix bugs on them), and development cycles that last 2-4 years, there isn't a major motivation to change.

Re:My list

[Dutch Gun]

Ah, yeah, the good old 8051. I only know about it because I worked on some robotics projects in school, so my memories of that chip are probably fonder than your reality of having to maintain production code for them. Nowadays I think some programmers couldn't even imagine working with 128 or 256 bytes of run-time memory, and having to carefully allocate every single bit.

I'm glad to hear your company has gotten on board with those new-fangled source control thingies. :-) Please tell me you're not using CVS at least.

Keep pushing for unit testing if you can, although keep the approach low-key or your co-workers will just dig in their claws. Maybe see if you can discretely squeeze in some time to do some proof-of-concept demonstrations. Unit testing doesn't have to be complex or use a bunch of fancy frameworks, so it might be easier to sell the concept if they can look at some very simple C code (or whatever you use) and see how it works in practice. People get too caught up into making fancy frameworks, because programmers love writing systems, while occasionally forgetting that the point is not the system but the results.

Interesting list, thanks!

Was the author even around 5 years ago?

[Anonymous Coward]

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.

The tower of babel was already present back then.

[Ungrounded Lightning]

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.

I go back that far, as well.

And the proliferation of languages, each with advocates claiming it to be the be-all and end-all, was well established by the early '60s.

(I recall the cover of the January 1961 Communications of the ACM, which had artwork showing the Tower of Babel, with various bricks labeled with a different programming language name. There were well over seventy of them.)

Moar old man complaints

[istartedi]

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".

Re:Moar old man complaints

[Anonymous Coward]

I was in love once... a Sinclair ZX-81. People said, "No, Holly, she's not for you." She's cheap, stupid, and she wouldn't load. Well, not for me anyway.

Re:Moar old man complaints

[bbsalem]

If you don't use a slide rule, you have no right to complain, least of all about the difference beteen precision and accuracy :-)

Re:Moar old man complaints

[david_thornley]

You know, I used to punch cards for programs in several languages, including two or three different assembly languages. Then, when I try to learn x86 assembly, my brain revolts and I feel the need to stick to something relatively sensible (and I used to program Z80 assembly). I'd rather have the punch cards, thanks.

Re:Moar old man complaints

[david_thornley]

There are some nice slide rule apps on Apple's App Store now, and the iPhone fits into my pocket better.

However, the old slipstick was great at teaching me that I needed to have some idea what the answer was going to be before I started to compute.

Re:Moar old man complaints

[bbsalem]

Using a slide rule teaches the skill of thinking about orders of magnitude in results with low precision. Whereas a calculator provides a false sense of accuracy by always reporting lots of precision, too much precision, and shoving the exponent off to the right.

The down side is that if you are visually impaired, like me, you need a magnifier, but the discipline you need to use a slide rule is something young people should be exposed to, I think.

Re:Moar old man complaints

[Pherdnut]

You ran off with a Trash 80 didn't you?

Not true!

[Murdoch5]

In the embedded world I often use Assembly and C, even on the desktop it's not rare for me to C in order to avoid pointless overhead with weighty languages like C# or Java. A real programmer interfaces at the hardware level and tells a computer how to do it's job without having to use bulky objects, interfaces and abstraction. "Modern" programming bears little resemblance to programming because modern programming isn't real programming, it's falling back on managed, bulky overhead that does all the work for you. I wouldn't call a developer who uses C#, Java and basically sticks in object land a programmer because they don't program, they don't interface to the hardware to make a computer actually work. As a good rule of thumb, the more you get abstracted from memory, the less of a programmer you become.

Re:Not true!

[NormalVisual]

A real programmer interfaces at the hardware level and tells a computer how to do it's job without having to use bulky objects, interfaces and abstraction.

Ah, a variation on the "No True Scotsman" fallacy. A "real" programmer is familiar with a wide set of tools and the knowledge when to use each. There are times when that tool set includes the ability to read schematics and an oscilloscope or DMM to verify proper operation of hand-written assembly, and there are times when huge enterprise projects require tons of abstraction in a high-level language in order to keep the complexity manageable.

Frankly, I find web development a hell of a lot more challenging than embedded work.

Re:Not true!

[Murdoch5]

I find web development rather simple in comparison to trying to write a basic thread manager for a PIC18F uC, not saying you're wrong, just different views. I also would hardly call something this:

$window = new window("title", 640, 480).show();
$window.thread1 = new Thread(attach(Serial.IO.Ports.serialPort));
$window.thread1 = Start();

Real programming, That is kind of mock-up of PHP mixed with C# but my point is clear. A real programmer can write the thread manager and a developer just calls the start function. The amount of new grads who I interview that can't write something as a simple as a splay tree with lists at the nodes, in C, in under an hour, is frankly disappointing.

Re:Not true!

[NormalVisual]

I find web development rather simple in comparison to trying to write a basic thread manager for a PIC18F uC, not saying you're wrong, just different views.

I should probably elaborate on my statement - I find web development more challenging because of the variety of stuff beyond my control that I have to account for. Different OSs, different browsers, different interpretations of the HTML/CSS specs, etc., whereas in the embedded world, you generally have pretty tight control over the platform you're working with, and you can say with some degree of certainty that the processor is going to take X number of nanoseconds to run a particular block of code or respond to an interrupt. If I'm writing something to run on a microcontroller, almost any problem I have with the code not running properly is going to be the result of a something that I've screwed up myself. While I can certainly screw up in a higher level environment, there are constantly issues to deal with involving inconsistent or undocumented behavior of the platform, or component bugs not of my own doing that still have to be identified and worked around. You don't get stalled by unexpected garbage collection when working on a PIC in assembly, and you don't have to be familiar with 18 zillion frameworks just to get text out to an LCD.

I will definitely agree that embedded work demands a much more complete understanding of how the machine actually works and the ability to decompose a solution into much more detail, but it's much less fatiguing for me because there's a lot less crap getting in the way of getting stuff working. It's also a lot more fun. :-)

Re:Not true!

[Anonymous Coward]

Algorithms will always be more important then memory micro management.

stop Javascript abuse!

[Mr. Slippery]

Is it possible to write code for the browser without using jQuery?

Yes, dammit, it is. 90% of Javascript use is Javascript abuse, and 90% of legitimate Javascript use doesn't need a fscking bloated framework. Stop it already, anyone with a clue is running some sort of script blocker and your page just isn't important enough to make them choose to open holes in it for you.

Now get off my lawn.

Erosion of knowledge

[Anonymous Coward]

Probably not a problem for most slashdotters, and really this is at the border of what I would call application development... but a BIG concern for me at my organization is the erosion of basic knowledge as things become abstracted further. We have higher ups who know nothing about application development going all in on code generation frameworks (PRPC). A major consequence of this is that mid to senior level developers working on projects with this framework do not know and are not learning the basics about how things like HTTP work. I'm talking about people making 60k-80k who cannot explain how an HTTP session is maintained.

And while this framework promised the world in terms of quicker development times, it hasn't really delivered. Now we are stuck with a massive team of 'not really programmers' who are truly hopeless when it comes time to actually troubleshoot a problem outside the purview of the Pega Rules Process Commander. The number of times a day I have to tell people "trace it with fiddler" is mind boggling. To them, if an entry doesn't show in the PRPC log, the request did not occur. Mention the possibly that it failed at the web proxy and you've just invited yourself to a two hour meeting to discuss this mythical "iplanet" creature.

Even worse is that these types of frameworks flaunt a big "fk you" at typical design patterns like separation of concerns. Imaging an entire UI layer which is essentially a runtime generated servlet persisted as a set of un-complied java classes stored in a DB, while the actual persistence layer of the application is an XML blob stored in a DB. If we wanted to change the underlying framework of this application, it is literally pull the plug and start from scratch. An insane level of vendor lock in.

All the while, my team, still fighting what I consider the good fight, writing simple java apps based on established design patterns. But I have to ask myself daily if I am just becoming one of those old (31) gumpy devs who complains about the good ole days.

Pointless

[Anonymous Coward]

Not everyone programs for the Web. My job hasn't changed a lot in the last 20 years compilers are the same the IDs are a little better. ICE system where replace by debuggers.

Old news

[Tough Love]

This article reviews techniques that became common ten years ago, at least for programmers worthy of the name. Misses a lot too but oh well.

Dude, give me a break, you're being silly.

[Qbertino]

COBOL was better than JavaScript.

Yeah, right. ...
Dude, give me a break, you're being silly.

Sure, JS it's a tad more ambiguous than PLs from back when we used punchcards, but, come on!
So, yeah, JS has lose typing. Newsflash: That is a *feature*. You have to know how to handle it though (hint: COBOL style isn't going to get you anywhere here).
So it would be tricking writing ERP, because JS has more rope with which you can hang yourself - so, yes, you do actually have to watch out what you are doing in different way nowadays. And yes, there are a lot of non-programmers out there today writing code - I'm trying to write an extension for Typo3, so tell me about it.

So JS uses Protoyping instead of Classes - that's a feature too - get with the programm.

I don't like the syntax of JS either, it's ancient by todays standards and I'd prefer Python. But I can test my JS on the nearest computer, because the runtime is everywhere.

Truth is, JS runs everywhere nowadays, and allthough you should expect callback hell when writing larger serverside apps, that's actually an encouragement to do things unix-style for non-trivial projects. That's why so many people use it. Even those that can't programm. ... Yeah, that's anoying, but repairing their shite earns us the bucks, so go figure.

I suggest you sit your ass down, take a deep breath and get yourself aquainted with some non-amature JS code. There's a nice Oreilly called "JavaScript - The Good Parts" to get you started nice and easy.

But don't forget to chase the kids of your law before.

My 2 cents.

Re: Dude, give me a break, you're being silly.

[Anonymous Coward]

Pretending that bugs are "features" doesn't actually make them so. They're still bugs, regardless of how you may try to spin them.

GetElementByID ??

[hotcut]

I quote from page 2 of the article: "Does anyone even remember there's a built-in function called GetElementByID? Nah, libraries like jQuery now rule every level of the stack." Nop - it is called getElementById()... Obiously the author has fallen into the trap of jQuery ;)

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

[idji]

The most useful programming skills I learnt were in 1982 on the Sinclair ZX Spectrum. Nothing I learnt then has become irrelevant, just the languages changed. I give programming courses and am amazed how 21st century programmers are missing the basics and cannot write algorithms.

filter bubble more than technology

[Anonymous Coward]

More than any technology or methodology, it is the internet forum filter bubble than has changed programming more than anything. Programmers have become convinced that they don't have to get along with anyone in the real world, because they're smarter than everyone in the real world, and that doing things the hard way demonstrates their brilliance. The internet tells them so.

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

[cheekyboy]

The biggest problem is either too vague requirements by business or wrong requirements - thus wasting your time on things that are never used.

Or stupid requirements, product X does Y by magic.

Some of us do still assemble, even now

[Anonymous Coward]

I found this article highly amusing, reading about JQuery, social networks, etc. I write in VHDL and C. I just finished designing a custom DMA engine in hardware. I am lucky that my current project has a whopping 60 KB of memory! However, my processor has no hardware multiply unit, and I am using a stripped-down version of the C standard library that is missing the more expensive functions, like printf(). JQuery? I wouldn't even want to try to shoehorn a JavaScript interpreter onto this processor. Social networks? Please - I don't have anything like a network connection. Or a user interface. Or a human-compatible input or output device.

No, I am not working on old, obsolete hardware. I am working on very current, but deeply embedded hardware for things like automotive and industrial applications. Despite all the progress made on desktops and high-end severs, we always seem to find new uses for small (and increasingly smaller!) embedded systems with a few KB of RAM.

You can do BEST OF BOTH worlds (Delphi)

[Anonymous Coward]

Since Delphi allows "inline" assembly via the asm directive for FASTER LOOPS, by far (proof's http://slashdot.org/comments.p... there via research that I pointed out to a user named "perpenso" here, who did some AMAZING THINGS he pointed out vs. a compiler, unrolling loops & all, vs. assembly... I was, to put it lightly, IMPRESSED to no end!).

Delphi's almost always allowed it, & it works, for FAR better performance (except Delphi XE/XE2 afaik, but now XE3 onwards has it again like Delphi 2.0 - 7.1 did in 32-bit, albeit also multiplatform + 64-bit too!).

Lastly, iirc? MANY C++ compilers offer this option too of an inline assembly directive!

(However, I feel C++ is a bit more difficult & less readable than Delphi is, & Delphi can do *almost* everything C++ can, to a 99.999% level - multiple inheritance only afaik (yes, even drivers via addon toolkits), but lacks a multiple inheritance oop model, & instead, goes for the MORE PRACTICALLY APPLICABLE (imo @ least) SINGLE INHERITANCE model instead!).

APK

P.S.=> I'm no "assembly language wizard" either - I just KNOW a few "key areas" where it helps performance (like loops, which most programs do some of if they're not "hello world" trivial) & Delphi "KNOCKED THE CHOCOLATE" out of MS stuff in VB5 (watered-down C++ compiler) & even MSVC++ as far back as 1997 in of all places a competing trade journal "Visual Basic Programmer's Journal" Sept./Oct. 1997 issue "Inside the VB5 compiler engine" in 4/6 tests:

http://it.slashdot.org/comment...

(Especially in MATH & STRINGS work, which face it - EVERY PROGRAM does work in)

... apk

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

[lgw]

My team is hiring developers like crazy, and I see the same at all the big shops. Sorry if you can't find work - maybe move to the West Coast where the jobs are?

Having coded since 1980's I can tell you the diff.

[Anonymous Coward]

The biggest assets for coding used to be:
1. Intelligence.
2. Imagination.
3. Neatness.
The biggest assets for coding now is:
1. Memory.
2. Speed.
3. Having no pride in your work.

Things have changed indeed, not sure its for the better.

BTW. "Ceterum censeo Systemd esse delendam"

Started with toggles now do Data Warehousing

[Mister Null]

Ages ago I diddled with toggles on a PDP 8; first program was to update the program address counter by 1 every instruction. Now I do Data Warehousing which requires that I know the business at least as well as the business itself. So yes things have changed.

Re:We only use JS now? Linux Solution?

[bbsalem]

I used to think that, until package database corruption caused by repository changes forces me to completely re-install, then Linux becomes a problem. It becomes a problem with you ask a Linux novice to manually partition his drive so the can protect his files in a separate /home. something not done by default with he installs Linux so that when the package manager breaks after 18 months he has to re-install. This is too much work unless you have had UNIX system admin experience and to expect novices to tackle what should have been an option in the distro install is a big problem for Linux.