Indeed, static type checking cannot prove your program correct, but it can prove your program incorrect, without even running a test. If your type system is sufficiently powerful to express your intention, the type checker helps. If it is too weak, it will get in your way. The latter happens all the type in C, where the fix usually involves void and it happens in Java where the fix is spelt object and a type cast.
Where the type system is expressive enough, I never found a need to cast. Neither in Haskell, which has a polymorphic type system, nor in C++, where the template mechanism creates a sort of meta-language with weak typing used to generate a strongly typed program.
When programming in a dynamically (not really 'weakly') typed language, it encourages an "interface based" style.
As does the use of templated classes and functions in C and as does Haskell through its type classes.
in fact Rice's theorem proves no non-trivial property of programs can be proven mechanically.
Indeed. You shouldn't bother writing unit tests, after all they are a doomed attempt at mechanically proving a program correct. Even worse, the attempt of formally specifying what in correct is already doomed.
So both tools, tests and typing, are imperfect. Choose what helps the most or combine them. I see great value in a clear error message telling me the bar was not supposed to go into a container of foo, as opposed to an error telling me a bar was missing some method I meant to invoke on a foo. The alternative is to write a test case, that checks if something that goes into my container really is a foo. Which is actually the same as worrying about typing and declaring the type.
By increasing market sharing, hardware producers will start producing device drivers for new products.
I'm afraid those (binary) drivers are not such a good idea after all. If we get drivers comparable to those for legacy OSes, we get forced into the same upgrade cycle: "This driver only supports Linux 2004." Or XFree 5.0, or whatever. But our upgrade cycle is not 2 years long but rather half a year.
What really helps are open source drivers or open hardware specs. But we will never get them, if we advocate GNU/Linux to those "average users" who will cry for binary drivers because compiling themselves is so hard.
What can you do on a game console that you can't do on a formal PC?
You can code for fun. Coding on an PC has become boring. The machine ist not interesting, you have to take care to be "compatible" with all sorts of crap hardware, etc. Game consoles are interesting: powerful small processors, where coding in assembly pays, interesting graphics hardware where you can do cool effects with skill istead of brute force. It's fun.
That said, I doubt, Sony will ever release information about the interesting bits. The vector processors of the emotion engine are top secret, and so ist the graphics processor. That makes it kind of pointless.
Have you ever tried politely asking Outlook users not to misquote, to use a correct In-Reply-To header, not to send HTML, to put Re: in a subject line instead of some silliness like Aw:, etc?
I did. It is fruitless. It is tiring. "Raising the bar for entry" is less hassle, really.
Well, for starters, this HTML is crap. Physical markup, redundant tags, simply annoying. Still, I could live with this mail. What I cannot live with are the mails that say "This is an HTML message." in their plain text version.
The point (if Nick is serious) ist not arbitrarily excluding someone, but deliberately excluding who is unwilling to adapt to accepted culture. Guess what, I'm thinking about doing the same, because those malformed emails from Outlook users are annoying me on a Linux User Group mailinglist. They intrude with their non-conformant software, they get excluded. Simple, isn't it?
Now the headers by themselves are of minor amusement, the begin exploit is extremely discourteous on public mailing lists, as for digest members, it destroys the rest of the disgest - ie. it affects the posts of others.
Outlook affects the posts of others. Remember, Nicks's posts are perfectly valid.
But, it is quite clear that the agenda is bigger than that. It is that there be no closed code at all.
The point is simply that Free and proprietary code don't mix well. If you allow Free code to be used in proprietary products, it ends up non-free, some company makes money and doesn't give back to the community. Otoh, if you allow proprietary code to be used in Free software, some company invests money and the community doesn't give back.
It doesn't work out either way. Therefore, companies don't allow Free use of their code and the community should not allow non-free use of their code. Which makes the GPL exactly right.
Should some company have a need to use Mono, they should license it. For money, for some patent exchange, whatever. Two worlds, keep them separate.
Lisp (or any functional programming language) shines where you have to handle complicated data structures. Complicated probably already includes binary trees.
Said application not only involves high volumes of data, but also complex searching strategies on certainly non-trivial graphs. Well, the same done in C would probably be faster, but no one would want to write it. The C equivalent would use simpler algorithms and lose on that ground.
Slashdot Mirror
Indeed, static type checking cannot prove your program correct, but it can prove your program incorrect, without even running a test. If your type system is sufficiently powerful to express your intention, the type checker helps. If it is too weak, it will get in your way. The latter happens all the type in C, where the fix usually involves void and it happens in Java where the fix is spelt object and a type cast.
Where the type system is expressive enough, I never found a need to cast. Neither in Haskell, which has a polymorphic type system, nor in C++, where the template mechanism creates a sort of meta-language with weak typing used to generate a strongly typed program.
When programming in a dynamically (not really 'weakly') typed language, it encourages an "interface based" style.
As does the use of templated classes and functions in C and as does Haskell through its type classes.
in fact Rice's theorem proves no non-trivial property of programs can be proven mechanically.
Indeed. You shouldn't bother writing unit tests, after all they are a doomed attempt at mechanically proving a program correct. Even worse, the attempt of formally specifying what in correct is already doomed.
So both tools, tests and typing, are imperfect. Choose what helps the most or combine them. I see great value in a clear error message telling me the bar was not supposed to go into a container of foo, as opposed to an error telling me a bar was missing some method I meant to invoke on a foo. The alternative is to write a test case, that checks if something that goes into my container really is a foo. Which is actually the same as worrying about typing and declaring the type.
By increasing market sharing, hardware producers will start producing device drivers for new products.
I'm afraid those (binary) drivers are not such a good idea after all. If we get drivers comparable to those for legacy OSes, we get forced into the same upgrade cycle: "This driver only supports Linux 2004." Or XFree 5.0, or whatever. But our upgrade cycle is not 2 years long but rather half a year.
What really helps are open source drivers or open hardware specs. But we will never get them, if we advocate GNU/Linux to those "average users" who will cry for binary drivers because compiling themselves is so hard.
What can you do on a game console that you can't do on a formal PC?
You can code for fun. Coding on an PC has become boring. The machine ist not interesting, you have to take care to be "compatible" with all sorts of crap hardware, etc. Game consoles are interesting: powerful small processors, where coding in assembly pays, interesting graphics hardware where you can do cool effects with skill istead of brute force. It's fun.
That said, I doubt, Sony will ever release information about the interesting bits. The vector processors of the emotion engine are top secret, and so ist the graphics processor. That makes it kind of pointless.
Have you ever tried politely asking Outlook users not to misquote, to use a correct In-Reply-To header, not to send HTML, to put Re: in a subject line instead of some silliness like Aw:, etc?
I did. It is fruitless. It is tiring. "Raising the bar for entry" is less hassle, really.
Well, for starters, this HTML is crap. Physical markup, redundant tags, simply annoying. Still, I could live with this mail. What I cannot live with are the mails that say "This is an HTML message." in their plain text version.
When did we become such elitists?
When did we become egalitarian?
The point (if Nick is serious) ist not arbitrarily excluding someone, but deliberately excluding who is unwilling to adapt to accepted culture. Guess what, I'm thinking about doing the same, because those malformed emails from Outlook users are annoying me on a Linux User Group mailinglist. They intrude with their non-conformant software, they get excluded. Simple, isn't it?
Now the headers by themselves are of minor amusement, the begin exploit is extremely discourteous on public mailing lists, as for digest members, it destroys the rest of the disgest - ie. it affects the posts of others.
Outlook affects the posts of others. Remember, Nicks's posts are perfectly valid.
But, it is quite clear that the agenda is bigger than that. It is that there be no closed code at all.
The point is simply that Free and proprietary code don't mix well. If you allow Free code to be used in proprietary products, it ends up non-free, some company makes money and doesn't give back to the community. Otoh, if you allow proprietary code to be used in Free software, some company invests money and the community doesn't give back.
It doesn't work out either way. Therefore, companies don't allow Free use of their code and the community should not allow non-free use of their code. Which makes the GPL exactly right.
Should some company have a need to use Mono, they should license it. For money, for some patent exchange, whatever. Two worlds, keep them separate.
Lisp (or any functional programming language) shines where you have to handle complicated data structures. Complicated probably already includes binary trees.
Said application not only involves high volumes of data, but also complex searching strategies on certainly non-trivial graphs. Well, the same done in C would probably be faster, but no one would want to write it. The C equivalent would use simpler algorithms and lose on that ground.
Better yet, have a look at Berlin, not only do they already run on OpenGL, their design is also sane.