Personally what I'd want would be something that involves all personal data being encrypted on the server side according to a private key that only the user has, with shared sub-information being encryped with shared sub-keys. Thus, even if the distributed social networking server is compromised, private data will remain (largely) private. Some more thought needs to be put into ensuring that it's not easy to infer the presence of shared keys, or otherwise even the encrypted data would allow an attacker to infer part of the structure of the acquaintance graph (which can then be used to infer other information).
I pretty much stopped watching TV in 2002, when I moved to the US. Not only were the ads unbearable, but the shows I cared about were never on at the time I wanted to watch them.
At this point, I use various online services (sadly reliant on Flash) to watch the shows I want to watch. Unfortunately, many of them still contain ads-- I'd happily pay the providers to not interrupt their shows with that nonsense. Alas, certain shows (such as the new Doctor Who series) are not accessible in that fashion, so I will have to wait many months until they are released on DVD.
Of course, Doctor Who is available on (probably illegal) bittorrent, but I don't consider that an option (since I can't buy a UK TV licence, which I would be willing to do for that purpose.) I've e-mailed BBC America asking specifically to buy a licence to download their shows: `I give you money, you don't sure me for bittorrenting your stuff.' (Yes, it sounds a bit like protection money.) Unfortunately they never got back to me.
I find it unlikely that content providers have not realised the demand by people like me. I've heard rumours that iTunes sells TV shows these days; could it be that the majority of people are flocking to these proprietary platforms, preventing a truly open solution from manifesting?
According to a report in a major German newspaper (FAZ), there will be launches from at least Berlin and Frankfurt and some other German airports, but not in all directions.
The fines are around $700, if I read that correctly.
That sounds like more than health insurance would normally cost. I pay $600 for my international travel health insurance, per year (this covers me almost completely-- excluding more expensive dental work-- while I live and work in the US, and while I travel elsewhere.)
I would expect CD-ROMs and DVD-ROMs to be reasonably safe (though any reading devices might be temporarily disabled or permanently damaged.) But what about HDDs? Are they sufficiently shielded against this?
Yes, losing power is a serious issue that will cost lives and losing GPS etc. would be very bad, too. But more and more of our cultural and scientific achievements are stored primarily on magnetic drives that may or may not be suitably shielded. How much at risk are those data, or should I invest in lead shielding for my backup storage drive?
Sun got it right on their keyboard design, but everyone else kept the CapsLock key. I've been using computers for 21 years, and I use Ctrl constantly. I do not recall ever having used the CapsLock key (except out of curiousity to see whether it actually does anything.)
(Well, that's a bit of a lie. Of course I use it, after reassigning it to Ctrl. But the point is, having to take that step is a waste of time.)
CapsLock was useful once upon a time, when there was no \section{} or \textbf{}, and when pressing `shift' actually required strenght. But those days are gone.
Yes, some things need to be done in assembly or C in order to `stay competetive' or even just to remain within the realm of the possible. How much that is depends on your application and your platform.
So, systems programmers, you need not worry, your skills are always going to be needed for something.
But let's be honest here, 80% of the applications you can code entirely in Haskell or Prolog or Python or whatever fancy high-level language you may personally have come to love. And of the remaining 20%, you can usually still code 80% of the application in your favourite language and optimise the core 20% in C. (After profiling. Let me repeat that, AFTER profiling.)
Will it run faster and in less memory if you do it all in C? If you do it properly, sure. But that's not the question to ask. If you work commercially, ask for `what will be most profitable in the long run, while remaining ethical'. If you work free software projects, ask for `what will benefit people the most'.
Don't confuse the above questions with `what will satisfy my C(++) hacker ego the most'. And remember that it's not just about getting the code working and making it fast, it's about making the code robust; and in many cases it's also about making the code readable for whoever will maintain it after you.
Apologies for this rant; feel free to mod it down if you so desire, but you, dear fellow programmers, have had it coming for quite a while, as did I.
I pray that the future will not be dynamically typed. We have enough run-time bugs as-is, and while I am in no way opposed to doing prototyping in dynamically typed languages, I would much prefer my everyday applications to be written in languages that don't constantly segfault because of pointer arithmetic, raise null pointer exceptions because nullable and nonnullable types are not distinguished, or give syntax errors at runtime because they happen to be fully interpreted.
Most static type systems suck, which is why people don't like them, but people who have used, say, SML or Haskell, tend to agree that static types can be something very natural and useful (the SML community has a saying which goes, roughly, "if it compiles, it's almost certainly correct").
I don't know about you guys, but I'd much rather have a slightly harder time with dynamic module loading, reflection (which, IMHO, is vastly overrated, considering the correctness/safety/usefulness tradeoff) and perhaps side effects than having to find all of my bugs (rather than 5% of them) through testing.
Interesting conjecture, and I frankly don't know whether you'd be right about that or not. The reason why I mentioned "putting FP back into the curriculum" was, however, that it is my understanding that, if you're right, there's a good chance that programmers would prefer multithreading in imperative languages precisely because it'd be closer to what they'd be used to. So, by getting them used to FP, we'd see a "more fair" evaluation of the practicality of this approach.
Good thinking, IBM. Now, let's get SML/NJ, Haskell, and O'Caml ported to these things.
"Why", you may wonder, but the answer is simple: Referential transparency or any kind of confinement of side-effects makes for easy parallelisation, which is what these Cell thingies are supposed to rock at.
This might be the one thing that will put FP back into the undergraduate curriculum.
Does anyone happen to know whether GNU Arch has been considered? I've been using it for a while and find it quite good (it's not perfect, but it's the best versionning system I've used so far).
Sorry if this is a dupe (it's so obvious someone has probably already suggested it, though if so, I missed it):
How about we simply get rid of that entire "change-the-meaning-time-twice-per-year" idea? Yes, I know, kids, cars, dark. How about we start school an hour early in the winter months? The result is the same, but we don't have to deal with the confusion caused by the meaning of the current time of day changing.
Personally, I find it easier to remember that "I have to be at X at 7 tomorrow instead of 8, as usual" as opposed to "tomorrow, 7 will be what 8 was today, so I will have to turn the clock... back? forward? one hour tomorrow and then figure out where I'm supposed to go"
Nice... but is it really neccessary to list tiny little update releases for current languages? And what precisely "defines" a language here-- should we treat SML/NJ as a different language than SML, because it supports continuations? Or current GHC as something other than Haskell98 because of its rank-n polymorphism and built-in support for arbitrary Arrows? And if drafts are in there (Fortran 2000), what about other drafts (ML 2000)?
And, finally, where's Scala (http://scala.epfl.ch/) on that graph?
Disclaimer: I haven't read the article; however, I was somewhat involved in research in this field in late 2003 and early 2004.
What the summary of the article claims IBM is developing-- a technology for getting the semantics behind an arbitrary sentence on the web-- is the Holy Grail of the discipline of Natural Language Processing (NLP) and very, very, very, _very_ far away at this point. Many people believe that we cannot ever get there (that's the point of a Holy Grail, after all), but I don't want to be quite as pessimistic (or realistic?) at this point.
The problem here is that English (or any other natural language, for that matter) isn't SML, or Haskell, or some other language with a well-defined denotational semantics. Natural language suffers from at least three problems that make it very tough to gather anything useful from a given piece of text:
(1) Grammar. Natural language isn't typechecked, and frequently uses incomplete sentences, which makes it hard to develop grammars (context-free, context-free probabilistic, lambek-style/proofnet-style or whatever else people have come up with) for it.
(2) Anaphora resolution. "I saw a dog on the street this morning. It was barking". So who's barking, street or dog? Gramatically, both would be possible; only with prior knowledge we can see that we're talking about the dog here.
(3) Polysemy. What does "play" mean, taken by itself? It can be used for different meanings in "to play a game", "a play of words", "a terrific shakespearian play" etc.; you might want to have a look at wordnet one of these days to get a feeling for this. Not knowing which meaning an arbitrary occurence of "play" refers to means that you have to try lots of options when parsing, LSIing or whatever else you do (though most people simply ignore this problem in research today-- it's too hard to disambiguate words in practice).
That's not all, of course-- try thinking of the need to deal with irony/sarcasm, metaphors, foreign words, the credibility of whichever sources you're using etc., and you'll get a pretty good feeling for why this is beyond merely being "hard". Of course, for very small problem domains (a "command language for naval vessels" was investigated in one paper I read a while ago-- those DARPA people definitely have too much money on their hands, but I digress), this can be solved, but general-purpose open-domain NLP is what you need to do a web search.
It might happen in my lifetime, but I won't hold my breath for it.
Hmm... why do we always get new expressivity features and library extensions, instead of new safety features and ways for statically checking our code (such as type checking, a novel but, admittedly, completely impractical and academic invention that only freak languages use)?
I guess because people like me prefer to complain and use other languages instead of fixing unsafe ones...
They're not quite the same; C++ templates are essentially glorified preprocessor macros with some relatively small checking and a rather baroque underlying functional language. Generics are more concrete than that.
Not to mention that attached to variable name doesn't make code any more attractive to look at.
It would be really neat to have type inference there;-)
It appears that Java's way to solve run time errors is to screw the bolts as tight a possible during compile time.
That's the idea, and that's also what I try to do when writing programs. Why should I have to write half a dozen test suites for some simple program property if the type checker can tell me whether it'll work right?
Remember: Compilers don't do type checking just to optimise, but also to catch programming errors. And Generics allow you to catch a much more interesting class of these.
Yes, Generics can be used for much more than this, particularly in combination with anonymous classes (which are Java's way for handling higher-order functions). Again, a lot of examples for this can be found in existing languages, e.g. we can now have something equivalent to the 'map' function found in functional languages. Here's a Haskell definition of map:
map:: (a -> a) -> [a] -> [a] map f [] = [] map f x::l = f(x)::l
I don't know the precise Java syntax for Generics, so I'll make one up for a Java equivalent:
public interface F[A] {
public A f(A v); }
static Container[A] map(F[A] fn, Container[A] c) {
Iterator[A] i = c.getIterator();
while (i.hasNext()) {
i.performUpdate(fn.f(i.get()));
i.next();
}/* OK, these aren't standard iterators, but
** it's been a while since I last did Java
*/ }
Granted, it's not quite the same, particularly since it supposedly works on all containers (with the right kind of iterators) and performs a destructive update, but you get the idea-- you can do powerful stuff and still get your types right.
FYI: Generics are _much_ more than mere syntactic sugar (as are enumerators, a weak form of algebraic datatypes, if handled type-correctly). These are actually the kinds of things that make program maintenance considerably easier, since they allow more concise specifications of intended semantics to be done. No longer having to typecast (and thus expect run-time exceptions) when using a "vector of FooObjects" gives more power to the type checker, and thus allows a much richer class of programming errors to be detected at compile-time. This is the one major improvement in Java that's been missing since its very inception.
But note that "generics" or "parametric types" have been present in languages such as Eiffel or Sather for well over a decade, and for much longer in ML. In a way, it's embarrassing that such an essential feature was added this late during development.
On the other hand, my experience and the experience of others I've seen is that dynamicly typed languages are not only more fun to program in, they produce good results faster.
Hmm, my experience is slightly different. The 'fun' part is, of course, rather subjective-- I find dyanmically typed languages more frustrating, which is why I personally wouldn't agree with that, but, of course, YMMV-- but I definitely disagree about the part with "good results being produced faster".
They do produce results faster, often even reasonable results. But good results (i.e. stable code) take much longer to achieve, in my experience.
Put that the other way around -- do you want to spend the rest of your life working against strong typing systems which only detect errors that even the simplest test suite would automatically find?
I've rarely had to "work against" strong type systems in the past. Sufficiently expressive type systems are important for this to make sense, I'll admit that; it requires a certain kind of thinking to be able to make use of strong typing effectively. This restriction on "free thought" may be what people find most offensive, but I'm not sure.
Regarding test suites: It is very hard to construct (for a non-trivial program) a test suite that achieves complete code coverage (recall that you'll want to check all of your error and special case handlers). Right now, test suites are the most reasonable approach to handling properties beyond the capabilities of type systems in languages we can come up with ("Does this function terminate? Does the sequence of file system updates it performs correspond to what I want it to do?"), and they are certainly a good complement to static checkers. But they rarely test all of the relevant properties of a program; as such, the neccessity for implementing a test suite can be considered as a sign of weakness of static checking. (That doesn't mean they should be omitted if static checking fails-- that'd be dishonest.)
There are errors which no static type system or static checker will be able to find (thanks to Goedel;-) but that doesn't mean that we should give up on static checking-- simply because no test suite writer will ever be able to test for all the things that fall out of a static checker for free.
In conclusion, I believe that we need static typechecking, static checking in general, and test suites for everything we cannot formalise (for whichever reason) if we want to ever resolve the "software crisis". Without any of these, we'll just keep inventing more crappy code.
That's true. But you can get pretty far in practice; moreover, having the developer specify (and the prover verify) auxiliary lemmata should resolve this problem in many situations.
The downside is that programmers will have to be able to deal with programs as well as with proofs if they want to produce stable code, but I'm not really convinced that this is neccessarily a bad thing.
Slashdot Mirror
Well, there is some work going on towards a distributed social networking protocol.
Personally what I'd want would be something that involves all personal data being encrypted on the server side according to a private key that only the user has, with shared sub-information being encryped with shared sub-keys. Thus, even if the distributed social networking server is compromised, private data will remain (largely) private. Some more thought needs to be put into ensuring that it's not easy to infer the presence of shared keys, or otherwise even the encrypted data would allow an attacker to infer part of the structure of the acquaintance graph (which can then be used to infer other information).
I pretty much stopped watching TV in 2002, when I moved to the US. Not only were the ads unbearable, but the shows I cared about were never on at the time I wanted to watch them.
At this point, I use various online services (sadly reliant on Flash) to watch the shows I want to watch. Unfortunately, many of them still contain ads-- I'd happily pay the providers to not interrupt their shows with that nonsense. Alas, certain shows (such as the new Doctor Who series) are not accessible in that fashion, so I will have to wait many months until they are released on DVD.
Of course, Doctor Who is available on (probably illegal) bittorrent, but I don't consider that an option (since I can't buy a UK TV licence, which I would be willing to do for that purpose.) I've e-mailed BBC America asking specifically to buy a licence to download their shows: `I give you money, you don't sure me for bittorrenting your stuff.' (Yes, it sounds a bit like protection money.) Unfortunately they never got back to me.
I find it unlikely that content providers have not realised the demand by people like me. I've heard rumours that iTunes sells TV shows these days; could it be that the majority of people are flocking to these proprietary platforms, preventing a truly open solution from manifesting?
The OSDI deadline is in August; plenty of time to implement this, write it up, and get a publication at a top research conference out of it!
According to a report in a major German newspaper (FAZ), there will be launches from at least Berlin and Frankfurt and some other German airports, but not in all directions.
The fines are around $700, if I read that correctly.
That sounds like more than health insurance would normally cost. I pay $600 for my international travel health insurance, per year (this covers me almost completely-- excluding more expensive dental work-- while I live and work in the US, and while I travel elsewhere.)
Person <> organisation. Very, very, very important.
I would expect CD-ROMs and DVD-ROMs to be reasonably safe (though any reading devices might be temporarily disabled or permanently damaged.) But what about HDDs? Are they sufficiently shielded against this?
Yes, losing power is a serious issue that will cost lives and losing GPS etc. would be very bad, too. But more and more of our cultural and scientific achievements are stored primarily on magnetic drives that may or may not be suitably shielded. How much at risk are those data, or should I invest in lead shielding for my backup storage drive?
Anyway, if they get John Leeson to do the voice, I'm buying one.
Sun got it right on their keyboard design, but everyone else kept the CapsLock key. I've been using computers for 21 years, and I use Ctrl constantly. I do not recall ever having used the CapsLock key (except out of curiousity to see whether it actually does anything.)
(Well, that's a bit of a lie. Of course I use it, after reassigning it to Ctrl. But the point is, having to take that step is a waste of time.)
CapsLock was useful once upon a time, when there was no \section{} or \textbf{}, and when pressing `shift' actually required strenght. But those days are gone.
Hi,
Yes, some things need to be done in assembly or C in order to `stay competetive' or even just to remain within the realm of the possible. How much that is depends on your application and your platform.
So, systems programmers, you need not worry, your skills are always going to be needed for something.
But let's be honest here, 80% of the applications you can code entirely in Haskell or Prolog or Python or whatever fancy high-level language you may personally have come to love. And of the remaining 20%, you can usually still code 80% of the application in your favourite language and optimise the core 20% in C. (After profiling. Let me repeat that, AFTER profiling.)
Will it run faster and in less memory if you do it all in C? If you do it properly, sure. But that's not the question to ask. If you work commercially, ask for `what will be most profitable in the long run, while remaining ethical'. If you work free software projects, ask for `what will benefit people the most'.
Don't confuse the above questions with `what will satisfy my C(++) hacker ego the most'. And remember that it's not just about getting the code working and making it fast, it's about making the code robust; and in many cases it's also about making the code readable for whoever will maintain it after you.
Apologies for this rant; feel free to mod it down if you so desire, but you, dear fellow programmers, have had it coming for quite a while, as did I.
Perhaps not in Canada, but I have been watching them here in Germany for over a week now. Well, not all the time, but still.
Well, if it's dynamic, it must be good, right?
I pray that the future will not be dynamically typed. We have enough run-time bugs as-is, and while I am in no way opposed to doing prototyping in dynamically typed languages, I would much prefer my everyday applications to be written in languages that don't constantly segfault because of pointer arithmetic, raise null pointer exceptions because nullable and nonnullable types are not distinguished, or give syntax errors at runtime because they happen to be fully interpreted.
Most static type systems suck, which is why people don't like them, but people who have used, say, SML or Haskell, tend to agree that static types can be something very natural and useful (the SML community has a saying which goes, roughly, "if it compiles, it's almost certainly correct").
I don't know about you guys, but I'd much rather have a slightly harder time with dynamic module loading, reflection (which, IMHO, is vastly overrated, considering the correctness/safety/usefulness tradeoff) and perhaps side effects than having to find all of my bugs (rather than 5% of them) through testing.
Just my EUR 0.018.
-- Christoph
Hi,
Interesting conjecture, and I frankly don't know whether you'd be right about that or not. The reason why I mentioned "putting FP back into the curriculum" was, however, that it is my understanding that, if you're right, there's a good chance that programmers would prefer multithreading in imperative languages precisely because it'd be closer to what they'd be used to. So, by getting them used to FP, we'd see a "more fair" evaluation of the practicality of this approach.
Alternatively, we might ultimately wind up with some "middle ground", as proposed in
imperative functional programming
on the functional end and
type system improvements for imperative languages of one kind or
another on the imperative/imperative OO language end.
-- Christoph
Good thinking, IBM. Now, let's get SML/NJ, Haskell, and O'Caml ported to these things.
"Why", you may wonder, but the answer is simple: Referential transparency or any kind of confinement of side-effects makes for easy parallelisation, which is what these Cell thingies are supposed to rock at.
This might be the one thing that will put FP back into the undergraduate curriculum.
-- Christoph
Wow, darcs looks really nice-- the "local copy=repository" makes perfect sense. I didn't know of it, but will give it a try. Thank you!
Does anyone happen to know whether GNU Arch has been considered? I've been using it for a while and find it quite good (it's not perfect, but it's the best versionning system I've used so far).
Sorry if this is a dupe (it's so obvious someone has probably already suggested it, though if so, I missed it):
How about we simply get rid of that entire "change-the-meaning-time-twice-per-year" idea? Yes, I know, kids, cars, dark. How about we start school an hour early in the winter months? The result is the same, but we don't have to deal with the confusion caused by the meaning of the current time of day changing.
Personally, I find it easier to remember that "I have to be at X at 7 tomorrow instead of 8, as usual" as opposed to "tomorrow, 7 will be what 8 was today, so I will have to turn the clock... back? forward? one hour tomorrow and then figure out where I'm supposed to go"
Nice... but is it really neccessary to list tiny little update releases for current languages? And what precisely "defines" a language here-- should we treat SML/NJ as a different language than SML, because it supports continuations? Or current GHC as something other than Haskell98 because of its rank-n polymorphism and built-in support for arbitrary Arrows? And if drafts are in there (Fortran 2000), what about other drafts (ML 2000)?
And, finally, where's Scala (http://scala.epfl.ch/) on that graph?
Disclaimer: I haven't read the article; however, I was somewhat involved in research in this field in late 2003 and early 2004.
What the summary of the article claims IBM is developing-- a technology for getting the semantics behind an arbitrary sentence on the web-- is the Holy Grail of the discipline of Natural Language Processing (NLP) and very, very, very, _very_ far away at this point. Many people believe that we cannot ever get there (that's the point of a Holy Grail, after all), but I don't want to be quite as pessimistic (or realistic?) at this point.
The problem here is that English (or any other natural language, for that matter) isn't SML, or Haskell, or some other language with a well-defined denotational semantics. Natural language suffers from at least three problems that make it very tough to gather anything useful from a given piece of text:
(1) Grammar. Natural language isn't typechecked, and frequently uses incomplete sentences, which makes it hard to develop grammars (context-free, context-free probabilistic, lambek-style/proofnet-style or whatever else people have come up with) for it.
(2) Anaphora resolution. "I saw a dog on the street this morning. It was barking". So who's barking, street or dog? Gramatically, both would be possible; only with prior knowledge we can see that we're talking about the dog here.
(3) Polysemy. What does "play" mean, taken by itself? It can be used for different meanings in "to play a game", "a play of words", "a terrific shakespearian play" etc.; you might want to have a look at wordnet one of these days to get a feeling for this. Not knowing which meaning an arbitrary occurence of "play" refers to means that you have to try lots of options when parsing, LSIing or whatever else you do (though most people simply ignore this problem in research today-- it's too hard to disambiguate words in practice).
That's not all, of course-- try thinking of the need to deal with irony/sarcasm, metaphors, foreign words, the credibility of whichever sources you're using etc., and you'll get a pretty good feeling for why this is beyond merely being "hard". Of course, for very small problem domains (a "command language for naval vessels" was investigated in one paper I read a while ago-- those DARPA people definitely have too much money on their hands, but I digress), this can be solved, but general-purpose open-domain NLP is what you need to do a web search.
It might happen in my lifetime, but I won't hold my breath for it.
-- Christoph
Hmm... why do we always get new expressivity features and library extensions, instead of new safety features and ways for statically checking our code (such as type checking, a novel but, admittedly, completely impractical and academic invention that only freak languages use)?
I guess because people like me prefer to complain and use other languages instead of fixing unsafe ones...
Hi,
;-)
Well, generics remind me of C++ templates
They're not quite the same; C++ templates are essentially glorified preprocessor macros with
some relatively small checking and a rather baroque
underlying functional language. Generics are more
concrete than that.
Not to mention that attached to variable name doesn't make code any more attractive to look at.
It would be really neat to have type inference there
It appears that Java's way to solve run time errors is to screw the bolts as tight a possible during compile time.
That's the idea, and that's also what I try to do when writing programs. Why should I have to write half a dozen test suites for some simple program property if the type checker can tell me whether it'll work right?
Remember: Compilers don't do type checking just to optimise, but also to catch programming errors. And Generics allow you to catch a much more interesting class of these.
-- Christoph
Yes, Generics can be used for much more than this, particularly in combination with anonymous classes (which are Java's way for handling higher-order functions). Again, a lot of examples for this can be found in existing languages, e.g. we can now have something equivalent to the 'map' function found in functional languages. Here's a Haskell definition of map:
I don't know the precise Java syntax for Generics, so I'll make one up for a Java equivalent:
Granted, it's not quite the same, particularly since it supposedly works on all containers (with the right kind of iterators) and performs a destructive update, but you get the idea-- you can do powerful stuff and still get your types right.
-- Christoph
Hi,
FYI: Generics are _much_ more than mere syntactic sugar (as are enumerators, a weak form of algebraic datatypes, if handled type-correctly).
These are actually the kinds of things that make program maintenance considerably easier, since they allow more concise specifications of intended semantics to be done. No longer having to typecast (and thus expect run-time exceptions) when using a "vector of FooObjects" gives more power to the type checker, and thus allows a much richer class of programming errors to be detected at compile-time. This is the one major improvement in Java that's been missing since its very inception.
But note that "generics" or "parametric types" have been present in languages such as Eiffel or Sather for well over a decade, and for much longer in ML. In a way, it's embarrassing that such an essential feature was added this late during development.
On the other hand, my experience and the experience of others I've seen is that dynamicly typed languages are not only more fun to program in, they produce good results faster.
;-) but that doesn't mean that we should give up on static checking-- simply because no test suite writer will ever be able to test for all the things that fall out of a static checker for free.
Hmm, my experience is slightly different. The 'fun' part is, of course, rather subjective-- I find dyanmically typed languages more frustrating, which is why I personally wouldn't agree with that, but, of course, YMMV-- but I definitely disagree about the part with "good results being produced faster".
They do produce results faster, often even reasonable results. But good results (i.e. stable code) take much longer to achieve, in my experience.
Put that the other way around -- do you want to spend the rest of your life working against strong typing systems which only detect errors that even the simplest test suite would automatically find?
I've rarely had to "work against" strong type systems in the past. Sufficiently expressive type systems are important for this to make sense, I'll admit that; it requires a certain kind of thinking to be able to make use of strong typing effectively. This restriction on "free thought" may be what people find most offensive, but I'm not sure.
Regarding test suites: It is very hard to construct (for a non-trivial program) a test suite that achieves complete code coverage (recall that you'll want to check all of your error and special case handlers). Right now, test suites are the most reasonable approach to handling properties beyond the capabilities of type systems in languages we can come up with ("Does this function terminate? Does the sequence of file system updates it performs correspond to what I want it to do?"), and they are certainly a good complement to static checkers. But they rarely test all of the relevant properties of a program; as such, the neccessity for implementing a test suite can be considered as a sign of weakness of static checking. (That doesn't mean they should be omitted if static checking fails-- that'd be dishonest.)
There are errors which no static type system or static checker will be able to find (thanks to Goedel
In conclusion, I believe that we need static typechecking, static checking in general, and test suites for everything we cannot formalise (for whichever reason) if we want to ever resolve the "software crisis". Without any of these, we'll just keep inventing more crappy code.
That's true. But you can get pretty far in practice; moreover, having the developer specify (and the prover verify) auxiliary lemmata should resolve this problem in many situations.
The downside is that programmers will have to be able to deal with programs as well as with proofs if they want to produce stable code, but I'm not really convinced that this is neccessarily a bad thing.