Please create an account to participate in the Slashdot moderation system


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Submission + - How to win the copyleft fight—without litigation (

An anonymous reader writes: The Software Freedom Conservancy's Bradley Kuhn is probably best known for his work in enforcing the GNU General Public License (GPL). Enforcement-by-litigation might get the headlines, but Kuhn treats the courts as a last resort.

A regular OSCON speaker, he returns this year to share the story of a project that avoided the courtroom. spoke to Kuhn about his talk and the free software landscape at large.

Submission + - Einstein and Schrödinger didn't believe in quantum indeterminism

StartsWithABang writes: When it comes to the very nature of quantum mechanics — about the inherent uncertainty and indeterminism to reality — it’s one of the most difficult things to accept. Perhaps, you imagine, there’s some underlying cause, some hidden reality beneath what’s visible that actually is deterministic. After all, a cat can’t simultaneously be dead and alive until someone looks can it? That’s one of the problems that both Einstein and Schrödinger wrestled with during their lives. An investigation of that story, their work on that front, and their friendship that ensued as both pursued that same end is thoroughly investigated here by physicist Paul Halpern.

Submission + - Tetris is hard to test (

JackDW writes: Tetris is one of the best-known computer games ever made. It's easy to play but hard to master, and it's based on a NP-hard problem. But that's not all that's difficult about it. Though it's simple enough to be implemented in one line of BBC BASIC, it's complex enough to be really hard to thoroughly test.

It may seem like you can test everything in Tetris just by playing it for a few minutes, but this is very unlikely! As I explain in this article, the game is filled with special cases that rarely occur in normal play, and these can only be easily found with the help of a coverage tool.

Comment Re:Blame the tool... (Score 2) 422

there are no bad languages, just bad programmers.

There are, however, languages that make it far easier to write code that is less readable and harder to maintain. As a specific example, compare Fortran 77 with Fortran 90. I can write the latter without any need for numerical statement labels. I can write a straightforward "DO WHILE" loop in Fortran 90, while in Fortran 77, I'd have to use the dreaded GOTO to get the same effect. Aside from basic stuff like that, I can write formulas in Fortran 90 with whole arrays, which can really help readability. In short, it is far easier to write clear code in Fortran 90 than in Fortran 77.

Do they seriously think that if those models were written in C, Java or Perl they would have been magnitudes better?

Heck, yes! For one thing, in any of those languages, separation of code and data -- something which spreadsheets actively discourage -- would be much easier.

Comment Re:Because C and C++ multidimensional arrays suck (Score 1) 634

FORTRAN was *NOT* designed to support multidimensional arrays from the beginning. That only came in Fortran 90.

Not true. Multidimensional array were around at least as far back as Fortran 77. Now what is new in Fortran 90 are the ways to manipulate those arrays. In Fortran 77, one could do arithmetic on elements of arrays but not on arrays as a whole, so, for example, adding two arrays in Fortran 77 required DO loops. In Fortran 90, though, one can add arrays A and B with the expression "A + B".

Comment Re:well (Score 2) 557

Actually, I think of the Russian occupation of Crimea as more analogous to the German occupation of the Sudetenland. The pretext for Germany occupying the Sudetenland was the presence of the ethnic Germans there, while for Russia, the pretext was the presence of ethnic Russians.

Comment Re:*nix desktops (Score 1) 503

There are a few catches with MacPorts, though:

1) Installing and updating ports usually requires compilation. There generally aren't ready-to-download binary packages. For a single package, this may not be a big deal, unless it drags in a bunch of other packages that also have to be compiled.

2) If one upgrades OS X, the MacPorts maintainers recommend deleting and reinstalling MacPorts for the new version of OS X. I'm not sure this is always necessary, but I've preferred not to risk it.

3) A given version of MacPorts targets certain OS X versions, and there's a lag time between when the latest release of OS X comes out and when a version of MacPorts comes out that targets that release.

There's also Fink, which shares problem #3 with MacPorts. It's supposed to have binary packages available, but when I tried it recently, that didn't work out, and it acted much like MacPorts, that is, downloading source and compiling it.