Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment: Re:What's more irritating? (Score 1) 251

by fractoid (#48930113) Attached to: One In Five Developers Now Works On IoT Projects
Oh, so that's what "IoT" is? Fucksake. As if "the internet of things" is somehow more special than the idea that as the tech gets cheaper, more and more things will connect to wireless networks. If this is going to be the next "cloud", I hope at least the cloud-to-butts browser addon gets updated so I can read about the Internet of Butts.

Comment: Re:Alternate Link (Score 1) 209

by fractoid (#48929579) Attached to: Ask Slashdot: What Makes a Great Software Developer?
What is this "technical track" you speak of? The last company I worked for (I'm currently working on a startup) had a single tier of engineers, a couple of "tech lead" / "senior engineer" roles (only available if you outlasted the incumbent), and everyone above that level (and there were 3+ tiers of them) was a nontechnical manager. Which is part of why I no longer work there but that's another story.

Comment: Re:Sort of like shitposting... (Score 1) 297

by Jeremy Erwin (#48927167) Attached to: The iPad Is 5 Years Old This Week, But You Still Don't Need One

I use my iPad to stream Amazon Prime video to my AppleTV-- technically I could use my Macs to watch the same streams, but they wouldn't be HD. This proved a welcome surprise, as many of the other services like Macs-- but demand additional payment for streaming to the iPad.

Comment: Re:Alternate Link (Score 1) 209

by fractoid (#48922813) Attached to: Ask Slashdot: What Makes a Great Software Developer?
I absolutely agree that curiosity (along with a willingness to actually RTFM) go a long way to making one indispensable in a team. However, that brings its own risks with it: If you can't be replaced, you can't be promoted. How do you balance the benefits to your career (in terms of increased productivity, reputation etc) against the risks (stagnation, either because they can't manage without you, or because they realise how productive you are and aren't prepared to lose your utility)?

Comment: Re:You nerds need to get over yourselves (Score 5, Insightful) 209

by fractoid (#48911995) Attached to: Why Coding Is Not the New Literacy

Programming is absurdly simple. Back in the 80's, you couldn't throw a stone without hitting a kid who wrote games for his home micro as a hobby.

There were plenty of kids who knew how to write "10 PRINT FART; 20 GOTO 10" or who typed in listings from magazines, and I agree that programming at that level is probably accessible to most people - but you can't equate that level of programming with modern software development.

You've probably noticed this yourself, but there are a LOT of really stupid professional developers.

I wouldn't phrase it as "really stupid professional developers". There are certainly a lot of incompetent professional developers, and they're part of what's formed my opinion about some people not being mentally equipped for software development. Do you honestly believe that such a proportion of people who make their living developing software are that bad at it purely because they're lazy, apathetic or unmotivated?

For the obligatory car analogy, most people are probably capable of learning to swap to a spare tyre, change the oil, or top up the radiator (learning some simple scripting). Most people are probably not capable of learning to design high-flow intake manifolds or variable valve timing mechanisms (useful commercial software development).

Comment: Re:You nerds need to get over yourselves (Score 5, Insightful) 209

by fractoid (#48911251) Attached to: Why Coding Is Not the New Literacy
Interestingly, it's not usually 'nerds' who push the idea that software development is something that everyone is even capable of, much less that it's something that most people should try and learn. It generally seems to be people who have grasped the basic idea that "programming means giving the computer instructions" and got excited about it, but never went beyond writing a few loops and some if() statements.

Anyone who's taught programming at a university level will know that even among intelligent students who want to learn, there are a large minority who (while they have many other valuable skills) are just not mentally wired to think in the way needed to develop software. It's a huge waste to try and push these people into doing something that they're not equipped for, instead of focusing on talents that they do have.

Comment: Re: Poor Alan Kay (Score 1) 200

by martin-boundary (#48903581) Attached to: Bjarne Stroustrup Awarded 2015 Dahl-Nygaard Prize
Essentially, they should never be used at all. If you're going to have an unrecoverable error, it's trivial to design the system to exit without using exceptions anyway.

Probably the most useful side effect of exceptions is printing the stack trace, and that's not something where the overhead (both performance wise, and logical complexity wise) of exceptions is needed. And you should really be doing logging rather than relying on cryptic exception traces.

The one theoretical case where exceptions are sometimes argued to be superior is if you don't know what to do locally about an error, and you're hoping that a higher level part of the program might know how to recover. Classic example is a read error, and then asking the user to put a usb stick in.

But guess what? That's not how nontrivial programs work. The higher level simply can't know fully the effect of handling an exception that bubbled up, because the low level details that matter can and often do have unpredictable consequences in terms of program correctness, especially when you're reasoning at a higher level. When an exception is thrown, your program state is wonky. Only trivial programs are like the usb stick example. Real programs become subtly wrong if you try to recover a partially completed, partially incomplete, multi statge operation, especially if you're not the guy who wrote the code, but feel you're doing the right thing at a higher level.

Your greatest chance of correctly handling errors is a few lines above or below where the error actually occurs. Anything else sounds good but is worse.

Comment: Re:Poor Alan Kay (Score -1) 200

by martin-boundary (#48897451) Attached to: Bjarne Stroustrup Awarded 2015 Dahl-Nygaard Prize

Exceptions are absolutely the right way to do error handling.

Really? You have no clue.

Exceptions are utterly wrong, they are Gotos Considered Harmful: An exception is basically a nonlocal jump and that's exactly the wrong way to do error handling, because it cause spaghetti logic, where pieces end up all over the place without any simple way to check what the code does besides unravelling the whole mess. And when multiple people maintain the code, it guarantees failures of logic.

The correct way to do error handling is _locally_, right where the failure occurs. It's the _nonlocal_ nature of exceptions which is evil because it causes brittle code and broken logic. Robust code requires that you handle all contingencies correctly. And you simply can't do that correctly way up the callchain except in trivial cases. But you can always do so at the site of the error. It's just very tedious and longwinded. But that's the difference between well written professional code and amateur hour anyway.

"Well hello there Charlie Brown, you blockhead." -- Lucy Van Pelt

Working...