Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:"Like"? (Score 1) 389

In the long run, I'd expect the tools to adapt to solve those problems more transparently, e.g. through the use of standardized libraries that hide the parallelization behind procedural wrappers so that developers can write seemingly procedural code, but gain the benefits of massively parallelized code for the pieces that matter.

Or not; hard to say.

Comment Re:Lots of claims are being made about it's virtue (Score 1) 389

For that to be even ostensibly correct, you're missing one single quote mark and some double quotes, e.g.

"There are to many 'it's, don't you think?" he said.

And even that is arguable, because those aren't really apostrophes; they just happen to use the same key on the keyboard, typically.

With only two exceptions, the plural of any word is always spelled with an 's', not an apostrophe followed by an s. The exceptions are:

  • The plural of a lowercase letter (e.g. there are too many i's here).
  • The plural of an abbreviation that contains periods or mixed case (e.g. there are too many Ph.D.'s here).

And even then, those exceptions might depend on what style guide you go by.

Comment Re:It has its uses (Score 1) 389

Functional programming and unit testing are things you don't see widely used in the videogame development world, at least that I've seen.

I'd expect functional programming to be used quite a bit in that space, but only for very small chunks of performance-critical code, such as massively parallel bits down in the guts of raytracing engines. Now whether they actually use functional programming languages or not is another question.

Unit testing is something you don't see widely used in software development, period, unfortunately. But the industry is getting better. Slowly. Very slowly. Very, very slowly. Glacially, really.

Comment Re:Functional Programming Considered Harmful (Score 4, Interesting) 389

It needs to be done and done well. Very tempting. But alas, just like drug use, there's only so much any sane person can write about the subject, because anyone who knows functional programming well enough to fully explain why it is harmful is probably mentally damaged beyond the point of being able to understand why it is harmful. :-D

The thing is, functional programming is a good paradigm for students to be exposed to in school. Briefly. It forces you to think about data flow through your program, and forces you to think about your software as a giant state machine and visualize how the states change as your software does work. It is not the only way to teach that concept, but it is a halfway decent way. And once you pick up those concepts, you'll start to understand why singletons are so useful (approximately the polar opposite of functional programming, but often the software equivalent of the data you'd be passing around in a functional world).

So basically, there's a time and a place for everything, and it's called college. But just like with drugs, if you continue to do significant amounts of functional programming after that, don't be surprised if the rest of us ask what you're smoking. Functional programming as a real-world paradigm tends to be almost invariably a disaster, because it neither fits the way we think about problems (human thinking is almost entirely procedural) nor the way machines do work (computers are inherently procedural). It can provide useful extensions to procedural programming languages that serve specific purposes (e.g. closures), but calling functional programming useful for that reason is akin to calling a diesel-electric freight train a perfect commuter car that saves fuel because a Prius is also hybrid hydrocarbon-electric.

About the only space where functional programming techniques might really make sense is when working in a massively multithreaded environment, e.g. creating really efficient implementations of certain massively parallelizable functions (such as FFTs). But for the most part, that functional programming is limited to creating components that are then utilized as small (but performance-critical) parts in what is otherwise on the whole still procedural (or OO) software.

Outside of those very limited scopes, though, the theoretically ivory-tower-pure, zero-side-effect functional programming model is pure garbage. Real world systems don't just have side effects; they are side effects, whether you're talking about storing data on disk, sending it over a wire, drawing it on the screen, reading data from a keyboard, or whatever. The notion of treating all of those "side effects" as some giant state object that mutates as it gets passed around is fundamentally antithetical to real-world use of the data, because state must be stored to be useful. And the entire notion of passing around the complete state of real-world software is so far beyond infeasible that the concept is utterly laughable. Cell phones have a gigabyte of RAM, not a petabyte. There's simply no way to write something like MS Word in a pure functional language, because it would take all the computing resources on the planet to barely run a single instance of it.

Using functional programming in most real-world environments, then, cannot possibly do anything but cause brain damage, because the whole functional paradigm is wrong for the problem space. It is like cutting the grass on a football field using only a single pair of nail clippers—theoretically possible, but completely infeasible. To that end, although I wouldn't say that functional programming is inherently considered harmful, it should be approached with approximately the same level of skepticism as goto statements, and for approximately the same reason. When used correctly, in a very limited way, it is a powerful tool to have in your toolbox that can seriously improve your software. When overused or misused, it is a black hole that consumes infinite amounts of programmer time while emitting very little.

Comment Re:What do you people expect? (Score 1) 90

Where I used to work, we called this the "Stack Overflow Effect" because so much bad code written by well-meaning people was floating around Stack Overflow that did things in dangerous, security-risky ways, such as telling people to disable TLS chain validation so they could use a self-signed cert for their test environment, then wondering why so many apps shipped with chain validation turned off in the production versions of the app.

I've actually written security documentation whose primary purpose was to provide a single set of code snippets that were known to do things in the right way so that we could plaster Stack Overflow with links to the doc. Then, when people say, "but can't I just...", we can say, "No", and point them atdocumentation explaining why so that at least when they do something stupid anyway, we can say, "Dude, what part of 'no, that is incredibly dangerous' didn't you understand?"

Comment Re:Irony of ironies (Score 1) 168

Which is worthless if the payment terminal is compromised, because the card can't know it the payment terminal is sending out messages on its own behalf or on behalf of another hacked payment terminal on the other side of the country.

Transaction log:

  • Terminal 1 gets a chipped card that it recognizes as "special". It contacts a C&C server and finds Terminal 2.
  • Terminal 2 reads the card number from some poor sucker's card and sends it to Terminal 1.
  • Terminal 1 relays the response to the card provider.
  • The bank sends back transaction info.
  • Terminal 1 relays that to Terminal 2.
  • Terminal 2 sends it to that same poor sucker's card for signing, gets the response, and sends it to Terminal 1.
  • Terminal 1 relays the signed response to the card provider.

As far as the card provider is concerned, the card physically present in Terminal 1 was actually used in Terminal 2.

Comment Re:Irony of ironies (Score 1) 168

The chip doesn't do that much, really. Most attacks on credit cards for the past decade have been attacks on the payment terminals themselves, and there's nothing fundamentally preventing someone who has already compromised a bunch of payment terminals from setting up a C&C server, and using it to let them make purchases for free by making the payment terminals recognize their chip in some way and relay the request through a different payment terminal to somebody else's card.

The only thing that would truly increase security would be having a screen on the individual card that shows the purchase info and a button on the individual card that lets you authorize it. As long as the information display and the authorization keystroke are handled by a potentially insecure, Internet-connected device, the biggest security problem with these systems cannot be solved.

Comment Re: I find this thoroughly unsurprising (Score 1) 344

Like the traffic isn't already loud? Besides, they could be a little smarter about it and use RADAR to determine if traffic is moving, and honk the horn if nobody moves after two seconds. That would make it less frequent, but still nearly as effective. And drivers would quickly learn to pay attention to avoid the honk, so this would also have the effect of making itself moot.

Slashdot Top Deals

This is clearly another case of too many mad scientists, and not enough hunchbacks.