a lot of entities public and private are throwing a lot of money at data mining research, reasonably expecting a big payoff, and sometimes it gets very good results indeed. The basic problem is that, as with any worthwhile CS question, doing it well is hard. It is very easy to come up with false connections between data. Sorting the wheat from the chaff in any kind of automated or even semi-automated fashion, OTOH, is an enormous challenge.
I would suggest that, in practice, the real difficulty is that the problems that need to really be solved for data mining to be as effective as some people seem to wish it was are, when you actually get down to it, issues of pure mathematics. Research in pure mathematics (and pure CS which is awfully similar really) is just hard. Pretending that this is a new and growing field is actually somewhat of a lie. It's avery very old field which people have been working on for a very long time, to the point where the problems that remain to be solved are incredibly difficult. What is new is someone other than pure mathematicians taking much interest in these problems. Do a search for "non linear manifold learning" on Google and you'll see what I mean.
As someone who has done datamining, ETL, and data auditing for very large systems (every transaction on every slot machine in a large Las Vegas casino for 5 years or so) I can assure you that the problem is not lack of data or issues with data entry. The problem, simply put, is that analysis is hard. The data is sitting there, but extracting meaningful information from it is far harder than you might imagine. The first hard part is determining what constitutes meaningful information, and yes that requires subject matter experts. Given the amount of money that can be made with even the slightest improvement, getting subject matter experts to sit down and work with the data people was not the problem. The problem is that, in the end, even subject matter experts can't say what is going to be meaningful - they know what sorts of things they currently extract for themselves as meaningful, but they simply don't know what patterns or connections are lying hidden that, if they knew about it, would be exceedingly meaningful. Because the pattern is a subtle one that they never even thought to connect they most certainly couldn't tell you to look for it. The best you can do is, upon finding an interesting pattern, is say "suppose I could tell you..." and wait for the reaction. Often enough with some of the work I did they simply didn't know how to react: the pattern was beyond their experience; it might be meaningful, it might not, even the subject matter experts couldn't tell immediately.
So how do you arrive at all those possible patterns and connections? If you think the number of different ways of slicing, considering, and analysing a given large dataset is anything but stupendously amazingly big then you're fooling yourself. Aside from millions of ways of slicing and dicing the data there are all kinds of useful ways to transform or reinterpret the data to find other connections: do fourier transforms to look at frequency spaces, view it as a directed graph or a lattice, perform some manner of clustering or classification against [insert random property here] and reinterpret, and so on, each of which expose whole new levels of slice and dice that can be done. If you'ev got subject matter experts working closely with you then you can at least make some constructive guesses as to some directions that will be profitable, and some directions that definitely will not be, but in between is a vast space where you simply cannot know. Data mining, right now, involves an awful lot of fumbling in the dark because there are simply so many ways to analyse the sort of volume of data we have collected, and the only real way to judge any analysis is to present it to human because our computers simply aren't as good at seeing understanding an interpreting patterns to trust with the job. Anytime a process has to route everything through humans you know it is going to be very very slow.
Linux doesn't have to be fat, it can be slimmed. That's how it runs on embedded systems. THe problem is X is huge, and not just the core X but once you add all of the things people expect, it takes a lot of ram and disk space.
The oft trotted out complaint that X is behind all the problems. I hate to break it to you but X is actually quite small if required, and highly adaptable. X is actually used for embedded systems, precisely because it is small (or can be made small). Here's a nice article on X and GTK+ in an embedded device. They managed to crunch an X and GTK+ based GUI down into only 2.9 MB, smaller than the QPE solution they were considering. It is quite possible to have X and a functioning GUI toolkit squeezed into a tiny space. The "things that come with it" that take up so much memory are things like Firefox and OpenOffice and a whole host high detail icons and whatnot. Try reading xrestop instead of top when you want to see how your memory is getting used - the figures that top reports are massively distorted.
You can get Design by Contract for Ada with SPARK. With the static analysis tools SPARK offers you've actually got a much stronger system with SPARK Ada than you have with Eiffel. If you're an Ada fan, check out SPARK.
Jedidiah
Re:the "pet rock" of programming languages
on
EiffelStudio Goes Open
·
· Score: 2, Informative
Design by Contract is particularly nice if you are willing to spend a little extra effort to write very reliable code, but it would be even better if there were good theorum provers out there to verify that contracts will always hold and warn if they don't. The would be much more developer friendly than the predicate calculus normally associated with formal methods.
If that's what you're looking for then I would suggest that you take some time to check out JML and ESC/Java2 which provides almost exactly that functionality for Java. It's not as clean as Eiffel as the contracts have be be kludged into Java as add-on annotation in comments, but all the functionality you'd want in a good expressive DbC system is there in JML, and ESC/Java2 provides a static checker/theorem prover that can attempt to verify contracts and provide warn you when they might fail. It also provides a number of other strong static checks based on JML annotations, allowing you to have high degree of confidence in well annotated code that passes ESC/Java2. Honestly, download JML, JMLEclipse and ESC/Java2 and try them out - you'll be amazed the number of subtle errors that can be quickly and efficiently caught!
His belief that a method should never return a value and have a side effect is particularly bad. Writing a stack with get_top() and remove_top() instead of pop() is a little weird.
It seems odd, but it does have nice aspects, particularly if you're used to a more functional perspective: it goes a long way toward isolating side effects and allowing better reasoning about the scope of effects that a given block of code may have. It certainly makes sense to me.
It's also worth noting that the GNU Eiffel com piler SmartEiffel provides a tool that can compiler Eiffel code to Java byte-code, so you can run Eiffel programs on a JVM too.
You have one polar opposite like Ruby, where you are free to do things using a variety of approaches. Then in the middle you have something like Python, where you are encouraged to do things using a certain Pythonic approach. Finally you have Eiffel where it's a certain way or else.
Which is bad if you just want to bash out code, but great if you want serious long term maintainability. Let's face it the ultimate "There's More Than One Way To Do It" language (hell, it's their motto) is Perl, and we all know how wonderfully mantainable that is...
It all comes down to what is more important for the project at hand: flexibility, or maintainability. If flexibility is what is most important, Eiffel is probably not the best choice for that project. If you want maintainability though - that's when Eiffel, with it's very clear "One Way To Do It" syntax, clean OO design, and built in Contract support really start to shine.
Use the right tool and all that.
Jedidiah.
Re:Back in the day, before C++ was the "winner"...
on
EiffelStudio Goes Open
·
· Score: 1
Back in the mid 80's, when the OO paradigm was first starting to gain traction (but it wasn't obvious that C++ would become the first mainstream object-oriented language) there were debates about whether the big OO language of the future would be C++, Smalltalk, or Eiffel.
And the more time has gone by, the more it looks like either of Eiffel of Smalltalk would have been far better choices. When it comes to clean OO design both Eiffel and Smalltalk are way ahead of C++. All C++ really had going for it in comparison was traction with C developers - that provided it with enough critical mass to win the mindshare market. If you don't know Eiffel then spend an evening reading about it some time. It's easy to learn, has very clear readable syntax, and a very well engineered OO design (far cleaner than anything C++ offers).
Jedidiah.
Re:the "pet rock" of programming languages
on
EiffelStudio Goes Open
·
· Score: 5, Informative
Programming by contract is essentially just writing twice as many unit tests, wrapped all around the code that is supposed to be doing the work.
Programming by contract is writing your unit testing harness as assertions while you write the code, and having those assertions respect inheritance elegantly, saving you considerable work if you actually have any sort of class heirarchy built up in your code. Programming by contract is about stating clearly how you intend your code to work so that it is much easier to determine whether the code you wrote actually does what is intended or not. Programming by contract is about providing clear and explicit documentation of the interfaces making code reuse and code maintainability far easier.
Programming by contract is not the right choice for every programming project. Sometimes you want flexibility. Sometimes rapid adaptability is more valuable than correctness or maintability. Sometimes, however, it is not. I don't draw up careful plans to build a treehouse, I hold the wood where I want it to go and cut it to fit: being able to adapt to the exact organic shape of the tree is more important than the strict integrity and finish of the treehouse. Likewise I don't build home by nailing 2x4's together and cutting the next chunk to fit: Having a truly solid structure, with all the walls and floors are properly aligned is more important than the speed with which I can get started building something. Different projects have different needs, and there are plenty of projects for which Design by Contract is a fantastic way to go. Just because you, personally, don't happen to work on those projects, doesn't invalidate its usefulness for others who do.
What are the differences between Eiffel and other free object oriented programming languages? What does Eiffel have that Ruby, Python, and Java do not?
Compared to Ruby, Python and Java the biggest thing Eiffel has going for it is raw speed. Consider the benchmarks and you'll see Eiffel is much much faster than Java, with considerably less memory use. You get that sort of performance from a langauge with an exceptionally clean, well designed and engineered OO system, and great support for Design by Contract, and a very clear readable syntax: learning Eiffel is very easy.
If you're doing very dynamic work that really calls for the flexibility of Python or Ruby, then Eiffel probably isn't for you. If you want something to build robust complex large scale systems then Eiffel is actually better than Java for producing robust, well documented, reusable, maintainable code - and its faster to boot. Java, of course, has its own advantages in terms of "run anywhere" and its huge standard library, but Eiffel is well worth acquainting yourself with.
I haven't heard of this language, and don't want to do too much research (go go procrastination!). Can anyone tell me some of the basic info about this, and what makes it different? Why would I want to use this language over something already available, for example.
Eiffel has been around for a long time, and is a mature language. What does it offer? A very clean and well designed Object Oriented language with a very clear and readable syntax and great support for Design by Contract. The principle behind Design by Contract is simple enough: objects, and methods provide contracts - providing you meet their stated requirements, the guarantee things in return. Statically typed languages offer some level of this already: you have to provide paramters of the right datatype, and it guarantees the datatype of the return type. Design by Contract essentially just extends this principle to allow for much more expressive contracts than just type signatures, and things like object invariants (properties of an object that are guaranteed not to change). The result is a much clearer statement of intention as to how code should work, and a powerful test harness that massively speeds up the test/debug cycle. In theory you can achieve this by liberally sprinkling assertions through your code. The advantage of having a language with explicit support for Design by Contract is that things like inheritance of contracts and invariants are all handled automatically and elegantly etc.
As well as this release of EiffelStudio as open source, there's SmartEiffel which is an open source Eiffel compiler (which supports a number of extra features beyond what is given in the recent ECMA spec).
Hardly. Giving them a computer solves none of their needs.
It really depends on whether you're just dumping a Dell laptop in their lap, or giving them something designed and targetted to be as useful as possible. That is it depends on hardware designed specifically to fit their needs, and what actually gets loaded onto it in the way of software.
a basic education would be needed before you give them a little white box
They would have to have learned to read at least, yes - our technology isn't quite advanced enough to teach children to read yet. Once they can read however the computer could quite conceivably come loaded with a lot of basic educational material such as basic mathematics through to algebra, plenty of reading material (potentially localised to be in their native language), and whatever else people see fit to include. It would not be that hard to provide enough material and software to make the laptop a complete resource for basic education to anyone motivated enough to sit and use it - and there are people who want the opportunity to learn desperately: don't think they wouldn't take advantage.
hell maybe you might even want to consider reliable power and communication networks before giving them such a wonderful tool for communication.
Or you could recognise that laying out massive power and communication infrastructure is going to be not just expensive, but extremely time consuming. With that in mind you cna design your laptop to have low power modes and long battery life to deal with intermittent power, as well as a hand crank to deal with a complete lack of power. You can also design your laptops to automatically create a peer to peer mesh network amongst each other for communication, spontaneously creating a new network wherever you put the laptops rather than relying on the slow arrival network services.
When you teach a man to fish you don't hand him a yacht, you give him a small fishing pole.
And when you want to provide someone who is self motivated with a basic education you give them a book. Or maybe you could give them a complete library of interactive books, access to a communication network, and a device that can expand to fit their needs all in one nice little durable package that they can take anywhere. Thinking that a child with a thirst for knowledge can't make use of a computer loaded with all manner of suitable educational material and interactive software is to grossly underestimate that child. These laptops have the potential to be amazing. Sure, there's still plenty of room for bureaucratic fuckups, or toher failures that ensure what actually gets delivered is far from the potential of what it could have been, but Negroponte and all seem quite determined to make it as good as possible.
This isn't about making a computer cheap enough that you can hand it to a child. This is about designing and building an educational tool that you can hand out and give people access to the sort of education so many of us simply take for granted.
Why do these countries need a widespread distribution of $100 computers?
It's aiming to be more than just a laptop, it is being designed for the express purpose of being an ideal educational tool for children in third world countries. Haven't you ever read "The Diamond Age" by Neal Stephenson? Think of it as our primitive version of "The Young Lady's Illustrated Primer" based on the technology we have available at our disposal currently. That sounds like a worthy goal to me.
f it were all about cheap computers for poor nations, just publish the specs and be done with it. Or just collect and ship used throwaway computers overseas.
The point, as Negorponte said, is that this is an educational project, not a project about cheap computers. If the aim was just to throw a random lump of computer hardware in front of a kid in the thrid world then indeed used computers would be fine. The project is trying to do more than that however, and that means more effort needs to be spent on the design. The laptop needs to be incredibly robust and durable, otherwise they'll just get broken immediately. It needs to have low power modes, and the ability to be hand-powered because the reality is that electricity is at best intermittent in many parts of the world where they hope to distribute these. It needs to have its own system for automatically generating its own network on the fly with all the other laptops because many parts of the world don't happen to have free WiFi access. There are a hundred other such constraints and requirements, all of which require special engineering. The point is not to give kids cheap computers, the point is to give them cheap devices that are designed from the get go for the express purpose of being as useful as possible in educating children in third world countries. That means you need more than some second-hand Dell.
Greenland used to be green 1400 years ago, I guess it was either cow or ocean flatulence or we had an enormous population of UFO drivers spewing CO2 that left a while ago. Or climactic cycle.
Greenland was not green 1400 years ago. At best we can say that it was settled by Norse around 980 CE. The Norse had 2 settlements, both of which have now been found, and both of which were in relatively sheltered fjords that today are quite green and have lush pasture. Of course the Norse had a hard life their. The growing season was short, and even the areas in which they settled that had pasture produced small amounts. Greenland cattle were the smallest cattle known, standing only 4 foot high, largely from malnutrition. There is good evidence that during the winters when the cattle were kept in barns they had to be force-fed seaweed due to the lack of hay produced over the summer. The Norse also had to eat a lot of seal, definitely not a preferred food for them, due to the lack of food available from their traditional sources (crops, dairy products, and sheep, goats and cows).
Today there are sheep farms in the same areas of Greenland that are coping at least as well as the Norse ever did. The best we can say is that Greenland was perhaps around as warm as it is now in 890 CE. And even that says little about global variation of temperature: according to temperature reconstructions using tree rings, ice cores, glaciers, coral, etc. at times when northern hemisphere areas like Greenland were warmer the southern pacific was colder, meaning despite fluctuations in local temperature over time, the global average changed a lot less. Now, however, it is the global average that is moving significantly.
The better way to deal with it would be determine the sustainable amount of carbon dioxide we can emit, chop it in half to be really sure, and produce tradable emission rights. If you don't have the right to the emissions, you can't emit it. The market will set the correct price for the emission rights.
The big problem with my plan is enforcement, you'd probably have to require the producers of the fuel to have the emission rights rather than the emitter.
I would think ideally you would simply fix a price on carbon emissions, with the cost for emissions going into a global climate change mititgation fund (money to be used to efforts to mittigate the effects). Once the right is bought it an be traded as normal. Perhaps a country will simply buy the rights they need by paying into the fund, or perhaps they'll tax their individual emitters over it, or perhaps producers (like oil producers) will buy rights and seel them packaged with their product ("oil from us is free of emissions charges - they are already paid"). The problems, as you note, are of enforcement, and secondly (and this is the big one) administering what is going to be a truly vast slush fund and trying to see that it gets used well (and for its intended purpose and not funnelled off into unrelated projects).
That crack-whore welfare mama with 18 children is more fit evolutionary wise than the lonly artist who creats beautifull paintings but kills himself due to depression before breeding.
More genetically fit yes, but the artist is more memtically fit: a lot more people will copy the artists ideas than will copy the crack-whore. Ultimately it is as much our thoughts and ideas that define us as it is our genes.
Didn't the NSA put out a distro specifically for high security applications a few years ago??
The NSA produced a kernel patch and a set of userland tools called SELinux which provided a much richer and more fine grained security model for Linux, but no actual distribution. In practice this was essentially done as a "proof of concept" by the NSA who were frustrated by the lack of serious security architecture in modern operating systems - they decided the easiest way to get the ball rolling was to take something freely available and modifiable, like Linux, add the better security architecture and hand it back to show how things could be done. Since then that work has been converted into the Linux Security Module which provides support for the general architecture suggested by the NSA in a more modular fashion, and SELinux was adapted to work within such a system.
What does SELinux actually buy you? To quote the NSA FAQ:
"The Security-enhanced Linux kernel enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. When confined in this way, the ability of these user programs and system daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example) is reduced or eliminated. This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).
The security of an unmodified Linux system depends on the correctness of the kernel, all the privileged applications, and each of their configurations. A problem in any one of these areas may allow the compromise of the entire system. In contrast, the security of a modified system based on the Security-enhanced Linux kernel depends primarily on the correctness of the kernel and its security policy configuration. While problems with the correctness or configuration of applications may allow the limited compromise of individual user programs and system daemons, they do not pose a threat to the security of other user programs and system daemons or to the security of the system as a whole."
Paper elections have been forged before. Why should we believe that a forgeable system makes an insecure system secure?
I think it's a question of redundant systems which can be independently verified. What would I like to see in an electronic voting system? I would like machines with a published hardware design, open source code according to full published formal requirements with a formal specification, published correctness proofs, and verification of the code against the specification, backed up by a redundant system of paper reciepts (turned in at the voting centre).
Sure, that sounds like a lot of trouble, but if ever there was a situation where all the open specifications, formal theorem proving and code verification were worth the cost and effort surely voting would be it. It provides a number of independent ways to verfiy that things are behaving correctly.
Jedidiah.
Re:What's with the "dump OSX" theme?
on
Apple Joins BAPCo
·
· Score: 1
And no, it's nothing like the switch to intel... processor flamewars were always foolishness: who really cares what processor architecture is underneath?...It's all about the user experience, and OSX is the experience Apple wants to deliver.
To be fair any of the detailed versions of the claims of Apple moving to Windows describe Apple using the Windows kernel and simply layering the MacOS GUI on top of that. Under that sort of claim the user experience wouldn't really change and it would be more like switching procesors because "who really cares what kernel is underneath?"
It's still a stupid claim and ridiculously unlikely to happen of course - the benefits (compatability and being able to run all Windows applications) don't stack up at all when compared to the costs (managing to port the MacOS GUI over and dealing with issues of integrating native Windows programs into that environment).
The Tarkovsky film version was fantastic. Sure it focussed on different aspects than the book, but in many ways it picked some of the more interesting points that were only peripherally explored in the book. Besides, film is a different medium, so the detailed wordy technical discussions must necessarily become limited. Instead we are treated to visual subtlety and mystery and the absolutely glorious cinematography that is par for the course with Tarkovsky. I rate Tarkovsky's two ventures into science fiction, Solaris and Stalker, as two of the greatest science fiction films ever made - science fiction films that are honestly interested about exploring ideas and giving the audience the space to fully appreciate the depth and subtelty of those ideas. They are films where you are fully expected to spend your time thinkin carefully about everything that is going on.
The Soderbergh film was comparatively truncated and necessarily lost a lot of the material. It was also, in practice, working more from tarkovsky's vision than from Lem's. Still, it managed to create much of the atmosphere and explore many of the ideas of the Tarkovsky film in the reduced time frame. Certainly a great film - though I agree, beginning to be quite divergent from the book.
Iain Banks for a remarkably positive view of the future with the culture novels, and a remarkably bleak view of the future with his non-culture novels.
If the article is true, and prime numbers can be gleaned from quantum stuff, and quantum computers are just around the corner
Well all of that is only tenuously related, but okay...
will that obsolete all our public key encryption tools?
Quantum computers will, yes. Not because information about the distribution of prime numbers is intertwined within quantum energy levels, but because there exist polynomial time algorithms for factoring and discrete logarithms given a quantum computer. Since all our current public key encryption schemes are based on the difficulty of one of those two problems quantum computers will render current public key schemes rather ineffective.
How does this affect quantum encryption?
It doesn't. Quantum cryptography isn't really encryption in the same sense, and doesn't have anything to do with quantum computers. The general principle is that using suitably encoded data the quantum theory effects of observation changing the object can be used to ensure that you can always know if someone has intercepted/observed your encoded message during transmission.
Will we have to wait for our household Mr. Fusion reactors to power these systems to maintain encryption?
Probably not.
Will all this happen within the next 5 years?
No. Currently the most powerful quantum computers in the world can factor numbers as large as 15. While progress is being made it is very slow and it is ridiculously improbable that any quantum computer capable of factoring numbers commonly used in encryption existing within the next 5 years, let alone anything that might actually have any sort of mainstream availability.
if the eagles could snatch the heroes off the top of Mt. Doom after all this noise, why couldn't they have simply sent the eagles to drop in the ring?
The long answer (in the sense that it requires all the extra backstory of the creation of Middle Earth, its Gods etc) is that the eagles are servants of Manwe and do his bidding, and essentially the Valar (Gods of Middle Earth, of which Manwe is one) have a policy of non-involvement (the bulk of the Silmarillion is about the woes of the elves who leave the Valar and go back to Middle Earth and have to struggle alone - it is only resolved when a half-elf manages to navigate the seas back to the Valar and plead the elves case). The eagles are not about to step in and help just because the elves, humans, or dwarves want them to. The Valar are not completely uninvolved mind - they sent Gandalf to come and guide things where necessary. The point, however, is that he is just that: his job is to spur the people of Middle Earth to stand up and resolve the problem themselves, providing occasional help along the way when absolutely necessary.
The short answer is that the eagles serve the Gods, and the Gods, from their longer term perspective, view the whole thing as a good character building exercise: they'll provide a little help when absolutely needed provided the people of Middle Earth actually stand up and do most of the work themselves.
Jedidiah.
Re:The books and PJ's movies were the only good on
on
LOTR Jumps the Shark
·
· Score: 1
I think the film trilogy actually doomed the musical to some extent. Adapting the books is a remarkably difficult task, and as you note, the standard result is a mess. While there are many here who will decry the movies as debauchery of the books the reality is that, all things considered, they were remarkably well done, highly entertaining films. Against the background of such a successful adaptation anything short of a miracle of a musical was always going to look poor - the reality is that the films simply set the bar of expectation far too high and there was no way that a musical could live up to it. I suggest that had the films never been made, the musical, while not getting rave reviews, would have been hailed as a remarkable achievement and generally gotten far more positive reviews than it has.
Slashdot Mirror
a lot of entities public and private are throwing a lot of money at data mining research, reasonably expecting a big payoff, and sometimes it gets very good results indeed. The basic problem is that, as with any worthwhile CS question, doing it well is hard. It is very easy to come up with false connections between data. Sorting the wheat from the chaff in any kind of automated or even semi-automated fashion, OTOH, is an enormous challenge.
I would suggest that, in practice, the real difficulty is that the problems that need to really be solved for data mining to be as effective as some people seem to wish it was are, when you actually get down to it, issues of pure mathematics. Research in pure mathematics (and pure CS which is awfully similar really) is just hard. Pretending that this is a new and growing field is actually somewhat of a lie. It's avery very old field which people have been working on for a very long time, to the point where the problems that remain to be solved are incredibly difficult. What is new is someone other than pure mathematicians taking much interest in these problems. Do a search for "non linear manifold learning" on Google and you'll see what I mean.
Jedidiah.
As someone who has done datamining, ETL, and data auditing for very large systems (every transaction on every slot machine in a large Las Vegas casino for 5 years or so) I can assure you that the problem is not lack of data or issues with data entry. The problem, simply put, is that analysis is hard. The data is sitting there, but extracting meaningful information from it is far harder than you might imagine. The first hard part is determining what constitutes meaningful information, and yes that requires subject matter experts. Given the amount of money that can be made with even the slightest improvement, getting subject matter experts to sit down and work with the data people was not the problem. The problem is that, in the end, even subject matter experts can't say what is going to be meaningful - they know what sorts of things they currently extract for themselves as meaningful, but they simply don't know what patterns or connections are lying hidden that, if they knew about it, would be exceedingly meaningful. Because the pattern is a subtle one that they never even thought to connect they most certainly couldn't tell you to look for it. The best you can do is, upon finding an interesting pattern, is say "suppose I could tell you ..." and wait for the reaction. Often enough with some of the work I did they simply didn't know how to react: the pattern was beyond their experience; it might be meaningful, it might not, even the subject matter experts couldn't tell immediately.
So how do you arrive at all those possible patterns and connections? If you think the number of different ways of slicing, considering, and analysing a given large dataset is anything but stupendously amazingly big then you're fooling yourself. Aside from millions of ways of slicing and dicing the data there are all kinds of useful ways to transform or reinterpret the data to find other connections: do fourier transforms to look at frequency spaces, view it as a directed graph or a lattice, perform some manner of clustering or classification against [insert random property here] and reinterpret, and so on, each of which expose whole new levels of slice and dice that can be done. If you'ev got subject matter experts working closely with you then you can at least make some constructive guesses as to some directions that will be profitable, and some directions that definitely will not be, but in between is a vast space where you simply cannot know. Data mining, right now, involves an awful lot of fumbling in the dark because there are simply so many ways to analyse the sort of volume of data we have collected, and the only real way to judge any analysis is to present it to human because our computers simply aren't as good at seeing understanding an interpreting patterns to trust with the job. Anytime a process has to route everything through humans you know it is going to be very very slow.
Jedidiah.
Linux doesn't have to be fat, it can be slimmed. That's how it runs on embedded systems. THe problem is X is huge, and not just the core X but once you add all of the things people expect, it takes a lot of ram and disk space.
The oft trotted out complaint that X is behind all the problems. I hate to break it to you but X is actually quite small if required, and highly adaptable. X is actually used for embedded systems, precisely because it is small (or can be made small). Here's a nice article on X and GTK+ in an embedded device. They managed to crunch an X and GTK+ based GUI down into only 2.9 MB, smaller than the QPE solution they were considering. It is quite possible to have X and a functioning GUI toolkit squeezed into a tiny space. The "things that come with it" that take up so much memory are things like Firefox and OpenOffice and a whole host high detail icons and whatnot. Try reading xrestop instead of top when you want to see how your memory is getting used - the figures that top reports are massively distorted.
Jedidiah.
You can get Design by Contract for Ada with SPARK. With the static analysis tools SPARK offers you've actually got a much stronger system with SPARK Ada than you have with Eiffel. If you're an Ada fan, check out SPARK.
Jedidiah
Design by Contract is particularly nice if you are willing to spend a little extra effort to write very reliable code, but it would be even better if there were good theorum provers out there to verify that contracts will always hold and warn if they don't. The would be much more developer friendly than the predicate calculus normally associated with formal methods.
If that's what you're looking for then I would suggest that you take some time to check out JML and ESC/Java2 which provides almost exactly that functionality for Java. It's not as clean as Eiffel as the contracts have be be kludged into Java as add-on annotation in comments, but all the functionality you'd want in a good expressive DbC system is there in JML, and ESC/Java2 provides a static checker/theorem prover that can attempt to verify contracts and provide warn you when they might fail. It also provides a number of other strong static checks based on JML annotations, allowing you to have high degree of confidence in well annotated code that passes ESC/Java2. Honestly, download JML, JMLEclipse and ESC/Java2 and try them out - you'll be amazed the number of subtle errors that can be quickly and efficiently caught!
His belief that a method should never return a value and have a side effect is particularly bad. Writing a stack with get_top() and remove_top() instead of pop() is a little weird.
It seems odd, but it does have nice aspects, particularly if you're used to a more functional perspective: it goes a long way toward isolating side effects and allowing better reasoning about the scope of effects that a given block of code may have. It certainly makes sense to me.
Jedidiah.
It's also worth noting that the GNU Eiffel com piler SmartEiffel provides a tool that can compiler Eiffel code to Java byte-code, so you can run Eiffel programs on a JVM too.
Jedidiah.
You have one polar opposite like Ruby, where you are free to do things using a variety of approaches. Then in the middle you have something like Python, where you are encouraged to do things using a certain Pythonic approach. Finally you have Eiffel where it's a certain way or else.
Which is bad if you just want to bash out code, but great if you want serious long term maintainability. Let's face it the ultimate "There's More Than One Way To Do It" language (hell, it's their motto) is Perl, and we all know how wonderfully mantainable that is...
It all comes down to what is more important for the project at hand: flexibility, or maintainability. If flexibility is what is most important, Eiffel is probably not the best choice for that project. If you want maintainability though - that's when Eiffel, with it's very clear "One Way To Do It" syntax, clean OO design, and built in Contract support really start to shine.
Use the right tool and all that.
Jedidiah.
Back in the mid 80's, when the OO paradigm was first starting to gain traction (but it wasn't obvious that C++ would become the first mainstream object-oriented language) there were debates about whether the big OO language of the future would be C++, Smalltalk, or Eiffel.
And the more time has gone by, the more it looks like either of Eiffel of Smalltalk would have been far better choices. When it comes to clean OO design both Eiffel and Smalltalk are way ahead of C++. All C++ really had going for it in comparison was traction with C developers - that provided it with enough critical mass to win the mindshare market. If you don't know Eiffel then spend an evening reading about it some time. It's easy to learn, has very clear readable syntax, and a very well engineered OO design (far cleaner than anything C++ offers).
Jedidiah.
Programming by contract is essentially just writing twice as many unit tests, wrapped all around the code that is supposed to be doing the work.
Programming by contract is writing your unit testing harness as assertions while you write the code, and having those assertions respect inheritance elegantly, saving you considerable work if you actually have any sort of class heirarchy built up in your code. Programming by contract is about stating clearly how you intend your code to work so that it is much easier to determine whether the code you wrote actually does what is intended or not. Programming by contract is about providing clear and explicit documentation of the interfaces making code reuse and code maintainability far easier.
Programming by contract is not the right choice for every programming project. Sometimes you want flexibility. Sometimes rapid adaptability is more valuable than correctness or maintability. Sometimes, however, it is not. I don't draw up careful plans to build a treehouse, I hold the wood where I want it to go and cut it to fit: being able to adapt to the exact organic shape of the tree is more important than the strict integrity and finish of the treehouse. Likewise I don't build home by nailing 2x4's together and cutting the next chunk to fit: Having a truly solid structure, with all the walls and floors are properly aligned is more important than the speed with which I can get started building something. Different projects have different needs, and there are plenty of projects for which Design by Contract is a fantastic way to go. Just because you, personally, don't happen to work on those projects, doesn't invalidate its usefulness for others who do.
Jedidiah.
What are the differences between Eiffel and other free object oriented programming languages? What does Eiffel have that Ruby, Python, and Java do not?
Compared to Ruby, Python and Java the biggest thing Eiffel has going for it is raw speed. Consider the benchmarks and you'll see Eiffel is much much faster than Java, with considerably less memory use. You get that sort of performance from a langauge with an exceptionally clean, well designed and engineered OO system, and great support for Design by Contract, and a very clear readable syntax: learning Eiffel is very easy.
If you're doing very dynamic work that really calls for the flexibility of Python or Ruby, then Eiffel probably isn't for you. If you want something to build robust complex large scale systems then Eiffel is actually better than Java for producing robust, well documented, reusable, maintainable code - and its faster to boot. Java, of course, has its own advantages in terms of "run anywhere" and its huge standard library, but Eiffel is well worth acquainting yourself with.
Jedidiah.
I haven't heard of this language, and don't want to do too much research (go go procrastination!). Can anyone tell me some of the basic info about this, and what makes it different? Why would I want to use this language over something already available, for example.
Eiffel has been around for a long time, and is a mature language. What does it offer? A very clean and well designed Object Oriented language with a very clear and readable syntax and great support for Design by Contract. The principle behind Design by Contract is simple enough: objects, and methods provide contracts - providing you meet their stated requirements, the guarantee things in return. Statically typed languages offer some level of this already: you have to provide paramters of the right datatype, and it guarantees the datatype of the return type. Design by Contract essentially just extends this principle to allow for much more expressive contracts than just type signatures, and things like object invariants (properties of an object that are guaranteed not to change). The result is a much clearer statement of intention as to how code should work, and a powerful test harness that massively speeds up the test/debug cycle. In theory you can achieve this by liberally sprinkling assertions through your code. The advantage of having a language with explicit support for Design by Contract is that things like inheritance of contracts and invariants are all handled automatically and elegantly etc.
As well as this release of EiffelStudio as open source, there's SmartEiffel which is an open source Eiffel compiler (which supports a number of extra features beyond what is given in the recent ECMA spec).
Jedidiah.
Hardly. Giving them a computer solves none of their needs.
It really depends on whether you're just dumping a Dell laptop in their lap, or giving them something designed and targetted to be as useful as possible. That is it depends on hardware designed specifically to fit their needs, and what actually gets loaded onto it in the way of software.
a basic education would be needed before you give them a little white box
They would have to have learned to read at least, yes - our technology isn't quite advanced enough to teach children to read yet. Once they can read however the computer could quite conceivably come loaded with a lot of basic educational material such as basic mathematics through to algebra, plenty of reading material (potentially localised to be in their native language), and whatever else people see fit to include. It would not be that hard to provide enough material and software to make the laptop a complete resource for basic education to anyone motivated enough to sit and use it - and there are people who want the opportunity to learn desperately: don't think they wouldn't take advantage.
hell maybe you might even want to consider reliable power and communication networks before giving them such a wonderful tool for communication.
Or you could recognise that laying out massive power and communication infrastructure is going to be not just expensive, but extremely time consuming. With that in mind you cna design your laptop to have low power modes and long battery life to deal with intermittent power, as well as a hand crank to deal with a complete lack of power. You can also design your laptops to automatically create a peer to peer mesh network amongst each other for communication, spontaneously creating a new network wherever you put the laptops rather than relying on the slow arrival network services.
When you teach a man to fish you don't hand him a yacht, you give him a small fishing pole.
And when you want to provide someone who is self motivated with a basic education you give them a book. Or maybe you could give them a complete library of interactive books, access to a communication network, and a device that can expand to fit their needs all in one nice little durable package that they can take anywhere. Thinking that a child with a thirst for knowledge can't make use of a computer loaded with all manner of suitable educational material and interactive software is to grossly underestimate that child. These laptops have the potential to be amazing. Sure, there's still plenty of room for bureaucratic fuckups, or toher failures that ensure what actually gets delivered is far from the potential of what it could have been, but Negroponte and all seem quite determined to make it as good as possible.
This isn't about making a computer cheap enough that you can hand it to a child. This is about designing and building an educational tool that you can hand out and give people access to the sort of education so many of us simply take for granted.
Jedidiah.
Why do these countries need a widespread distribution of $100 computers?
It's aiming to be more than just a laptop, it is being designed for the express purpose of being an ideal educational tool for children in third world countries. Haven't you ever read "The Diamond Age" by Neal Stephenson? Think of it as our primitive version of "The Young Lady's Illustrated Primer" based on the technology we have available at our disposal currently. That sounds like a worthy goal to me.
Jedidiah.
f it were all about cheap computers for poor nations, just publish the specs and be done with it. Or just collect and ship used throwaway computers overseas.
The point, as Negorponte said, is that this is an educational project, not a project about cheap computers. If the aim was just to throw a random lump of computer hardware in front of a kid in the thrid world then indeed used computers would be fine. The project is trying to do more than that however, and that means more effort needs to be spent on the design. The laptop needs to be incredibly robust and durable, otherwise they'll just get broken immediately. It needs to have low power modes, and the ability to be hand-powered because the reality is that electricity is at best intermittent in many parts of the world where they hope to distribute these. It needs to have its own system for automatically generating its own network on the fly with all the other laptops because many parts of the world don't happen to have free WiFi access. There are a hundred other such constraints and requirements, all of which require special engineering. The point is not to give kids cheap computers, the point is to give them cheap devices that are designed from the get go for the express purpose of being as useful as possible in educating children in third world countries. That means you need more than some second-hand Dell.
Jedidiah.
Greenland used to be green 1400 years ago, I guess it was either cow or ocean flatulence or we had an enormous population of UFO drivers spewing CO2 that left a while ago. Or climactic cycle.
Greenland was not green 1400 years ago. At best we can say that it was settled by Norse around 980 CE. The Norse had 2 settlements, both of which have now been found, and both of which were in relatively sheltered fjords that today are quite green and have lush pasture. Of course the Norse had a hard life their. The growing season was short, and even the areas in which they settled that had pasture produced small amounts. Greenland cattle were the smallest cattle known, standing only 4 foot high, largely from malnutrition. There is good evidence that during the winters when the cattle were kept in barns they had to be force-fed seaweed due to the lack of hay produced over the summer. The Norse also had to eat a lot of seal, definitely not a preferred food for them, due to the lack of food available from their traditional sources (crops, dairy products, and sheep, goats and cows).
Today there are sheep farms in the same areas of Greenland that are coping at least as well as the Norse ever did. The best we can say is that Greenland was perhaps around as warm as it is now in 890 CE. And even that says little about global variation of temperature: according to temperature reconstructions using tree rings, ice cores, glaciers, coral, etc. at times when northern hemisphere areas like Greenland were warmer the southern pacific was colder, meaning despite fluctuations in local temperature over time, the global average changed a lot less. Now, however, it is the global average that is moving significantly.
Jedidiah.
The better way to deal with it would be determine the sustainable amount of carbon dioxide we can emit, chop it in half to be really sure, and produce tradable emission rights. If you don't have the right to the emissions, you can't emit it. The market will set the correct price for the emission rights.
The big problem with my plan is enforcement, you'd probably have to require the producers of the fuel to have the emission rights rather than the emitter.
I would think ideally you would simply fix a price on carbon emissions, with the cost for emissions going into a global climate change mititgation fund (money to be used to efforts to mittigate the effects). Once the right is bought it an be traded as normal. Perhaps a country will simply buy the rights they need by paying into the fund, or perhaps they'll tax their individual emitters over it, or perhaps producers (like oil producers) will buy rights and seel them packaged with their product ("oil from us is free of emissions charges - they are already paid"). The problems, as you note, are of enforcement, and secondly (and this is the big one) administering what is going to be a truly vast slush fund and trying to see that it gets used well (and for its intended purpose and not funnelled off into unrelated projects).
Jedidiah.
That crack-whore welfare mama with 18 children is more fit evolutionary wise than the lonly artist who creats beautifull paintings but kills himself due to depression before breeding.
More genetically fit yes, but the artist is more memtically fit: a lot more people will copy the artists ideas than will copy the crack-whore. Ultimately it is as much our thoughts and ideas that define us as it is our genes.
Jedidiah.
The NSA produced a kernel patch and a set of userland tools called SELinux which provided a much richer and more fine grained security model for Linux, but no actual distribution. In practice this was essentially done as a "proof of concept" by the NSA who were frustrated by the lack of serious security architecture in modern operating systems - they decided the easiest way to get the ball rolling was to take something freely available and modifiable, like Linux, add the better security architecture and hand it back to show how things could be done. Since then that work has been converted into the Linux Security Module which provides support for the general architecture suggested by the NSA in a more modular fashion, and SELinux was adapted to work within such a system.
What does SELinux actually buy you? To quote the NSA FAQ:
Jedidiah.
Paper elections have been forged before. Why should we believe that a forgeable system makes an insecure system secure?
I think it's a question of redundant systems which can be independently verified. What would I like to see in an electronic voting system? I would like machines with a published hardware design, open source code according to full published formal requirements with a formal specification, published correctness proofs, and verification of the code against the specification, backed up by a redundant system of paper reciepts (turned in at the voting centre).
Sure, that sounds like a lot of trouble, but if ever there was a situation where all the open specifications, formal theorem proving and code verification were worth the cost and effort surely voting would be it. It provides a number of independent ways to verfiy that things are behaving correctly.
Jedidiah.
And no, it's nothing like the switch to intel... processor flamewars were always foolishness: who really cares what processor architecture is underneath?...It's all about the user experience, and OSX is the experience Apple wants to deliver.
To be fair any of the detailed versions of the claims of Apple moving to Windows describe Apple using the Windows kernel and simply layering the MacOS GUI on top of that. Under that sort of claim the user experience wouldn't really change and it would be more like switching procesors because "who really cares what kernel is underneath?"
It's still a stupid claim and ridiculously unlikely to happen of course - the benefits (compatability and being able to run all Windows applications) don't stack up at all when compared to the costs (managing to port the MacOS GUI over and dealing with issues of integrating native Windows programs into that environment).
Jedidiah.
The Tarkovsky film version was fantastic. Sure it focussed on different aspects than the book, but in many ways it picked some of the more interesting points that were only peripherally explored in the book. Besides, film is a different medium, so the detailed wordy technical discussions must necessarily become limited. Instead we are treated to visual subtlety and mystery and the absolutely glorious cinematography that is par for the course with Tarkovsky. I rate Tarkovsky's two ventures into science fiction, Solaris and Stalker, as two of the greatest science fiction films ever made - science fiction films that are honestly interested about exploring ideas and giving the audience the space to fully appreciate the depth and subtelty of those ideas. They are films where you are fully expected to spend your time thinkin carefully about everything that is going on.
The Soderbergh film was comparatively truncated and necessarily lost a lot of the material. It was also, in practice, working more from tarkovsky's vision than from Lem's. Still, it managed to create much of the atmosphere and explore many of the ideas of the Tarkovsky film in the reduced time frame. Certainly a great film - though I agree, beginning to be quite divergent from the book.
Jedidiah.
Iain Banks for a remarkably positive view of the future with the culture novels, and a remarkably bleak view of the future with his non-culture novels.
Jedidiah.
If the article is true, and prime numbers can be gleaned from quantum stuff, and quantum computers are just around the corner
Well all of that is only tenuously related, but okay...
will that obsolete all our public key encryption tools?
Quantum computers will, yes. Not because information about the distribution of prime numbers is intertwined within quantum energy levels, but because there exist polynomial time algorithms for factoring and discrete logarithms given a quantum computer. Since all our current public key encryption schemes are based on the difficulty of one of those two problems quantum computers will render current public key schemes rather ineffective.
How does this affect quantum encryption?
It doesn't. Quantum cryptography isn't really encryption in the same sense, and doesn't have anything to do with quantum computers. The general principle is that using suitably encoded data the quantum theory effects of observation changing the object can be used to ensure that you can always know if someone has intercepted/observed your encoded message during transmission.
Will we have to wait for our household Mr. Fusion reactors to power these systems to maintain encryption?
Probably not.
Will all this happen within the next 5 years?
No. Currently the most powerful quantum computers in the world can factor numbers as large as 15. While progress is being made it is very slow and it is ridiculously improbable that any quantum computer capable of factoring numbers commonly used in encryption existing within the next 5 years, let alone anything that might actually have any sort of mainstream availability.
Jedidiah.
if the eagles could snatch the heroes off the top of Mt. Doom after all this noise, why couldn't they have simply sent the eagles to drop in the ring?
The long answer (in the sense that it requires all the extra backstory of the creation of Middle Earth, its Gods etc) is that the eagles are servants of Manwe and do his bidding, and essentially the Valar (Gods of Middle Earth, of which Manwe is one) have a policy of non-involvement (the bulk of the Silmarillion is about the woes of the elves who leave the Valar and go back to Middle Earth and have to struggle alone - it is only resolved when a half-elf manages to navigate the seas back to the Valar and plead the elves case). The eagles are not about to step in and help just because the elves, humans, or dwarves want them to. The Valar are not completely uninvolved mind - they sent Gandalf to come and guide things where necessary. The point, however, is that he is just that: his job is to spur the people of Middle Earth to stand up and resolve the problem themselves, providing occasional help along the way when absolutely necessary.
The short answer is that the eagles serve the Gods, and the Gods, from their longer term perspective, view the whole thing as a good character building exercise: they'll provide a little help when absolutely needed provided the people of Middle Earth actually stand up and do most of the work themselves.
Jedidiah.
I think the film trilogy actually doomed the musical to some extent. Adapting the books is a remarkably difficult task, and as you note, the standard result is a mess. While there are many here who will decry the movies as debauchery of the books the reality is that, all things considered, they were remarkably well done, highly entertaining films. Against the background of such a successful adaptation anything short of a miracle of a musical was always going to look poor - the reality is that the films simply set the bar of expectation far too high and there was no way that a musical could live up to it. I suggest that had the films never been made, the musical, while not getting rave reviews, would have been hailed as a remarkable achievement and generally gotten far more positive reviews than it has.
Jedidiah.