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.
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.)
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.
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.
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.
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.
I've helped to guide a bunch of SATA boards from prototype to product. From personal experience, I can tell you that a switch put together "half-decently" is very likely to result in unreliable SATA communication.
Well, if you include a few more pins, then you should be able to merely extend the current design to include the data cables...
Only if you want to deal with a bunch of CRC failures. You can't really expect to be able to mess around with signal lines when you're switching at 1.5 or 3.0 Gbps.
By convention, "lock-free" is sort of an ill-defined term that roughly means "no software-based locking operations, except maybe we'll ignore spin-locking, provided the algorithm always makes global progress while spinning occurs." In any case, there is no common definition for "lock-free" which implies the absence of hardware locking.
I'm not sure there is anything radically new in this project. However, given the exceptional difficulty of writing correct lock-free algorithms, just about any project exploring this area is noteworthy.
Um, no. A kilobyte is exactly 1024 bytes. It's "close enough" to 1000, hence the term "kilo". Why bother making up a whole bunch of new prefixes when there's one that already exists, especially given that it's blindingly obvious that the original meaning makes no sense in context?
Base-2 measurement does not offer any particular advantages when quantifying the storage of magnetic media; the capacity is a function of drive geometry and bit density, and has nothing to do with the number of logic gates on the board. So "in context" it is not blindingly obvious what number should be used.
Because context is not always enough to resolve ambiguity, reusing the SI prefixes was clearly a mistake. This is why we have binary prefixes.
The article mentions this being chose over sleuthkit, which makes me wonder just how much better (if at all) the software internals are on the TreCorder.
The key isn't so much the software as it is the hardware. The TreCorder uses hardware write blockers to provide a rather strong guarantee that the original data will not be corrupted even if the OS and the acquisition software happen to be written by idiots.
It's not distributed, so the project workflow is limited to the centralized model. It lacks powerful history-sensitive merging algorithms. It does not support "true renames." You can't run it purely off of widely available dumb file transports like sftp and http (it requires its own server).
Subversion is better than CVS, but that's about all you can say for it. The overall design is uninspired.
I don't find it terribly compelling at the moment. Subversion sucks*, and having a place to park the official website is pretty important.
As a fan of various distributed version control systems, the most important feature to me is a sizeable web space quota with sftp access. Just give me a place where I can mirror my repositories and put up a homepage. Throw in mailing lists and bug tracking, and I'd be happy.
* By "sucks," I mean "is incredibly limiting when compared to modern DVCSs."
You clearly asked the wrong people. Much like Debian, Ubuntu's packages can be found quite easily on its website. A quick search here leads to the kernel image package; there you can find a link leading you to the kernel source package used to generate the image.
The APT package management system also provides commands that make it quite easy to download source automatically.
I will definitely agree that reimplementing version control within an office suite is asinine. Better to leverage one of the existing VCSs, and almost certainly end up with a more powerful and more robust solution as a result.
Change management already exists in so many forms it's not even funny (cvs, svn, source safe, etc), and works off the shelf with any document format.
You make it sound like version control is a solved problem--it's not. A typical version control system will treat a spreadsheet as binary data and do nothing more than archive copies of each version. In contrast, applying version control to source code provides a lot of semantic information from each patch, due to the use of context diffs. If you're very lucky, maybe your spreadsheet application saves in some XML-like format that you can make a diff from... but even then, typical diff tools don't have any understanding of the document model, and consequently won't provide terribly useful changesets.
There's an argument to be made for domain-specific version control that applies to this sort of document (or at least domain-specific plugins for existing VCSs). A well-designed system could potentially assist in the task of merging changes from many authors into a single document.
The people who still attempt to create a classical home page generate something that's ugly and obsolete.
Ugly, perhaps, but hardly obsolete. No-frills static HTML is accessible to everyone, whether they're reading on a high-powered standards-compliant browser, a mobile phone, a textmode browser, or a screen reader.
If performance and memory usage are among your biggest concerns, maybe Wyrd would be a better fit. It's built on top of Remind, a Unix console calendar with powerful scripting capabilities.
Disclaimer: Yes, I wrote Wyrd, and am therefore thoroughly convinced of it's awesomeness. But in all seriousness, it's extremely fast and runs in under 2MB. Textmode applications have their advantages.
Am I the only one, having a somewhat strong immune system, that is not in the least bit worried about a pandemic?
Start worrying. Many of the deaths from the 1918 pandemic and from H5N1 have been related to a "cytokine storm," resulting in an overly vigorous immune response. The typical "healthy young adult" is very much at risk.
]]Only a small percentage of Java/C# libraries have Free implementations.
What are you talking about? You're free to use all of the standard java libraries without paying a dime.
This kind of free. (Don't read Slashdot much, do you?) Kinda lame to spend thousands of man-hours building a Free desktop only to have it depend on non-Free software, no?
]]Qt does multi-platform at least as well as Java.
ROFLMAO! Good one!
Glad I gave you a laugh, but I was actually serious. Java is riddled with platform- and VM-specific issues that pretty well kill the "write once, run anywhere" mantra. Qt generally ports pretty well.
]]STOP DRINKING MS AND SUN'S KOOL-AID.
SUN's Kool-Aid is great! Drink up!
For philosophical reasons, I only drink Free beer.
(Also, Sun is clinging to a failed business model and would be dead already if it didn't have so much cash in the bank. If it's board had any sense, they'd dissolve the company, sell off the assets, and return the money to investors. Their kool-aid sucks.)
OK. But Qt is already very extensive, and has the advantage that Trolltech's implementation is GPL'd. Only a small percentage of Java/C# libraries have Free implementations.
multi-platform compilation,
Qt does multi-platform at least as well as Java. C# is only sorta cross-platform, if you stick to the Mono project's supported API, and if you trust that Microsoft will never sue Novell over their C# implementation.
better API documentation
Qt's documentation is exceedingly good.
automatic garbage collection
OK. But Qt child widgets automatically get cleaned up when the parent is destroyed, so there is not a lot of fussing around with memory management in a typical Qt application.
more developers
More developers than C++? Questionable.
So why should KDE switch to C# or Java again? Is it for the increased memory usage? Or perhaps it's the desire to run on a non-Free VM with patent-encumbered libraries? Maybe it's just the masochistic desire to rewrite millions of lines of perfectly functional code?
No need for hacks like that... on a LAN with X remote you can't tell you're not working on the local machine, it's that good.
What if you're not on a LAN? High-latency links absolutely kill X performance, due to a large number of round-trips. The NX "hacks" are designed to address this issue (and provide more efficient compression, etc.).
A new lunar landing will help re-establish faith in our government, faith in ourselves, and faith in what we can achieve.
OK. Great. But at this point in time, the tangible benefits to US society from a lunar landing project are minimal.
Thomas Friedman has the right idea: fund alternative energy research on a scale similar to the 1960's space program. We could see all the intangible benefits you list, along with reduced energy costs, reduced pollution, reduced dependence on the resources of unstable or hostile nations, etc.
Ideally, we should have invested heavily in alternative energy research ten years ago. Realistically, it'll happen when gas costs $5/gallon. It is unfortunate that our political system does not reward long-term thinking.
Re:Can someone please explain to me...
on
Opera Free as in Beer
·
· Score: 3, Informative
FYI, someone did write an Undo Close Tab extension for Firefox.
Slashdot Mirror
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.
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.)
Objective, generic, functional -- its all there and accompained with the best preprocessor, macros and code generators
LOL
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.
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.
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.
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.
I've helped to guide a bunch of SATA boards from prototype to product. From personal experience, I can tell you that a switch put together "half-decently" is very likely to result in unreliable SATA communication.
Well, if you include a few more pins, then you should be able to merely extend the current design to include the data cables...
Only if you want to deal with a bunch of CRC failures. You can't really expect to be able to mess around with signal lines when you're switching at 1.5 or 3.0 Gbps.
By convention, "lock-free" is sort of an ill-defined term that roughly means "no software-based locking operations, except maybe we'll ignore spin-locking, provided the algorithm always makes global progress while spinning occurs." In any case, there is no common definition for "lock-free" which implies the absence of hardware locking.
I'm not sure there is anything radically new in this project. However, given the exceptional difficulty of writing correct lock-free algorithms, just about any project exploring this area is noteworthy.
Um, no. A kilobyte is exactly 1024 bytes. It's "close enough" to 1000, hence the term "kilo". Why bother making up a whole bunch of new prefixes when there's one that already exists, especially given that it's blindingly obvious that the original meaning makes no sense in context?
Base-2 measurement does not offer any particular advantages when quantifying the storage of magnetic media; the capacity is a function of drive geometry and bit density, and has nothing to do with the number of logic gates on the board. So "in context" it is not blindingly obvious what number should be used.
Because context is not always enough to resolve ambiguity, reusing the SI prefixes was clearly a mistake. This is why we have binary prefixes.
The article mentions this being chose over sleuthkit, which makes me wonder just how much better (if at all) the software internals are on the TreCorder.
The key isn't so much the software as it is the hardware. The TreCorder uses hardware write blockers to provide a rather strong guarantee that the original data will not be corrupted even if the OS and the acquisition software happen to be written by idiots.
It's not distributed, so the project workflow is limited to the centralized model. It lacks powerful history-sensitive merging algorithms. It does not support "true renames." You can't run it purely off of widely available dumb file transports like sftp and http (it requires its own server).
Subversion is better than CVS, but that's about all you can say for it. The overall design is uninspired.
I don't find it terribly compelling at the moment. Subversion sucks*, and having a place to park the official website is pretty important.
As a fan of various distributed version control systems, the most important feature to me is a sizeable web space quota with sftp access. Just give me a place where I can mirror my repositories and put up a homepage. Throw in mailing lists and bug tracking, and I'd be happy.
* By "sucks," I mean "is incredibly limiting when compared to modern DVCSs."
You clearly asked the wrong people. Much like Debian, Ubuntu's packages can be found quite easily on its website. A quick search here leads to the kernel image package; there you can find a link leading you to the kernel source package used to generate the image.
The APT package management system also provides commands that make it quite easy to download source automatically.
I will definitely agree that reimplementing version control within an office suite is asinine. Better to leverage one of the existing VCSs, and almost certainly end up with a more powerful and more robust solution as a result.
Change management already exists in so many forms it's not even funny (cvs, svn, source safe, etc), and works off the shelf with any document format.
You make it sound like version control is a solved problem--it's not. A typical version control system will treat a spreadsheet as binary data and do nothing more than archive copies of each version. In contrast, applying version control to source code provides a lot of semantic information from each patch, due to the use of context diffs. If you're very lucky, maybe your spreadsheet application saves in some XML-like format that you can make a diff from... but even then, typical diff tools don't have any understanding of the document model, and consequently won't provide terribly useful changesets.
There's an argument to be made for domain-specific version control that applies to this sort of document (or at least domain-specific plugins for existing VCSs). A well-designed system could potentially assist in the task of merging changes from many authors into a single document.
The people who still attempt to create a classical home page generate something that's ugly and obsolete.
Ugly, perhaps, but hardly obsolete. No-frills static HTML is accessible to everyone, whether they're reading on a high-powered standards-compliant browser, a mobile phone, a textmode browser, or a screen reader.
If performance and memory usage are among your biggest concerns, maybe Wyrd would be a better fit. It's built on top of Remind, a Unix console calendar with powerful scripting capabilities.
Disclaimer: Yes, I wrote Wyrd, and am therefore thoroughly convinced of it's awesomeness. But in all seriousness, it's extremely fast and runs in under 2MB. Textmode applications have their advantages.
Am I the only one, having a somewhat strong immune system, that is not in the least bit worried about a pandemic?
Start worrying. Many of the deaths from the 1918 pandemic and from H5N1 have been related to a "cytokine storm," resulting in an overly vigorous immune response. The typical "healthy young adult" is very much at risk.
]]Only a small percentage of Java/C# libraries have Free implementations.
What are you talking about? You're free to use all of the standard java libraries without paying a dime.
This kind of free. (Don't read Slashdot much, do you?) Kinda lame to spend thousands of man-hours building a Free desktop only to have it depend on non-Free software, no?
]]Qt does multi-platform at least as well as Java.
ROFLMAO! Good one!
Glad I gave you a laugh, but I was actually serious. Java is riddled with platform- and VM-specific issues that pretty well kill the "write once, run anywhere" mantra. Qt generally ports pretty well.
]]STOP DRINKING MS AND SUN'S KOOL-AID.
SUN's Kool-Aid is great! Drink up!
For philosophical reasons, I only drink Free beer.
(Also, Sun is clinging to a failed business model and would be dead already if it didn't have so much cash in the bank. If it's board had any sense, they'd dissolve the company, sell off the assets, and return the money to investors. Their kool-aid sucks.)
Vast array of common libraries
OK. But Qt is already very extensive, and has the advantage that Trolltech's implementation is GPL'd. Only a small percentage of Java/C# libraries have Free implementations.
multi-platform compilation,
Qt does multi-platform at least as well as Java. C# is only sorta cross-platform, if you stick to the Mono project's supported API, and if you trust that Microsoft will never sue Novell over their C# implementation.
better API documentation
Qt's documentation is exceedingly good.
automatic garbage collection
OK. But Qt child widgets automatically get cleaned up when the parent is destroyed, so there is not a lot of fussing around with memory management in a typical Qt application.
more developers
More developers than C++? Questionable.
So why should KDE switch to C# or Java again? Is it for the increased memory usage? Or perhaps it's the desire to run on a non-Free VM with patent-encumbered libraries? Maybe it's just the masochistic desire to rewrite millions of lines of perfectly functional code?
STOP DRINKING MS AND SUN'S KOOL-AID.
No need for hacks like that... on a LAN with X remote you can't tell you're not working on the local machine, it's that good.
What if you're not on a LAN? High-latency links absolutely kill X performance, due to a large number of round-trips. The NX "hacks" are designed to address this issue (and provide more efficient compression, etc.).
A new lunar landing will help re-establish faith in our government, faith in ourselves, and faith in what we can achieve.
OK. Great. But at this point in time, the tangible benefits to US society from a lunar landing project are minimal.
Thomas Friedman has the right idea: fund alternative energy research on a scale similar to the 1960's space program. We could see all the intangible benefits you list, along with reduced energy costs, reduced pollution, reduced dependence on the resources of unstable or hostile nations, etc.
Ideally, we should have invested heavily in alternative energy research ten years ago. Realistically, it'll happen when gas costs $5/gallon. It is unfortunate that our political system does not reward long-term thinking.
FYI, someone did write an Undo Close Tab extension for Firefox.