1. Start with a grid of data 2. Filter out empty rows 3. Group rows together that have identical values for the first column. 4. Make a tree branch from each route, using the value of the first column as the head of the branch, and use recursion to find the child branches from the remaining columns (i.e. every column but the first) of the grid.
Sometimes this (known as "crashme" approach) catches errors. Most of bugs, especially security-related ones are still missed.
Try to calculate all possible combinations of states in a program that occupies 10M of heap and stack (each bit can be one or zero), and take into account all possible relative positions of instruction pointer in its multiple threads.
Oh, don't be ridiculous. Bugs aren't distributed evenly through a program's state space.
This is a stupid analogy. If you wear more than one seatbelt, it will make you LESS safe
Analogies are not meant to be illustrative, not comprehensive.
And most of those automated checks did not contribute anything at all to security fixes because conditions that trigger security bugs usually require knowledge and analysis of the system
Valgrind? Lint?
It does not matter how much is in the set. What matters is how much is outside of it -- and in case of bugs it's for all practical purpose the infinity.
Of course it isn't. The number of possible bugs for any program is always going to be finite, and even simple tests can reduce the number of possible bugs by a significant fraction. If you keep halving a mountain, it doesn't take many iterations until it's dust.
What I have described are general principles. They do not correspond to any particular styles of programming languages, styles or even "doctrines" such as functional programming, object-oriented programming, use of particular models, etc.
In other words, you can't back up your argument with a concrete example.
I think I'm beginning to get wise to this. In the past, I've often spend quite a few posts on various boards debating my point, but I've come to the conclusion that vague concepts that can't be explicitly nailed down and demonstrated are not worth arguing over, because there can never be any closure. You say this, I say that, and we get nowhere.
So, unless you want to start backing up your argument, I think I'm going to leave this thread for the archives and googlebots.
This uses a function from Control.Applicative, but once you know that:
(f . g <*> h) x = f (g x) (h x)
It's not so scary. It takes the first cell from the first column of the group (head . head) to use as the value of the branch node, and then passes all the remaining columns (map tail) back into the listToForest function, and uses this as the subtree.
Not trivial, but pretty clear when you think about it.
Have you tried it in C# with LINQ? It should map almost exactly to LINQ, just with different syntax.
Yes, you're probably right. LINQ is a specialised form of monad comprehension, and I suspect that some of the Haskell programmers that Microsoft employs might have contributed to the initial idea. For a 'popular' language like C#, LINQ is a pretty advanced feature to have. I guess Microsoft was able to get away with it by dressing it up in SQL-like syntax.
That said, I'd be interested in seeing someone actually produce the code. I suspect LINQ would allow for a pretty concise implementation, but there may be gotchas in the Haskell code that LINQ wouldn't be able to deal with.
I'm not going to take the time to look up the appropriate API calls at the moment, but I believe it's somewhere in the range of 2-3 lines of code to accomplish this feat.
If you're not going to take the time to actually produce any code to back up your point, why bother replying?
The biggest problem with talking about the advantages and disadvantages of programming languages is that people tend to make vague claims without producing any evidence for their case. Can JPA produce lazily produce a hierarchical tree of objects from a single database query? I don't know; it's not an answer you're likely to find in an FAQ or a tutorial. And how much work is it to actually set JPA and XStream up? Does it really only take 2-3 lines of code?
Without providing working code, who knows whether your assertion has any merit or not.
The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages.
At University, I studied SML, and came out with a opinion similar to yours concerning functional languages. But when I started to learn Haskell on my own, really learn it, I found that all the concepts in my CompSci courses that seemed so pointlessly complex before, just fell neatly into place.
I'll give you an example of a case where my solution in Haskell to a problem was rather better than any solution I came up with in C#. A while ago I was designing a program to export some hierarchical data held in a database to XML. Because SQL resultsets are 2D grids, I needed a way of converting a 2D grid into a list of fixed-depth tree structures.
In Haskell, the solution is two lines of code, and assuming you know Haskell pretty well, it's fairly clear as well:
Lack of this "absolute perfection" is the reason why most of software is chock-full of security bugs. Security is one area where pretty much anything unexpected done by a program as a response for (usually) invalid input results in a massive hole that will be eventually exploited. Developer that relies on tests will never hit those conditions unless tests are developed by someone much smarter than he is.
Or more methodical. For instance, testing a distributed sorting algorithm by shoving ten billion random numbers through is a good way of checking for any flaws the human eye may have missed. The computer doesn't have to be smarter than you in order to catch something you've missed, just like a computer doesn't have to be smarter than you to beat you at chess. Sheer brute force is the advantage of a computer; it can zip through thousands, even millions of discrete tests per second.
Automated tests aren't a mechanism for replacing human thought, any more than seatbelts replace the need for safe driving. But people make mistakes, and even the most security-conscious applications have bug trackers. Unit tests are a way of reducing human error by taking advantage of the computer's ability to singlemindedly check thousands of conditions every time the developer makes a change. A good type system works in much the same way, checking a more abstract, but more comprehensive set of conditions each time the program compiles.
Fortunately the solution is actually simple -- design software in a rule-based manner (so no actual scenario has ever to be considered, only classes of it), with consistent representation of data (so "deep propagation of invalid conditions" such as your example with "None" will never happen), and clearly defined interfaces (so programmer has a limited scope of code to work on, and clearly defined requirements to what it should accept and produce).
That rather sounds like a description of a functional type system to me, but perhaps I'm misunderstanding. Can you give an example to clarify your explanation?
Those are the kind of improvements that I describe as "If this actually managed to help you, you were not qualified to do this job in the first place". If programmer does not consider full set of possible outcomes of all situations, he can't write a program that properly handles it. If compiler throws some of those outcomes in his face, there will be still plenty of ones he did not take into account
It sounds as if you are suggesting that a programmer is only competant if he or she makes no mistakes; if their programs compile first time, if every scenario is accounted for, if there are no bugs anywhere, ever, in their software.
If absolute perfection is the yardstick you measure by, no wonder you believe most programmers are incompetant.
For programmers that are merely mortal, automated tests and checks are a useful tool. If you're refactoring a large application, tracking every possible result of each alteration by hand is impractical and inefficient. Far better to use unit tests and compile time checks to ensure correctness, as a thousand automated tests are going to be less prone to error than checking a thousand things by hand.
This still does very little to reduce the number of actual bugs
Only if the programmer is a complete incompetent, but you don't need to be a complete incompetent for there to be bugs in your code.
In your example if programmer does not know what to do when he gets None, he will still do something invalid down the line when he applies it to some other operations (like, skipping None lines in the input file when formatting it for printing, or waiting None seconds before dialing the phone number, or allocating None IP addresses for some devices, or measuring the distance to an object None meters tall using a camera image where it takes 20 pixels).
Most of the examples you provide would be caught by the Haskell compiler. If you tried to sleep for 'Maybe Integer' seconds, the compiler would complain. You'd need to explicitly extract the Integer part, accounting for the None possibility.
Similarly, you'd have to explicitly tell Haskell that the distance to an object was 'Maybe Float' metres, rather than just 'Float' metres. It would require a really enterprising idiot to work around the typing errors without once engaging his brain.
That's not to say that there aren't people that stupid, as stupidity is not a resource the Earth is short on. However, not every programmer is an utter moron; in fact, there is a not insignificant proportion of programmers capable of some logical thought, surprising though that may be. If the compiler tells a developer, "You're not accounting for the possibility that the user might not have a display picture", then I hope I'm not being terribly optimistic to assume that at least some programmers would say, "Hey, you're right - I'll fix that", rather than to stare blankly and drool upon the keyboard.
Compile-time checks aren't a complete solution, but to claim that they won't have any effect at all seems silly.
I'll give you an example. The Java compiler cannot guarentee that a program will not raise a NullPointerException during its execution. In contrast, the Glasgow Haskell Compiler can guarentee that no null references will ever exist if the program passes compilation.
And I can "solve" a halting problem by inventing a language that runs all programs in a loop, so they can't halt.
Re-reading my statement I can see I missed out a word that changes the whole meaning, so it's no wonder you seemed less than impressed;)
I meant to type:
The Glasgow Haskell Compiler can guarentee that no null reference exceptions will ever exist if the program passes compilation.
Haskell allows null references, or the equivalent thereof, but the compiler will ensure that you never refer to a null reference when you expect a value.
For instance, the following Haskell program will not compile:
div x y = if y == 0 then None else Just (x / y)
z = (5 `div` 0) * 10
The compiler knows that (5 `div` 0) could be None (the equivalent to null), and None * 10 is a nonsensical statement. You have to explicitly account for both possibilities before it compiles:
z = let r = 5 `div` 0 in
case r
None -> None
Just x -> Just (x * 10)
This is a pretty common pattern, so Haskell provides a shortcut:
z = (5 `div` 0) >>= (\x -> return x * 10)
But whilst shorter, this isn't exactly more readable. So Haskell provides the 'do-notation' syntax sugar to make it look better:
z = do x <- 5 `div` 0
return x * 10
And there we have code guarenteed to be free of null pointer exceptions by the compiler, whilst still allowing null pointers to exist.
And I can "solve" a halting problem by inventing a language that runs all programs in a loop, so they can't halt.
The difference between your approach and Haskell's is that you're reducing errors by limiting the language, whilst Haskell reduces errors by increasing the scope of the type system. The more powerful type system you have, the more you can tell the compiler about your program, and the more errors can be caught at compile time.
You don't need to limit the language to eliminate large categories of bugs. You just need to have a flexible enough type system that the compiler can figure them out on its own.
This is not a property of compiler, it's a property of language. Language is not defined by "compiler checks", it determines what compiler does in the first place.
I didn't say it was a property of the compiler. I said it was a "compile-time check" - a check that happens at compile time.
I have no idea, what do you mean by "tougher compile-time checks" -- if the compiler does not produce an error on invalid source, it's a buggy compiler.
If you have no idea what I'm talking about, why are you arguing the opposite view instead of asking me what I meant?
I'll give you an example. The Java compiler cannot guarentee that a program will not raise a NullPointerException during its execution. In contrast, the Glasgow Haskell Compiler can guarentee that no null references will ever exist if the program passes compilation.
This isn't a bug with the Java compiler. Java's type system was not designed to distinguish between types that can be null, and types that cannot. The Haskell type system is more sophisticated, and thus the compiler can perform more stringent checks.
They use a trial-and-error method that I call "perma-debugging" -- writing code that seems right, compiling it, making random changes until it compiles, running it on some test input, making random changes until the test runs, writing more code and repeating the process. The result of this process is your typical buggy piece of software.
Whilst this is far from an ideal way of writing software, I suspect that using this method with Haskell would produce fewer bugs than with Java.
Unfortunately, Haskell is difficult for even good programmers to understand, so I wouldn't hold out hope that everyone will switch to Haskell and start writing less buggy code. On the other hand, if you use Haskell to write your code, it's much less likely you'll wind up hiring crap programmers:)
Yet, humans have managed in their brief existence to take a good number of other races out, lift the global temperature a few degrees and pretty much change a planet into a huge trash can. So yeah, you're right. I awe at the accomplishments of the human race.
I think this very neatly demonstrates our inherent myopia when it comes to what we've achieved. We focus on the worst aspects of ourselves, completely blind to the miracles we've constructed. I suspect this is a survival trait, a way of ensuring that we continually strive to better ourselves, regardless of our achievements.
It's more like the kid has just given the parent the finger and said that he doesn't need him anymore, then tried to drive off in his Dad's car - great show of independance.
The whole point of the joke is that the scientists were trying to create life for themselves, not steal it from God. And whilst the scientists were a little too cocky, they weren't exactly rude either, so your analogy doesn't seem very accurate.
It's the classic master-student story, where the student attempts to prove himself superior, but is cut down in some unexpected fashion by the much wiser master. But putting God in the role of the master is inherently problematic, because there's a vast gulf between the inherent abilities of man, and the inherent abilities of God.
For instance, if an amputee child managed to produce a working and road-worthy car out of bits and pieces he found in a garden shed, we'd be rather impressed. Imagine someone with such disadvantages succeeding in building a complex device with such primitive tools. Now suppose the child's uncle, a billionaire owner of a luxery car company hears about this. "Ridiculous!" the billionaire cries, "I don't see why everyone is making such a fuss about this! With but a phone call, I can have a car a thousand times better built in half the time! And as I own a number of quarries and smelting factories, I have no need to use scraps made by other people. Surely this proves I am far superior than my ham-fisted, no-legged nephew."
In this case, the uncle comes off looking like an asshole. We notice this because we can clearly judge the successes and failings of other humans; whilst the billionaire can produce a superior car through his company, it takes him no effort to do so, and thus his actions are inherently unimpressive. But if we replace the billionaire with God, our sense of perspective becomes warped. We have an innate modesty, almost a blindness, that prevents us from being amazed at our own achievements.
The point of the joke, as I see it, is that wrangling over evolution is really avoiding the question. If you want to argue over beginnings, argue over the real beginnings - how was matter, time, energy, etc formed? Until you can answer that, you can't really posit a universe without God (or without some other external force that made reality happen).
I can't work out what happened to one of my socks. Until I can work out where it went, am I to posit the existence of a sock-stealing gnome?
Further, you're looking at the Universe from the perspective of a three-dimensional creature, when the Universe has at least four dimensions. You ask how something was formed, but thinking of the beginning of the Universe as an event is inaccurate and misleading. It's better to think of it as a particularly interesting point in space-time. If the Universe could be represented as a sphere, for instance, the Big Bang would be the point in the centre. Asking what caused the centre of a sphere, or what was before the centre, is plainly nonsensical.
Now, one might suppose that our Universe is a structure connected, somehow, to another structure called "God". But why posit the existence of two structures, when we have only direct observations of one? It's like seeing a picture of a sphere, and claiming that there must be a connecting cone hidden behind it, because one simply can't imagine a sphere without a cone attacted to it.
Well sure, if you see humanity as a mechanism set into motion by God, then it's a little difficult to take credit for any accomplishments when we are but clockwork aspects of a greater whole. And, assuming I've understood your position, humility may very well be the correct position in that case.
However, many religions that have a divine creator go to great lengths to separate us from him, to have our motivations and actions as independent of our deity. The Christian Bible, for instance, has many instances where humans go against God's wishes, and even if one believes this is merely a ploy, a creator playing with the cogs in his machine, it makes little sense to have a concept of heaven and hell in order to punish human actions that are all part of a greater design.
It seems to me that if you believe in taking responsibility for one's own actions, then it follows that you can legitimately claim pride over one's successes. To take responsibility for your failings, but to never take pride in your success, seems somehow perverse, or at the very least reveals a deep lack of self worth.
God just looked at him and said, "No, no, no. You go get your own dirt!"
I find jokes like this interesting, because they demonstrate quite neatly humanity's obsession with modesty. Humans have relatively little power to alter their surroundings. We have hands and fingers that can manipulate small objects, but nothing much beyond that. We're a creature who's first resume could be summed up with "Skills: Can throw rocks" and "Hobbies: Enthusiastic hooting". We live short lives and die horribly easily. Compared to the vast energies of quasars, or the intricacies of quantum particles, we are powerless and clumsy creatures; small sacks of meat with little more natural skills than the ability to pick up small stones.
But in a blink of the cosmic eye, our species has constructed, well, this. Technology of unfathomable intricacy, abilities far beyond the dreams of our forebears. When you consider what we started out with, and where we are now, and how much work goes into everything we take for granted, it's too much for a single mind to comprehend. But rather than reflect on our amazing achievements, we exhibit an enviable modesty, making jokes comparing these achievements to a hypothetical perfect being. We ever hold in our minds how far we have to go, almost never considering how far we have come.
It's akin to leaving a child on a beach, and coming back an hour later to find he's accepting a Nobel Prize for the particle accelerator he build out of sand and seaweed. You might be amazed, but the child would merely shrug depreciatingly, and say something like "Well, it's not as good as the one at CERN."
Conversely, our concept of God is a entity that is inherently incapable of performing impressive actions. He might make impressive things, or be impressive to behold, but because his power is, by definition, unlimited, there can be no effort, or possibility of failure involved in his manipulations of the Universe. God creating a human being is no more impressive than a human picking a pebble off a beach; both are inherent skills that require no effort or risk of failure. But for a human being to create life, for a being of our meager abilities to succeed in reproducing, even in part, the awesome forces of nature and the cosmos... now that's impressive.
In summary, that joke makes God look like the asshole parents who try and win races against their 5 year old children. It's not a flattering image.
As far as languages like ADA and Haskell go with tough compile time checks, they have a tendency to make people think their code is good, and they rely too much on the checks and they stop thinking.
I'm not sure it's possible for a mere human to program in Haskell without thinking:) - it's a pretty tricky language to work with.
Inexperienced and stupid programmers produce bugs at nearly constant rate -- give them something that makes some bugs impossible, and they will either improve their productivity (still with $deity-awful rate of bugs), or start making different kinds of bugs.
Assuming it is the former, that their productivity increases but the rate of bugs remains the same, then surely that logically implies that they'll create products with less bugs? If programmer Joe creates 10 bugs in an hour, then if he finishes in 10 hours he'll have 100 bugs in his application, whilst if he's less productive and takes 20 hours he'll wind up with 200.
The average driver can't take out the whole bridge. The average programmer can. Software is just not understood as well as structural engineering, and most of the people we allow to do it couldn't even get into an engineering program.
It seems to me that's all the more reason to have more rigorous compile-time checks, then.
Merely because there are a large number of things that can go wrong, doesn't mean that adding safety checks that eliminate only some of the problems is a bad idea.
With a general purpose programming language, the number of ways to screw up is effectively infinite. If you take another infinite set, say, the integers, and eliminate a large subset, say the even integers, you still have an infinite set left over.
By the same token, the number of ways to befall a terrible accident is effectively infinite. Does that therefore mean we should not bother putting railings on bridges, or seatbelts in cars, or fuses in sockets?
I also, long ago, used to believe that language features could improve software reliability. Nowadays the idea just makes me cackle
Why? Certain languages have features that eliminate large classes of errors. Whilst its possible that programmers will find other ways to screw up, I'd have though that reducing the set of errors that are actually possible would go some way to improving reliability.
Out of curiousity, what languages are you familiar with? Have you worked much in languages with very tough compile-time checks, like Haskell?
Adblock does not, by default block anything. It's the libraries that you add to ABP that block things, and the things you add yourself.
You're probably right. I use Adblock Plus, which does provide a default option for the filter subscription part of the wizard that runs after you install it.
Slashdot Mirror
1. Start with a grid of data
2. Filter out empty rows
3. Group rows together that have identical values for the first column.
4. Make a tree branch from each route, using the value of the first column as the head of the branch, and use recursion to find the child branches from the remaining columns (i.e. every column but the first) of the grid.
So:
Becomes:
Sometimes this (known as "crashme" approach) catches errors. Most of bugs, especially security-related ones are still missed.
Try to calculate all possible combinations of states in a program that occupies 10M of heap and stack (each bit can be one or zero), and take into account all possible relative positions of instruction pointer in its multiple threads.
Oh, don't be ridiculous. Bugs aren't distributed evenly through a program's state space.
This is a stupid analogy. If you wear more than one seatbelt, it will make you LESS safe
Analogies are not meant to be illustrative, not comprehensive.
And most of those automated checks did not contribute anything at all to security fixes because conditions that trigger security bugs usually require knowledge and analysis of the system
Valgrind? Lint?
It does not matter how much is in the set. What matters is how much is outside of it -- and in case of bugs it's for all practical purpose the infinity.
Of course it isn't. The number of possible bugs for any program is always going to be finite, and even simple tests can reduce the number of possible bugs by a significant fraction. If you keep halving a mountain, it doesn't take many iterations until it's dust.
What I have described are general principles. They do not correspond to any particular styles of programming languages, styles or even "doctrines" such as functional programming, object-oriented programming, use of particular models, etc.
In other words, you can't back up your argument with a concrete example.
I think I'm beginning to get wise to this. In the past, I've often spend quite a few posts on various boards debating my point, but I've come to the conclusion that vague concepts that can't be explicitly nailed down and demonstrated are not worth arguing over, because there can never be any closure. You say this, I say that, and we get nowhere.
So, unless you want to start backing up your argument, I think I'm going to leave this thread for the archives and googlebots.
Except nobody can read that. The line noise up there with perl!
Nonsense. You need to be familiar with Haskell's syntax, but once you are, it's as clear as it can be for what it does.
Reading the Haskell in evaluation order:
Filters out blank lists.
Groups rows whose first column is identical.
This uses a function from Control.Applicative, but once you know that:
It's not so scary. It takes the first cell from the first column of the group (head . head) to use as the value of the branch node, and then passes all the remaining columns (map tail) back into the listToForest function, and uses this as the subtree.
Not trivial, but pretty clear when you think about it.
Have you tried it in C# with LINQ? It should map almost exactly to LINQ, just with different syntax.
Yes, you're probably right. LINQ is a specialised form of monad comprehension, and I suspect that some of the Haskell programmers that Microsoft employs might have contributed to the initial idea. For a 'popular' language like C#, LINQ is a pretty advanced feature to have. I guess Microsoft was able to get away with it by dressing it up in SQL-like syntax.
That said, I'd be interested in seeing someone actually produce the code. I suspect LINQ would allow for a pretty concise implementation, but there may be gotchas in the Haskell code that LINQ wouldn't be able to deal with.
I'm not going to take the time to look up the appropriate API calls at the moment, but I believe it's somewhere in the range of 2-3 lines of code to accomplish this feat.
If you're not going to take the time to actually produce any code to back up your point, why bother replying?
The biggest problem with talking about the advantages and disadvantages of programming languages is that people tend to make vague claims without producing any evidence for their case. Can JPA produce lazily produce a hierarchical tree of objects from a single database query? I don't know; it's not an answer you're likely to find in an FAQ or a tutorial. And how much work is it to actually set JPA and XStream up? Does it really only take 2-3 lines of code?
Without providing working code, who knows whether your assertion has any merit or not.
The point is that there's nothing those languages can do that can't be done, often more easily, with the current crop of popular languages.
At University, I studied SML, and came out with a opinion similar to yours concerning functional languages. But when I started to learn Haskell on my own, really learn it, I found that all the concepts in my CompSci courses that seemed so pointlessly complex before, just fell neatly into place.
I'll give you an example of a case where my solution in Haskell to a problem was rather better than any solution I came up with in C#. A while ago I was designing a program to export some hierarchical data held in a database to XML. Because SQL resultsets are 2D grids, I needed a way of converting a 2D grid into a list of fixed-depth tree structures.
In Haskell, the solution is two lines of code, and assuming you know Haskell pretty well, it's fairly clear as well:
I'd be interested to see if you could mirror the functionality in one of the 'popular' languages you mentioned. Perhaps something in Java?
Lack of this "absolute perfection" is the reason why most of software is chock-full of security bugs. Security is one area where pretty much anything unexpected done by a program as a response for (usually) invalid input results in a massive hole that will be eventually exploited. Developer that relies on tests will never hit those conditions unless tests are developed by someone much smarter than he is.
Or more methodical. For instance, testing a distributed sorting algorithm by shoving ten billion random numbers through is a good way of checking for any flaws the human eye may have missed. The computer doesn't have to be smarter than you in order to catch something you've missed, just like a computer doesn't have to be smarter than you to beat you at chess. Sheer brute force is the advantage of a computer; it can zip through thousands, even millions of discrete tests per second.
Automated tests aren't a mechanism for replacing human thought, any more than seatbelts replace the need for safe driving. But people make mistakes, and even the most security-conscious applications have bug trackers. Unit tests are a way of reducing human error by taking advantage of the computer's ability to singlemindedly check thousands of conditions every time the developer makes a change. A good type system works in much the same way, checking a more abstract, but more comprehensive set of conditions each time the program compiles.
Fortunately the solution is actually simple -- design software in a rule-based manner (so no actual scenario has ever to be considered, only classes of it), with consistent representation of data (so "deep propagation of invalid conditions" such as your example with "None" will never happen), and clearly defined interfaces (so programmer has a limited scope of code to work on, and clearly defined requirements to what it should accept and produce).
That rather sounds like a description of a functional type system to me, but perhaps I'm misunderstanding. Can you give an example to clarify your explanation?
Those are the kind of improvements that I describe as "If this actually managed to help you, you were not qualified to do this job in the first place". If programmer does not consider full set of possible outcomes of all situations, he can't write a program that properly handles it. If compiler throws some of those outcomes in his face, there will be still plenty of ones he did not take into account
It sounds as if you are suggesting that a programmer is only competant if he or she makes no mistakes; if their programs compile first time, if every scenario is accounted for, if there are no bugs anywhere, ever, in their software.
If absolute perfection is the yardstick you measure by, no wonder you believe most programmers are incompetant.
For programmers that are merely mortal, automated tests and checks are a useful tool. If you're refactoring a large application, tracking every possible result of each alteration by hand is impractical and inefficient. Far better to use unit tests and compile time checks to ensure correctness, as a thousand automated tests are going to be less prone to error than checking a thousand things by hand.
This still does very little to reduce the number of actual bugs
Only if the programmer is a complete incompetent, but you don't need to be a complete incompetent for there to be bugs in your code.
In your example if programmer does not know what to do when he gets None, he will still do something invalid down the line when he applies it to some other operations (like, skipping None lines in the input file when formatting it for printing, or waiting None seconds before dialing the phone number, or allocating None IP addresses for some devices, or measuring the distance to an object None meters tall using a camera image where it takes 20 pixels).
Most of the examples you provide would be caught by the Haskell compiler. If you tried to sleep for 'Maybe Integer' seconds, the compiler would complain. You'd need to explicitly extract the Integer part, accounting for the None possibility.
Similarly, you'd have to explicitly tell Haskell that the distance to an object was 'Maybe Float' metres, rather than just 'Float' metres. It would require a really enterprising idiot to work around the typing errors without once engaging his brain.
That's not to say that there aren't people that stupid, as stupidity is not a resource the Earth is short on. However, not every programmer is an utter moron; in fact, there is a not insignificant proportion of programmers capable of some logical thought, surprising though that may be. If the compiler tells a developer, "You're not accounting for the possibility that the user might not have a display picture", then I hope I'm not being terribly optimistic to assume that at least some programmers would say, "Hey, you're right - I'll fix that", rather than to stare blankly and drool upon the keyboard.
Compile-time checks aren't a complete solution, but to claim that they won't have any effect at all seems silly.
I'll give you an example. The Java compiler cannot guarentee that a program will not raise a NullPointerException during its execution. In contrast, the Glasgow Haskell Compiler can guarentee that no null references will ever exist if the program passes compilation.
And I can "solve" a halting problem by inventing a language that runs all programs in a loop, so they can't halt.
Re-reading my statement I can see I missed out a word that changes the whole meaning, so it's no wonder you seemed less than impressed ;)
I meant to type:
The Glasgow Haskell Compiler can guarentee that no null reference exceptions will ever exist if the program passes compilation.
Haskell allows null references, or the equivalent thereof, but the compiler will ensure that you never refer to a null reference when you expect a value.
For instance, the following Haskell program will not compile:
The compiler knows that (5 `div` 0) could be None (the equivalent to null), and None * 10 is a nonsensical statement. You have to explicitly account for both possibilities before it compiles:
This is a pretty common pattern, so Haskell provides a shortcut:
But whilst shorter, this isn't exactly more readable. So Haskell provides the 'do-notation' syntax sugar to make it look better:
And there we have code guarenteed to be free of null pointer exceptions by the compiler, whilst still allowing null pointers to exist.
And I can "solve" a halting problem by inventing a language that runs all programs in a loop, so they can't halt.
The difference between your approach and Haskell's is that you're reducing errors by limiting the language, whilst Haskell reduces errors by increasing the scope of the type system. The more powerful type system you have, the more you can tell the compiler about your program, and the more errors can be caught at compile time.
You don't need to limit the language to eliminate large categories of bugs. You just need to have a flexible enough type system that the compiler can figure them out on its own.
This is not a property of compiler, it's a property of language. Language is not defined by "compiler checks", it determines what compiler does in the first place.
I didn't say it was a property of the compiler. I said it was a "compile-time check" - a check that happens at compile time.
I have no idea, what do you mean by "tougher compile-time checks" -- if the compiler does not produce an error on invalid source, it's a buggy compiler.
If you have no idea what I'm talking about, why are you arguing the opposite view instead of asking me what I meant?
I'll give you an example. The Java compiler cannot guarentee that a program will not raise a NullPointerException during its execution. In contrast, the Glasgow Haskell Compiler can guarentee that no null references will ever exist if the program passes compilation.
This isn't a bug with the Java compiler. Java's type system was not designed to distinguish between types that can be null, and types that cannot. The Haskell type system is more sophisticated, and thus the compiler can perform more stringent checks.
They use a trial-and-error method that I call "perma-debugging" -- writing code that seems right, compiling it, making random changes until it compiles, running it on some test input, making random changes until the test runs, writing more code and repeating the process. The result of this process is your typical buggy piece of software.
Whilst this is far from an ideal way of writing software, I suspect that using this method with Haskell would produce fewer bugs than with Java.
Unfortunately, Haskell is difficult for even good programmers to understand, so I wouldn't hold out hope that everyone will switch to Haskell and start writing less buggy code. On the other hand, if you use Haskell to write your code, it's much less likely you'll wind up hiring crap programmers :)
Constant bugs rate means that number of bugs increases with productivity, and products remain just as buggy.
So you're saying that tougher compile time checks would make inept programmers more productive, but not reduce their bug count.
Unless you're proposing that inept programmers deliberately insert bugs into their code, I'm uncertain how you reached this conclusion.
Yet, humans have managed in their brief existence to take a good number of other races out, lift the global temperature a few degrees and pretty much change a planet into a huge trash can.
So yeah, you're right. I awe at the accomplishments of the human race.
I think this very neatly demonstrates our inherent myopia when it comes to what we've achieved. We focus on the worst aspects of ourselves, completely blind to the miracles we've constructed. I suspect this is a survival trait, a way of ensuring that we continually strive to better ourselves, regardless of our achievements.
It's more like the kid has just given the parent the finger and said that he doesn't need him anymore, then tried to drive off in his Dad's car - great show of independance.
The whole point of the joke is that the scientists were trying to create life for themselves, not steal it from God. And whilst the scientists were a little too cocky, they weren't exactly rude either, so your analogy doesn't seem very accurate.
It's the classic master-student story, where the student attempts to prove himself superior, but is cut down in some unexpected fashion by the much wiser master. But putting God in the role of the master is inherently problematic, because there's a vast gulf between the inherent abilities of man, and the inherent abilities of God.
For instance, if an amputee child managed to produce a working and road-worthy car out of bits and pieces he found in a garden shed, we'd be rather impressed. Imagine someone with such disadvantages succeeding in building a complex device with such primitive tools. Now suppose the child's uncle, a billionaire owner of a luxery car company hears about this. "Ridiculous!" the billionaire cries, "I don't see why everyone is making such a fuss about this! With but a phone call, I can have a car a thousand times better built in half the time! And as I own a number of quarries and smelting factories, I have no need to use scraps made by other people. Surely this proves I am far superior than my ham-fisted, no-legged nephew."
In this case, the uncle comes off looking like an asshole. We notice this because we can clearly judge the successes and failings of other humans; whilst the billionaire can produce a superior car through his company, it takes him no effort to do so, and thus his actions are inherently unimpressive. But if we replace the billionaire with God, our sense of perspective becomes warped. We have an innate modesty, almost a blindness, that prevents us from being amazed at our own achievements.
The point of the joke, as I see it, is that wrangling over evolution is really avoiding the question. If you want to argue over beginnings, argue over the real beginnings - how was matter, time, energy, etc formed? Until you can answer that, you can't really posit a universe without God (or without some other external force that made reality happen).
I can't work out what happened to one of my socks. Until I can work out where it went, am I to posit the existence of a sock-stealing gnome?
Further, you're looking at the Universe from the perspective of a three-dimensional creature, when the Universe has at least four dimensions. You ask how something was formed, but thinking of the beginning of the Universe as an event is inaccurate and misleading. It's better to think of it as a particularly interesting point in space-time. If the Universe could be represented as a sphere, for instance, the Big Bang would be the point in the centre. Asking what caused the centre of a sphere, or what was before the centre, is plainly nonsensical.
Now, one might suppose that our Universe is a structure connected, somehow, to another structure called "God". But why posit the existence of two structures, when we have only direct observations of one? It's like seeing a picture of a sphere, and claiming that there must be a connecting cone hidden behind it, because one simply can't imagine a sphere without a cone attacted to it.
Well sure, if you see humanity as a mechanism set into motion by God, then it's a little difficult to take credit for any accomplishments when we are but clockwork aspects of a greater whole. And, assuming I've understood your position, humility may very well be the correct position in that case.
However, many religions that have a divine creator go to great lengths to separate us from him, to have our motivations and actions as independent of our deity. The Christian Bible, for instance, has many instances where humans go against God's wishes, and even if one believes this is merely a ploy, a creator playing with the cogs in his machine, it makes little sense to have a concept of heaven and hell in order to punish human actions that are all part of a greater design.
It seems to me that if you believe in taking responsibility for one's own actions, then it follows that you can legitimately claim pride over one's successes. To take responsibility for your failings, but to never take pride in your success, seems somehow perverse, or at the very least reveals a deep lack of self worth.
God just looked at him and said, "No, no, no. You go get your own dirt!"
I find jokes like this interesting, because they demonstrate quite neatly humanity's obsession with modesty. Humans have relatively little power to alter their surroundings. We have hands and fingers that can manipulate small objects, but nothing much beyond that. We're a creature who's first resume could be summed up with "Skills: Can throw rocks" and "Hobbies: Enthusiastic hooting". We live short lives and die horribly easily. Compared to the vast energies of quasars, or the intricacies of quantum particles, we are powerless and clumsy creatures; small sacks of meat with little more natural skills than the ability to pick up small stones.
But in a blink of the cosmic eye, our species has constructed, well, this. Technology of unfathomable intricacy, abilities far beyond the dreams of our forebears. When you consider what we started out with, and where we are now, and how much work goes into everything we take for granted, it's too much for a single mind to comprehend. But rather than reflect on our amazing achievements, we exhibit an enviable modesty, making jokes comparing these achievements to a hypothetical perfect being. We ever hold in our minds how far we have to go, almost never considering how far we have come.
It's akin to leaving a child on a beach, and coming back an hour later to find he's accepting a Nobel Prize for the particle accelerator he build out of sand and seaweed. You might be amazed, but the child would merely shrug depreciatingly, and say something like "Well, it's not as good as the one at CERN."
Conversely, our concept of God is a entity that is inherently incapable of performing impressive actions. He might make impressive things, or be impressive to behold, but because his power is, by definition, unlimited, there can be no effort, or possibility of failure involved in his manipulations of the Universe. God creating a human being is no more impressive than a human picking a pebble off a beach; both are inherent skills that require no effort or risk of failure. But for a human being to create life, for a being of our meager abilities to succeed in reproducing, even in part, the awesome forces of nature and the cosmos... now that's impressive.
In summary, that joke makes God look like the asshole parents who try and win races against their 5 year old children. It's not a flattering image.
As far as languages like ADA and Haskell go with tough compile time checks, they have a tendency to make people think their code is good, and they rely too much on the checks and they stop thinking.
I'm not sure it's possible for a mere human to program in Haskell without thinking :) - it's a pretty tricky language to work with.
Inexperienced and stupid programmers produce bugs at nearly constant rate -- give them something that makes some bugs impossible, and they will either improve their productivity (still with $deity-awful rate of bugs), or start making different kinds of bugs.
Assuming it is the former, that their productivity increases but the rate of bugs remains the same, then surely that logically implies that they'll create products with less bugs? If programmer Joe creates 10 bugs in an hour, then if he finishes in 10 hours he'll have 100 bugs in his application, whilst if he's less productive and takes 20 hours he'll wind up with 200.
The average driver can't take out the whole bridge. The average programmer can. Software is just not understood as well as structural engineering, and most of the people we allow to do it couldn't even get into an engineering program.
It seems to me that's all the more reason to have more rigorous compile-time checks, then.
Just because a languages reduces or even removes certain classes of problems does not mean it doesn't create new ones.
Nor does it mean that does. What's your point?
You're missing the point.
Merely because there are a large number of things that can go wrong, doesn't mean that adding safety checks that eliminate only some of the problems is a bad idea.
With a general purpose programming language, the number of ways to screw up is effectively infinite. If you take another infinite set, say, the integers, and eliminate a large subset, say the even integers, you still have an infinite set left over.
By the same token, the number of ways to befall a terrible accident is effectively infinite. Does that therefore mean we should not bother putting railings on bridges, or seatbelts in cars, or fuses in sockets?
I also, long ago, used to believe that language features could improve software reliability. Nowadays the idea just makes me cackle
Why? Certain languages have features that eliminate large classes of errors. Whilst its possible that programmers will find other ways to screw up, I'd have though that reducing the set of errors that are actually possible would go some way to improving reliability.
Out of curiousity, what languages are you familiar with? Have you worked much in languages with very tough compile-time checks, like Haskell?
Adblock does not, by default block anything. It's the libraries that you add to ABP that block things, and the things you add yourself.
You're probably right. I use Adblock Plus, which does provide a default option for the filter subscription part of the wizard that runs after you install it.