Right now, something worth getting good at is understanding how to write highly parallel programs that are reliable. Write something that has lots of intercommunicating threads and be confident the locking is correct. There aren't that many people who consistently get that right.
Then learn CSP or CCS or a similar process calculus that will let you easily reason about vast numbers of processes and be sure you don't have deadlock or race conditions. You an convert that to code easily enough in a lot of cases: Java has JCSP and I expect similar things probably exist for other languages. Alternately languages like Erlang or Oz or Eiffel with SCOOP support a programming style which is relatively easy to convert back and forth to CSP. Writing massively concurrent code isn't actually that hard if you're actually willing to do the groundwork to learn how to really do it well.
What happened to the old fashioned way of sending sales reps with blond bombshell "assistants" to get these 20 bozos and ply them with wine and fine food and golf outings and "business" trips to Cayman islands?
I think, as someone else pointe out, that the issue is that, with so many companies competing for the attention of these execs and all offering blonde bombshells and trips to the Caymans, managing to get picked to be one of the companies supplying such things and hence getting contact with the execs, is rather hard. To get to that stage you first have to compete for their attention at all - and that's most likely what this campaign is about.
Maybe we need new window managers to take advantage of the larger screens. I think the fact that they used Macintosh machines definitely changes the results, because the maximize button doesn't really maximize. WHich makes a lot of sense if you have a 23 inch apple cinema display, but doesn't make much sense if you use a 17 4:3 resolution monitor.
Oddly window managers for X used to have these sorts of features - FVWM and Enlightenment, for instance, featured "smart maximising" which expanded the window to fill the largest area without overlapping other windows that the expanding window wasn't already overlapping. Similarly I used to have, in my old FVWM setup, separate buttons to maximise vertically or horizontally, allowing me to just stretch a window to maximum height without altering it's width - a very useful feature. In the effort to strip down and simplify window managers these features got removed. In some sense I can understand this: separate buttons for different kinds of maximising was confusing for anyone who sat down at my FVWM setup, and ultimately while "smart maximising" tended to mostly do the right thing, it was also a little baffling if you weren't well acquainted with how it actually worked. Hopefully, however, as demand for better maximising rises with larger screens some of these features, perhaps polished a little, can make their way back in to common window managers.
Then, when the next blockbuster movie sell a grand total of four DVDs, maybe the movie and television studios will finally realize how much money this is costing them.
More likely they'll blame piracy.
And they will probably be correct to some extent, in that the pirated versions of the DVD that come without any elaborate restrictions will be "stealing" all their sales. Of course were there no such pirate version they wouldn't sell any more DVDs, but that wouldn't stop them accounting it as a "loss".
Remoting software: Putty is the best CLI one I've ever seen, TightVNC is good for most of my stuff, but I prefer to use RemoteDesktop when appropriate (when I can lock the screen.. yes I know rdesktop is great, not a server tho)
Am I missing something here, because X does remoting out of the box very effectively. If you want separate sessions try XDMCP and start on a new display (as in:1 instead of:0 - you can have as many Xservers as you like running and use Ctrl-Alt-F7, Ctrl-Alt-F8, etc to jump through them). If you want to access the same client application from different places try xmove to move a client application between XServers (that is, make the application display on whatever machine you want).
It could be worse. One of the major channels in New Zealand "accidentally" had a caption that listed President Bush as a "professional facsist". I believe te official comment from the TV station essentially amounted to "Oops".
Sadly, usually the users aren't really sure what they want. Or if they are, they have great difficulty in describing it. And their standards of usability are usually "It should be easy to get it to do what I want."
You see the problem?
Yeah, the problem is that we need to work harder on drawing out the user on specifics as to what they want. I'm not claiming that's easy - it is, as you say very hard - but it is at the root of many problems in software development. Usually the issue comes down to either poor communication between marketing/sales who talk to customer, and developers, or the fact that developers have plenty of other things to get on with and can't spend the required time patiently drawing useful details out of the user. Perhaps that just means we need to consider a better intermediary - a requirements gatherer and specification writer who can talk to both customers and developers, and can spend the time to get the details from the customer and write that down as a clear, precise, and explicit specification that is easily understood by developers.
I think software is so complicated that testing every single scenario is way too time consuming, thus unreliability is inevitable. Also, software developer often get requirements and specifications that aren't complete, but are expected to continue on with development anyway.
It is worth noting that the latter leads to the problem of the former. The better the requirements and specification, the easier it is to do more complete testing via automated randomised testing, and extended static checking (which can potentially cover all test cases using theorem provers). Such things need fairly precise specification to work, so that means demanding better requirements and specifications.
Of course then there are those bugs which comes from the oversight of the developers themselves. Hey, no one's perfect.
And those are the easiest bugs to quash - get better specification and you can do far more complete testing and weed out the little oversights. No, it won't make software perfect, but it will reduce at least one source of problems, and its one of the few sources that you are likely to have any real control over.
Any ass monkey can right a book of criticisms... I would like to see his attempt at a software development methodology that is better.
It is highly unlikely that there will be a particular methodology that magically makes things better, but certainly there are things you can do to make things better. Two major hurdles in software quality are "building the right product" and "building the product right". That is, is what you are planning to build what the users want, and is what you're actually building the same as what you're planning. There's no magic methodlogy, but spending some time thinking how to best answer those questions for your particular piece of software can go a long way toward lifting the quality. The first question, ultimately, is the hardest - working out what you need to build involves wheedling the details out of the customer. You can do things like acceptance testing, or try an agile rapid feedback approach, but that isn't always applicable, and it isn't necessarily going to get you the right answers.
The other side of the issue is a little easier, presuming you're willing to expend a little effort. At the most basic level there is testing - whether that is direct testing from a testing department, unit testing, or automated random testing (like quickcheck or AutoTest). Alternatively you can step up to extended static checking tools like ESC/Java2 or Spec# which use automated theorem provers to try and find potential errors, effectively testing all possible inputs - they can't always find errors, but they can find a great many that testing won't. In the end though all of these, even the most basic testing, require you to be able to specify what it is you are trying to build (see the first paragraph). The more preceisely you can specify that, the more powerful the testing you can do to verify that you're building what you intend. That means the quality of verification is up to the quality of the validation - how well you know whether you are building what you want, depends on how well you know what you want to build.
Given the review it seems that the book views "lack of features" as a bug, so really it is even worse than you suggest - you can produce a quality piece of software by dropping a few features and you will still be in the firing line of the book author.
Re:There is truth in this book
on
Why Software Sucks
·
· Score: 2, Insightful
No matter how neatly programmed or how much time people spend writing a program, truth is software is highly unreliable.
That is, of course, no reason not to try and make it more reliable - we'll never be perfect, but that doesn't mean we can't try to be better.
There will always be something that will not work as expected no matter what software. Better acknowledge the fact. There is a difference between having a taste for programming and trying to make something work for everyone as they would want to.
Sure, you will never have something work for everyone exactly as they would want it to - if you're going to count missing features as failures of the software then inevitably you're going to find everything inadequate. What software developers could, very reasonably, be aiming toward is, if not guaranteeing that everything will work exactly as desired, at least providing some certification as to which bits they are pretty damn sure will always work as expected (and under what extreme conditions, such as hardware failure or OS bugs, they might condone failure). A word processor might not have all the features I could imagine wanting, but that doesn't mean having a guarantee that, barring hardware failure, it won't ever corrupt a file I'm working on wouldn't be nice.
A private sector company can't be expected to invest in research that pays off in ten years; there are too many uncertainties in business to ask investors to shoulder that.
I'm really not sure that's true. Certainly in the current climate oif short term investment outlook and focus on short term growth it is true, but I really doubt it is true in general. Its all very well for a company to have good growth prospects for the next quarter, but as a long term investor I would much rather see some good prospects for continued profitability 10 years from now. If that takes the form of various promising, but long term, research projects then so be it - it's not necessarily a bad thing.
The problem with any verification tool is that it can't know what you expect the program to do unless you tell it. Why should this be any more correct than the program itself? In other words, if you can write a description of what the program should do that is more accurate than the program, then that description should replace the source code.
It is often easier to describe what a program has to do than it is to describe exactly how to do it. I can describe what a square root finding algorithm has to do: given x it has to find y such that y*y =x; without coming close to writing something that actaully finds the square root. All the prover then has to do is ensure that the code instructions really do produce a result that satisfies the stated constraint - which is potentially entirely possible. Writing contracts for code can be as easy (or easier) than writing unit tests for code. If you write a contract instead of a unit test then that potentially gives the prover all it needs to verify that the code will work for all possible test cases instead of your predefined unit test cases. If the prover can't manage that then just feed in some test data and if the contract fails you've found an error (that is, at worst you've got a unit test already). Working this way can be remarkably efficient at weeding out errors - you verify code when it works, and essentially do unit testing for the code that can't be verified. Perhaps if you actually tried it you'd see.
Sure, I agree. Then again the people who are talking about human extinction (extinction of some species due to global warming, given how fragile some species and environments are, is inevitable) or civilization collapse are just being silly. However resettling 2 billion people and making massive changes to our current agricultural system to adapt to shifted climate bands is a pretty damn huge cost. While civilization might collapse, avoiding the massive costs of resettlement and forced infrastructure rebuilding via significant costs and voluntary infrastructure adaptation might be worth considering.
I've discussed the "Greenland was once green" issue here, the short answer being that Greenland is still green in the areas the Norse settled, and there is plenty of archaelogical evidence that the Norse settlements were marginal due to a cold climate. You raise another claim however, which is worth addressing:
Europe was so warm England's wine production was felt to be an economic threat in France. We know from written human history that it was so.
I don't actually believe there is any evidence of England's wine production threatening France. English wine has a long history, with the historical peak of English wine production occuring with the arrival of the wine loving Normans during the medieval warm period. The Domesday book, a census taken at that time, recorded 42 vineyards in England, all restricted to southern England, and mostly coastal southern England. It can hardly have been a threat to French wine production given that vast amounts of imported wine were available in England during that time. Wine production in England declined after that, possibly due to some climatic cooling, and possibly also due to changing cultural factors (such as an increasing taste for beer and ale), and was practically non-existent through to about the 19th century. Since then there have been various flirtations with wine growing in England, and a flowering since about 1950. There are currently far more vineyards in England than at any time in history, currently over 400 - about 10 times the number of medieval England - and extending further north than at any previous time. From this we can, at best, conclude that the medieval warm period was probably warmer than the 13th to 20th century, but then we knew that, and historical temperature reconstructions clearly show that anyway. If you're going to consider volume of production and location of vineyards as a good proxy data source for climate, however, then you would have to conclude, given the vastly increased volume and more northerly extent of modern wine production in England, that it is warmer today than it was in the medieval warm period - again, as historical temperature reconstructions show. And let's be honest, wine growing is hardly a clear sign of a warm climate in the area the wine is grown. Canada has a large wine industry, and there are even vineyards in Alaska!
I suppose the same could be said of human civilization. We haven't evolved to it. The thing that puzzles me here though is what condition haven't we evolved to before? Slightly higher CO2 concentration? Slightly warmer temperatures? More or less rain? These are all well within the range of what the human race has evolved with.
It's not a matter of whether or not there is change, it is a matter of how fast change occurs. Besides, even if we do successfully adapt, that doesn't mean it won't be without cost. At the last major climate shift humans lived in hunter-gatherer groups that were sparsely spread across Africa and Eurasia, so as the climate changed people could simply move to new areas. We now live far more densely, in largely sedentary groups, and are dependent on farming and agriculture to provide our food. If the areas suitable for food production move we are no longer in a position to just move with it as easily as a small hunter-gatherer group - we will need to shift large populations and significant agricultural infrastructure, which is no small task. These are far from insurmountable obstacles, but they are not exactly minor inconveniences either.
Now consider the unescapable fact that the Earth HAS been hotter in the past, despite the FUD coming from the enviro political hacks. Greenland wasn't given that name as some sort of horrible joke. It used to be GREEN.
Greenland was named by the Norse. Presumably you're claiming their settlement demonstrates that the earth was warmer then. It is true that the Norse colonised Greenland around 1000 CE. Surely Greenland must have been much warmer than it is today with its 3km thick ice pack right? The reality is that there were only 2 Norse settlements in Greenland, located in fjords on Greenland's west coast. The areas of both those settlements are quite green and hospitable today, and there are several farms there now, so Greenland need not have been any warmer than today to have provided the Norse with sustainable settlements. Further the archaeological evidence from the sites implies the Norse hardly had an easy life: Greenland cows were the smallest ever known, largely due to malnutrition, and it seems the cows and sheep may have had to be force fed seaweed over the winter to keep them alive. The Norse also tended to rely on trips to the Eastern Canadian coast, most likely the Labrador area, for many things, most particularly wood. In practice the apparently marginal Norse Greenland colonies say little or nothing about the temperatures a millennium ago. Greenland was simply a marketing name used by Erik the Red to get people to come an colonise a place that wasn't terribly appealing otherwise.
When the dinosaurs roamed the earth it is thought to have been much warmer than today.
Yes, and oddly enough the dinosaurs, and all the other flora and fauna of the time, were well adapted to those climates. Humans, and the flora and fauna of today, however, are not well adapted to Cretaceous era climates. Homo Sapiens have only been around in their modern for for around a million years, so it is the climate of the last million years that we are adapted to and need to be concerned about. You can raise the question of how life managed to change from being suited to Creataceous era climates to modern climates, but the answer to that is slowly. It isn't the change of climate that is really of most concern, it is how fast it is changing - and relatively speaking it is changing pretty quickly. That means life, and humanity needs to adapt quickly. Life may struggle, but will undoubtedly succeed; it might just mean some changes in the current makeup of the ecosystem. Humans can probably adapt too; it might just be very expensive and and involve quite a bit of hardship. That's still reason to be concerned.
Note also the evidence of melting polar caps on Mars, something unlikely to be caused by humans.
Mars, and the rest of the solar system, are different planets with their own quite different climates with different factors affecting their climates. More importantly, when analysed by experts, the warming of other bodies in the solar system can be well accounted for by the natures of their orbits and variation in solar intensity. The warming on Earth, which is more severe than elsewhere, however, cannot adequately be accounted for via solar variation and other natural factors alone. Ultimately warming elsewhere says little or nothing about the nature of the warming on Earth.
Several studies indicate solar output is currently increasing.
Solar output was increasing, but it stopped a while ago and is starting to decrease. No one is claiming solar variation isn't a factor (well, okay, some idiots are, but we can safely ignore them). In fact the IPCC claims that up to 30% of the observed warming can be attributed to solar variation factors. The problem is that since about 1950 solar intensity has started decreasing, while the
It's a huge pain to distribute binaries for every different distro, so unless your app becomes popular enough for other people to do that work for you, (or the distros do it themselves) then a significant amount of development time is spent just on packaging and deployment.
If you are writing software that isn't going to be included and packaged for you by a distribution, then you can just use Autopackage to create a single distro-agnostic binary with its own built in installer. Autopackage even provides libraries/tools to allow functionality to degrade gracefully so that, for instance, your application can use new GTK+ features if the newer library is available, but fall back to older features and still work properly if an older library is all that's available. The tools are there, all you have to do is actually use them.
The first thing to understand is that eiffel's design-by-contract features sound a lot nicer than they are. They could be very good, but most (all?) current compilers pretty much just translate them to a bunch of run-time precondition and postcondition assertions, which I find pretty yawn-worthy. Of course, I'm *VERY* far from an Eiffel expert, so feel free to politely correct me if the above is bunk.
What you want, I think, would be some sort of extended static checking using the contracts and an automated theorem prover to warn you of, for instance, bizarre corner cases you hadn't thought of that might allow contracts to be violated. Such things do exist, though strangely for Eiffel they're a little behind - for Eiffel there's a system for doin this still in development. For Java there's ESC/Java2, which requires you to annotate your java with JML to get the contracts, but once you've done that does a truly remarkable job of finding interesting errors you would more than likely miss (as well as obvious ones too). Better still running ESC/Java2 over a codebase takes about as long as the compile step, so it's easy to do regularly.
It's a nice idea, but then you run into the problem of strengthening or weakening contracts in sub-objects, and if you have lots of classes, and hence lots of different base classes, then turning runtime checking of contracts on and off is not so easy. That's not to say it isn't a good idea and doesn't have value, especially in a language that just doesn't have any DbC facility, but it isn't a replacement fr good DbC.
As someone else pointed out, Eiffel, or anything that takes design by contract seriously, adds more than just keywords. Good design by contract should ahve contracts behave properly with respect to inheritance (preconditions can only be weakened, and postconditions and invariants can only be strengthened) with contracts being inherited properly even in overidden methods. Eiffel also allows much more fine grained control of runtime checking of contracts than asserts and ifdefs can give you unless you spend a lot of time and have complex layered ifdefs. Good DbC also offers more than just require and ensures, it also has keywords like "old" (to refer to the value of a variable upon entry to the method), and logical connectives like "implies" and "if and only if" to allow for greater expressivity of requirements. Good DbC also involve s a certain amount of smartness in when conditions are checked - there's actually come subtlety. For instance, should you check an invariant after a method completes even though that method was called by another method of the same object which is still continuing (the answer, of course, is no)? Good DbC also integrates efficiently and easily into autogenerated documentation so contracts are fully documented from the outset.
Yes, throwing in assertions is good, and can save you a lot of trouble tracking down bugs. That doesn't, however, make it equivalent to a good DbC system like Eiffel, JML, SPARK, or Spec#.
Besides the many very good points you mention there's also the question of documentation - good DbC systems are integrated into the autogenerated documentation elegantly. All that said, you do have more options then Eiffel if you want to use contracts. If you use Java you can use JML which I believe covers all your points, and my point about documentation. If you use Ada you can use SPARK which again, covers your points quite well. Both SPARK and JML also offer (via ESC/Java2 for JML) extended static checking as well as the usual runtime checking of contracts. Finally for C# there's Spec#, but I don't know too much about that one.
Still, Eiffel is actually an extremely elegant language with powerful DbC built into at the core. If DbC is something that's important to you Eiffel probably is your best choice.
There are several options. You can simply use macros as many people do. It's clunky and tends to have issues with inheritance and documentation, but it gets the job done. Alternatively you can try the digital mars c++ compiler which supports design by contract, or if your co-workers are willing to stretch a little bit you can try the D programming language from digital mars which is very similar to C++ but offers native contracts as well as a host of other nice features. Otherwise you can go the proprietary route and get C2 which is a C++ code generator that uses comment annotations to manage contracts and is a little slicker than the macro approach.
Yeah, I have to wonder at the definition of cheating here.
According to TFA cheating was defined as: "copying the work of other students, plagiarizing and bringing prohibited notes into exams", which seems reasonable to me. The only minor quibble one could raise was as to whether allowed collaborative work counted as "copying the work of other students", which I don't think it does - unless you're completely passive in the collaboration.
I would say Maths/Statistics has the most cheaters, pretty much everyone I know who takes it cheats at it.
At the graduate level? Mathematics and statistics at the graduate level tends to be very different from high school and early undergrad math and stats, and also tends to be assessed rather differently. I've had several graduate math courses that were assessed by having the students give lectures - I'm not sure how you can cheat at that easily, especially when the lecturer olr any other student can ask you a question about what your discussing at any time; either you understand the material and can discuss is well, or you don't.
Slashdot Mirror
Then learn CSP or CCS or a similar process calculus that will let you easily reason about vast numbers of processes and be sure you don't have deadlock or race conditions. You an convert that to code easily enough in a lot of cases: Java has JCSP and I expect similar things probably exist for other languages. Alternately languages like Erlang or Oz or Eiffel with SCOOP support a programming style which is relatively easy to convert back and forth to CSP. Writing massively concurrent code isn't actually that hard if you're actually willing to do the groundwork to learn how to really do it well.
I think, as someone else pointe out, that the issue is that, with so many companies competing for the attention of these execs and all offering blonde bombshells and trips to the Caymans, managing to get picked to be one of the companies supplying such things and hence getting contact with the execs, is rather hard. To get to that stage you first have to compete for their attention at all - and that's most likely what this campaign is about.
Oddly window managers for X used to have these sorts of features - FVWM and Enlightenment, for instance, featured "smart maximising" which expanded the window to fill the largest area without overlapping other windows that the expanding window wasn't already overlapping. Similarly I used to have, in my old FVWM setup, separate buttons to maximise vertically or horizontally, allowing me to just stretch a window to maximum height without altering it's width - a very useful feature. In the effort to strip down and simplify window managers these features got removed. In some sense I can understand this: separate buttons for different kinds of maximising was confusing for anyone who sat down at my FVWM setup, and ultimately while "smart maximising" tended to mostly do the right thing, it was also a little baffling if you weren't well acquainted with how it actually worked. Hopefully, however, as demand for better maximising rises with larger screens some of these features, perhaps polished a little, can make their way back in to common window managers.
And they will probably be correct to some extent, in that the pirated versions of the DVD that come without any elaborate restrictions will be "stealing" all their sales. Of course were there no such pirate version they wouldn't sell any more DVDs, but that wouldn't stop them accounting it as a "loss".
Am I missing something here, because X does remoting out of the box very effectively. If you want separate sessions try XDMCP and start on a new display (as in
It could be worse. One of the major channels in New Zealand "accidentally" had a caption that listed President Bush as a "professional facsist". I believe te official comment from the TV station essentially amounted to "Oops".
Yeah, the problem is that we need to work harder on drawing out the user on specifics as to what they want. I'm not claiming that's easy - it is, as you say very hard - but it is at the root of many problems in software development. Usually the issue comes down to either poor communication between marketing/sales who talk to customer, and developers, or the fact that developers have plenty of other things to get on with and can't spend the required time patiently drawing useful details out of the user. Perhaps that just means we need to consider a better intermediary - a requirements gatherer and specification writer who can talk to both customers and developers, and can spend the time to get the details from the customer and write that down as a clear, precise, and explicit specification that is easily understood by developers.
It is worth noting that the latter leads to the problem of the former. The better the requirements and specification, the easier it is to do more complete testing via automated randomised testing, and extended static checking (which can potentially cover all test cases using theorem provers). Such things need fairly precise specification to work, so that means demanding better requirements and specifications.
And those are the easiest bugs to quash - get better specification and you can do far more complete testing and weed out the little oversights. No, it won't make software perfect, but it will reduce at least one source of problems, and its one of the few sources that you are likely to have any real control over.
It is highly unlikely that there will be a particular methodology that magically makes things better, but certainly there are things you can do to make things better. Two major hurdles in software quality are "building the right product" and "building the product right". That is, is what you are planning to build what the users want, and is what you're actually building the same as what you're planning. There's no magic methodlogy, but spending some time thinking how to best answer those questions for your particular piece of software can go a long way toward lifting the quality. The first question, ultimately, is the hardest - working out what you need to build involves wheedling the details out of the customer. You can do things like acceptance testing, or try an agile rapid feedback approach, but that isn't always applicable, and it isn't necessarily going to get you the right answers.
The other side of the issue is a little easier, presuming you're willing to expend a little effort. At the most basic level there is testing - whether that is direct testing from a testing department, unit testing, or automated random testing (like quickcheck or AutoTest). Alternatively you can step up to extended static checking tools like ESC/Java2 or Spec# which use automated theorem provers to try and find potential errors, effectively testing all possible inputs - they can't always find errors, but they can find a great many that testing won't. In the end though all of these, even the most basic testing, require you to be able to specify what it is you are trying to build (see the first paragraph). The more preceisely you can specify that, the more powerful the testing you can do to verify that you're building what you intend. That means the quality of verification is up to the quality of the validation - how well you know whether you are building what you want, depends on how well you know what you want to build.
Given the review it seems that the book views "lack of features" as a bug, so really it is even worse than you suggest - you can produce a quality piece of software by dropping a few features and you will still be in the firing line of the book author.
That is, of course, no reason not to try and make it more reliable - we'll never be perfect, but that doesn't mean we can't try to be better.
Sure, you will never have something work for everyone exactly as they would want it to - if you're going to count missing features as failures of the software then inevitably you're going to find everything inadequate. What software developers could, very reasonably, be aiming toward is, if not guaranteeing that everything will work exactly as desired, at least providing some certification as to which bits they are pretty damn sure will always work as expected (and under what extreme conditions, such as hardware failure or OS bugs, they might condone failure). A word processor might not have all the features I could imagine wanting, but that doesn't mean having a guarantee that, barring hardware failure, it won't ever corrupt a file I'm working on wouldn't be nice.
I'm really not sure that's true. Certainly in the current climate oif short term investment outlook and focus on short term growth it is true, but I really doubt it is true in general. Its all very well for a company to have good growth prospects for the next quarter, but as a long term investor I would much rather see some good prospects for continued profitability 10 years from now. If that takes the form of various promising, but long term, research projects then so be it - it's not necessarily a bad thing.
It is often easier to describe what a program has to do than it is to describe exactly how to do it. I can describe what a square root finding algorithm has to do: given x it has to find y such that y*y =x; without coming close to writing something that actaully finds the square root. All the prover then has to do is ensure that the code instructions really do produce a result that satisfies the stated constraint - which is potentially entirely possible. Writing contracts for code can be as easy (or easier) than writing unit tests for code. If you write a contract instead of a unit test then that potentially gives the prover all it needs to verify that the code will work for all possible test cases instead of your predefined unit test cases. If the prover can't manage that then just feed in some test data and if the contract fails you've found an error (that is, at worst you've got a unit test already). Working this way can be remarkably efficient at weeding out errors - you verify code when it works, and essentially do unit testing for the code that can't be verified. Perhaps if you actually tried it you'd see.
Sure, I agree. Then again the people who are talking about human extinction (extinction of some species due to global warming, given how fragile some species and environments are, is inevitable) or civilization collapse are just being silly. However resettling 2 billion people and making massive changes to our current agricultural system to adapt to shifted climate bands is a pretty damn huge cost. While civilization might collapse, avoiding the massive costs of resettlement and forced infrastructure rebuilding via significant costs and voluntary infrastructure adaptation might be worth considering.
I don't actually believe there is any evidence of England's wine production threatening France. English wine has a long history, with the historical peak of English wine production occuring with the arrival of the wine loving Normans during the medieval warm period. The Domesday book, a census taken at that time, recorded 42 vineyards in England, all restricted to southern England, and mostly coastal southern England. It can hardly have been a threat to French wine production given that vast amounts of imported wine were available in England during that time. Wine production in England declined after that, possibly due to some climatic cooling, and possibly also due to changing cultural factors (such as an increasing taste for beer and ale), and was practically non-existent through to about the 19th century. Since then there have been various flirtations with wine growing in England, and a flowering since about 1950. There are currently far more vineyards in England than at any time in history, currently over 400 - about 10 times the number of medieval England - and extending further north than at any previous time. From this we can, at best, conclude that the medieval warm period was probably warmer than the 13th to 20th century, but then we knew that, and historical temperature reconstructions clearly show that anyway. If you're going to consider volume of production and location of vineyards as a good proxy data source for climate, however, then you would have to conclude, given the vastly increased volume and more northerly extent of modern wine production in England, that it is warmer today than it was in the medieval warm period - again, as historical temperature reconstructions show. And let's be honest, wine growing is hardly a clear sign of a warm climate in the area the wine is grown. Canada has a large wine industry, and there are even vineyards in Alaska!
It's not a matter of whether or not there is change, it is a matter of how fast change occurs. Besides, even if we do successfully adapt, that doesn't mean it won't be without cost. At the last major climate shift humans lived in hunter-gatherer groups that were sparsely spread across Africa and Eurasia, so as the climate changed people could simply move to new areas. We now live far more densely, in largely sedentary groups, and are dependent on farming and agriculture to provide our food. If the areas suitable for food production move we are no longer in a position to just move with it as easily as a small hunter-gatherer group - we will need to shift large populations and significant agricultural infrastructure, which is no small task. These are far from insurmountable obstacles, but they are not exactly minor inconveniences either.
Greenland was named by the Norse. Presumably you're claiming their settlement demonstrates that the earth was warmer then. It is true that the Norse colonised Greenland around 1000 CE. Surely Greenland must have been much warmer than it is today with its 3km thick ice pack right? The reality is that there were only 2 Norse settlements in Greenland, located in fjords on Greenland's west coast. The areas of both those settlements are quite green and hospitable today, and there are several farms there now, so Greenland need not have been any warmer than today to have provided the Norse with sustainable settlements. Further the archaeological evidence from the sites implies the Norse hardly had an easy life: Greenland cows were the smallest ever known, largely due to malnutrition, and it seems the cows and sheep may have had to be force fed seaweed over the winter to keep them alive. The Norse also tended to rely on trips to the Eastern Canadian coast, most likely the Labrador area, for many things, most particularly wood. In practice the apparently marginal Norse Greenland colonies say little or nothing about the temperatures a millennium ago. Greenland was simply a marketing name used by Erik the Red to get people to come an colonise a place that wasn't terribly appealing otherwise.
Yes, and oddly enough the dinosaurs, and all the other flora and fauna of the time, were well adapted to those climates. Humans, and the flora and fauna of today, however, are not well adapted to Cretaceous era climates. Homo Sapiens have only been around in their modern for for around a million years, so it is the climate of the last million years that we are adapted to and need to be concerned about. You can raise the question of how life managed to change from being suited to Creataceous era climates to modern climates, but the answer to that is slowly. It isn't the change of climate that is really of most concern, it is how fast it is changing - and relatively speaking it is changing pretty quickly. That means life, and humanity needs to adapt quickly. Life may struggle, but will undoubtedly succeed; it might just mean some changes in the current makeup of the ecosystem. Humans can probably adapt too; it might just be very expensive and and involve quite a bit of hardship. That's still reason to be concerned.
Mars, and the rest of the solar system, are different planets with their own quite different climates with different factors affecting their climates. More importantly, when analysed by experts, the warming of other bodies in the solar system can be well accounted for by the natures of their orbits and variation in solar intensity. The warming on Earth, which is more severe than elsewhere, however, cannot adequately be accounted for via solar variation and other natural factors alone. Ultimately warming elsewhere says little or nothing about the nature of the warming on Earth.
Solar output was increasing, but it stopped a while ago and is starting to decrease. No one is claiming solar variation isn't a factor (well, okay, some idiots are, but we can safely ignore them). In fact the IPCC claims that up to 30% of the observed warming can be attributed to solar variation factors. The problem is that since about 1950 solar intensity has started decreasing, while the
If you are writing software that isn't going to be included and packaged for you by a distribution, then you can just use Autopackage to create a single distro-agnostic binary with its own built in installer. Autopackage even provides libraries/tools to allow functionality to degrade gracefully so that, for instance, your application can use new GTK+ features if the newer library is available, but fall back to older features and still work properly if an older library is all that's available. The tools are there, all you have to do is actually use them.
What you want, I think, would be some sort of extended static checking using the contracts and an automated theorem prover to warn you of, for instance, bizarre corner cases you hadn't thought of that might allow contracts to be violated. Such things do exist, though strangely for Eiffel they're a little behind - for Eiffel there's a system for doin this still in development. For Java there's ESC/Java2, which requires you to annotate your java with JML to get the contracts, but once you've done that does a truly remarkable job of finding interesting errors you would more than likely miss (as well as obvious ones too). Better still running ESC/Java2 over a codebase takes about as long as the compile step, so it's easy to do regularly.
It's a nice idea, but then you run into the problem of strengthening or weakening contracts in sub-objects, and if you have lots of classes, and hence lots of different base classes, then turning runtime checking of contracts on and off is not so easy. That's not to say it isn't a good idea and doesn't have value, especially in a language that just doesn't have any DbC facility, but it isn't a replacement fr good DbC.
As someone else pointed out, Eiffel, or anything that takes design by contract seriously, adds more than just keywords. Good design by contract should ahve contracts behave properly with respect to inheritance (preconditions can only be weakened, and postconditions and invariants can only be strengthened) with contracts being inherited properly even in overidden methods. Eiffel also allows much more fine grained control of runtime checking of contracts than asserts and ifdefs can give you unless you spend a lot of time and have complex layered ifdefs. Good DbC also offers more than just require and ensures, it also has keywords like "old" (to refer to the value of a variable upon entry to the method), and logical connectives like "implies" and "if and only if" to allow for greater expressivity of requirements. Good DbC also involve s a certain amount of smartness in when conditions are checked - there's actually come subtlety. For instance, should you check an invariant after a method completes even though that method was called by another method of the same object which is still continuing (the answer, of course, is no)? Good DbC also integrates efficiently and easily into autogenerated documentation so contracts are fully documented from the outset.
Yes, throwing in assertions is good, and can save you a lot of trouble tracking down bugs. That doesn't, however, make it equivalent to a good DbC system like Eiffel, JML, SPARK, or Spec#.
Besides the many very good points you mention there's also the question of documentation - good DbC systems are integrated into the autogenerated documentation elegantly. All that said, you do have more options then Eiffel if you want to use contracts. If you use Java you can use JML which I believe covers all your points, and my point about documentation. If you use Ada you can use SPARK which again, covers your points quite well. Both SPARK and JML also offer (via ESC/Java2 for JML) extended static checking as well as the usual runtime checking of contracts. Finally for C# there's Spec#, but I don't know too much about that one.
Still, Eiffel is actually an extremely elegant language with powerful DbC built into at the core. If DbC is something that's important to you Eiffel probably is your best choice.
There are several options. You can simply use macros as many people do. It's clunky and tends to have issues with inheritance and documentation, but it gets the job done. Alternatively you can try the digital mars c++ compiler which supports design by contract, or if your co-workers are willing to stretch a little bit you can try the D programming language from digital mars which is very similar to C++ but offers native contracts as well as a host of other nice features. Otherwise you can go the proprietary route and get C2 which is a C++ code generator that uses comment annotations to manage contracts and is a little slicker than the macro approach.
According to TFA cheating was defined as: "copying the work of other students, plagiarizing and bringing prohibited notes into exams", which seems reasonable to me. The only minor quibble one could raise was as to whether allowed collaborative work counted as "copying the work of other students", which I don't think it does - unless you're completely passive in the collaboration.
At the graduate level? Mathematics and statistics at the graduate level tends to be very different from high school and early undergrad math and stats, and also tends to be assessed rather differently. I've had several graduate math courses that were assessed by having the students give lectures - I'm not sure how you can cheat at that easily, especially when the lecturer olr any other student can ask you a question about what your discussing at any time; either you understand the material and can discuss is well, or you don't.