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:Another functional programming fan (Score 1) 338

Functional programming has its downsides. It tends to result in heavily nested code.

Beginner functional programmers nest their code too deeply, in exactly the same way that beginner C programmers nest their code too deeply. It's not an inherent property of the language.

It's hard to fan out results, so programs tend to be trees with a single result.

I have no idea what "hard to fan out results" is supposed to mean, but the conclusion is trivially disproven by the existence of lots of functional programs that do more than compute a single result.

Persistent state and I/O don't fit well with the functional model.

Persistent state works fine, it's just managed more explicitly: you take the "previous" state as input, and you return the "next" state as an output. Practical functional programming languages have a "functional update" syntax for struct/record types that makes it easy to do this sort of thing.

I agree regarding I/O. But OCaml is not a purely functional language, and the I/O implementation uses imperative syntax. It works just like it does in C. (Well, with the notable exception that printf actually type-checks its arguments at compile time.)

OCaml has some features that ought to be in more languages, like Djykstra's "guards" for choosing multiple alternatives.

The "guards" are a minor detail compared to the use of pattern matching for operating over sum types. It's the presence of a first-class sum type which makes these languages so effective at a wide variety of practical problems, because it gives the programmer a truly effective way to express the invariant that "either the data is of this type, OR the data is of that type, but not both". This is not mathematical bullshit, this is basic business-logic programming that happens all the time. In the mainstream programming languages, you don't have anything better to work with than a tagged union; that's a crappy solution.

The article, of course, elaborates on this. You should consider reading it.

Comment Re:the best. (Score 1) 553

The LOL was aimed at the boldface text. The C++ preprocessor is an underdesigned relic of C which integrates very poorly with the C++ feature set. To describe it as "best" is laughable.

(C++ is also a piece of shit for writing functional-style code, but I'll give that one a pass.)

Comment Re:Most misleading article ever (Score 1) 286

I don't agree that this is a hatchet job. I am concerned by the volume of highly-rated applications on the Android Market which require permissions that should be unnecessary. As you point out, the Android platform enumerates the requested permissions in a very visible way, which is great. The problem is cultural: users do not question these permission requests as much as they should.

I would really like to be able to selectively deny certain permissions to applications.

Comment Re:wire speed vs. practical maximums (Score 1) 191

People who have performance drives *already* use eSATA (seriously, firewire? Is this 2002? Worse, you then go on to talk about CPU usage, where again the answer is "use eSATA")

eSATA is a nice technology in general, and certainly looks like the future of commodity high-speed external storage, but I expect that it will take a couple of years before the OS/driver support matures. As evidence: take a random sampling of eSATA host controllers and you'll find a disturbingly small percentage that provide driver hooks to safely unmount the drive. You'll find an even smaller percentage that does this *reliably*.

1394 drivers are pretty mature these days, so one doesn't tend to run into those sorts of issues. 1394b also gets close to 80MB/s in practice (not just in theory); it takes a pretty fast HDD to saturate that kind of bandwidth. I would argue that 1394 is still a pretty good choice in 2009, although it's clearly on the way out.

Comment Re:How much trust is it asking? (Score 2, Interesting) 96

Not sure how serious you are, but you've got it backwards. A future FSF could create a GPL with more liberal terms of distribution. Suppose the license permitted binary-only distribution in exchange for a generous donation to the FSF--probably most developers would have a problem with that.

It's difficult to imagine such a scenario today, but I'm sufficiently paranoid to expect that the FSF may not always be trustworthy. All it takes is a gradual shift in the voting membership.

If the FSF continues to release reasonable licenses, a developer can retroactively relicense old software releases under the new versions of the GPL. No risk to the developer, just a little more bookkeeping work.

Comment Re:"minefield" ? GPL or FreeBSD (Score 1, Insightful) 96

if GPL then GPL v3 *and higher* (don't forget).

Or not. The "...or higher" language implies a great deal of trust in the FSF. There is risk in making that decision: the FSF could one day release a GPL which offers terms that the developer disagrees with.

It is entirely reasonable for a risk-averse developer to distribute software under a single well-defined license rather than an unlimited number of undefined licenses.

Slashdot Top Deals

One good reason why computers can do more work than people is that they never have to stop and answer the phone.