41–50 of 65 posts
Yep, there is no silver bullet. But that doesn't mean all bullets are created equal.
Yes, but perhaps we it means we can stop bitching about each other's bullets of choice and get back to shooting.
Yes, static typing is not enough. Which is why a good statically typed language like Haskell also has great testing facilities. So you don't just write well typed code, but you also write unit tests (HUnit) and property-based tests (QuickCheck). The really neat bit is that static typing actually makes writing tests easier--QuickCheck is much easier to use in Haskell than it would be in some dynamically typed language…
QuickCheck is great and can be found in many languages - dynamic and static alike - nowadays. Another tool that is currently unique to Haskell and is easier to write tests for is Lazy/SmallCheck. SmallCheck shines in the left long tail of failure. Its core idea is based on a powerful principle: "If a program does not fail in any simple case, it hardly ever fails in any case." [] So SmallCheck works exhaustively to fi…
http://permalink.gmane.org/gmane.comp.lang.haskell.general/1...
Unfortunately, this is not enough. You need a consistent and complete specification, too.
Yet another attempt to diminish the value of statically typed languages and the benefits that go along with them.
I'm question if you read the post because I didn't diminish anything. I did say that it is a tool in the fight of software validation however.
Yet another attempt to diminish the value of statically typed languages and the benefits that go along with them.
Also: <3 Love Driven Development <3
Kind of a strawman argument, as no developer would argue that only unit tests and static typing are needed to guarantee quality.
Doesn't anyone view static typing as done in a language like Haskell as a form of documentation? I am not saying ALL Haskell code can be deciphered by its types - hell no. But a useful technique is to express the semantics of the program into the type system (as much as possible anyways) to communicate intent. This is a huge benefit over dynamic languages imho. So there is more too it than just verification, even if…
[1]: http://lambda-the-ultimate.org/node/1178
Happily, there are practical programs that take advantage of the types' expressiveness. My favorite example: Hoogle[2]. It's brilliant: a search engine that given a type signature gives you a list of functions either with that type (modulo renaming) or a similar type. The beauty is that it can work even if the function is more general than what you're looking for and has a weird name (so a normal search would not be very helpful).
[2]: http://www.haskell.org/hoogle/
A perfect example: let's say you're looking for the equivalent of JavaScript's join method. It would have the type [String] -> String -> String. Now, this particular function does not actually exist in Haskell. Instead, there is a more general function called intercalate that works on any list. Moreover, intercalate's arguments are reversed: it's type is actually [a] -> [[a]] -> [a] (or String -> [String] -> String if made specific to String). And yet, if you search for [String] -> String -> String, the second result is intercalate! It's magical.
In short: types are basically a form of self-documenting code, so you get a lot of cool stuff for free given a good type system.
Yep, there is no silver bullet. But that doesn't mean all bullets are created equal.
Yes, but perhaps we it means we can stop bitching about each other's bullets of choice and get back to shooting.
You need formal machine-checked verification (Coq, Isabelle). Unfortunately, this is not enough. You need a consistent and complete specification, too.
The second isn't so clear, but sometimes you can get a bit more confidence by showing that other good properties are implied by the specification alone.