I think I get the basic concept of design-by-contract, but I don't really get how it's different than unit tests, or why it's superior.
Design-by-contract will in no way prevent you, or discourage you, from writing test-code (in fact, it encourages it), but it can help you spend your time writing those tests more sensibly, and drive your code in much more life-like scenarios. Yeah, interesting. How?
Most of the really tricky problems comes in the interfacing between units and no unit tests will help you here. No, then you have integration tests, and functional tests -- which are essentially higher-order unit tests.
Unit tests, strictly speaking, are only the beginning. You're also going to want functional tests, and in general, you're going to want to test everything you can, unless you have a good reason for believing it doesn't need testing -- for example, you probably don't need to test things that are built-in to the language; not only is it probably better tested than any code you could write, but there's not a lot you could do if it somehow failed.
And after a "unit" of code is written "correctly", you may not be done. You may still refactor it at some point, or rewrite it with a different algorithm, and unit tests help you do that without having to worry as much about whether you broke it. More importantly, unit tests (and functional tests) also mean that you avoid the situation where you change some completely unrelated code, and it breaks your test.
They're not going to protect you 100% of the time, but they don't have to. Any bug they catch is probably going to save you enough time to be worth it -- especially because it will catch that bug early.
And then there's test-driven design -- first write a test to describe how the system is supposed to work, and then write the code that passes that test. Here, it helps you know when you're done with that particular piece of code -- that is, it prevents you from writing too much at once.
I suppose it depends how reasonably you could actually fix the incorrect behavior, or whether it makes more sense to document it explicitly and move on. For example, I might consider it a bug that I can't easily type an apostrophe as part of a contraction in a single-quoted string, but I'm fairly sure I'm happier with the explicit, simple, and predictable behavior than any hack which would allow the compiler to always detect when a ' was meant to be quoting a string, or to be an apostrophe in a string.
Take, for example, Ubuntu's Bug #1 -- certainly undesirable behavior, but really not trivial to fix. Undocumented behavior can always at least be easily fixed by documenting it.
Good tests are a form of documentation, but I wouldn't suggest that they're an especially good one... First and foremost, they're not the easiest to read since they're code, not English (or your preferred native language). It sounds to me like you haven't used particularly good test suites. RSpec is actually very readable. It's not entirely a substitute for documentation, but it does solve the "not in English" problem.
Yeah, that's the one thing I hate about Ruby now -- seeing the end of a file that looks like this:
# for some reason, Slashdot won't indent the first line...
end
end
end
end
end end
Especially when the whole culture around things like Ruby on Rails is "Convention over Configuration" (thus, your code should always be indented properly anyway) and "Don't Repeat Yourself" (tons of 'end' statements isn't particularly DRY).
I will say one thing, though: After haml, I never want to write any raw HTML, or any XML, by hand again. Ever.
There is nothing uber or elite about breaking things out into smaller functions. It's a no-brainer -- as in, if you don't do it, you have no brain, and why are you programming in the first place?
That said, use a better text editor -- one that understands the syntax of the language you're using. % in vim will bounce between opening and closing brackets. No need to pollute the source with a workaround for a bad text editor.
Well, this is very, very rarely a problem for me, for the reasons others have said -- if I make a nesting construct that is more than, say, a single page long in my text editor, then I probably should be refactoring it.
But if it's actually braces, just bounce back and forth with % in vim. Don't add comments because your text editor doesn't know how to find the other brace.
Your CYA point is valid: Nobody got fired for choosing IBM. I mean Microsoft.
(Hint: Where's IBM now?)
And most of your analysis is right -- 5% is optimistic. What I think you're missing is the ways in which open source is actually safer.
See, open source is generally known to work -- you can find as many known-good configurations as with Windows. It's possible to pay someone to actually stand behind it -- whereas you admit it's naive to think Microsoft will stand behind their code.
And there's the additional bonus that you always have the source code, which means you're independent of any one vendor, and you have some measure of control over the direction of the project.
In simpler terms: You can always ditch one vendor for another, if something happens to that one vendor. And you can always hire someone to develop a feature for you.
Those are two things you simply cannot get with Microsoft, or with any proprietary software vendor -- if they go away, you're SOL. Take the "Save XP" petition -- this kind of thing completely baffles Linux geeks. If Ubuntu Hardy doesn't work, you can downgrade back to Feisty. Canonical may no longer support it after awhile, but if you really can't afford to upgrade, you can always find your own support.
Or, if it's just a few things wrong with Hardy, you can fix them. No need to beg Microsoft to admit that it's a bug, not a feature.
So there it is, in terms a suit would understand. The only thing dangerous about Linux is the initial switch, and the chance that there's something you need from Windows that just won't run on Linux. So fine, buy a few nice, beefy terminal servers, put some Windows VMs on them, and use those for the 10% of your business which needs them -- and I think I'm being generous there. With the other 90% on Linux, you've got 90% more 'insurance'.
I, too, live in the real world, and I realize this isn't an easy sell. But the reality is, one by one, some of these suits are learning, and bit by bit, Linux is becoming at least competent, if not excellent, for more and more tasks.
The problem is, it would have to be absolutely perfect.
Good luck with that -- I'd put better odds on being able to run the Windows VB environment under Wine than reimplementing it ourselves.
In any case, VB should be discouraged, right? I'm assuming that when you said "lock in tool", you meant that people can't switch because they have existing stuff in VB, not because anyone sane would use it for a new project.
Fine. At least that's saner than claiming C is a good language to "dash off a quick little program".
And your pet language doesn't seem to have any code samples on its page, so it fails.
Let me put it this way:
find . -name '*.svn' -exec rm -rf '{}' \;
Not really going to beat a shell for one-liners, and I've written 100-line ruby code that does what I want. You could not pay me enough to rewrite most of those in C.
Yes, but it is hard to come by the clients and servers without similar licensing restriction or TCO. How thorough are your TCO studies, and who did them? Kind of hard to estimate it anyway.
Oh, and it's easy to find clients and servers with open licenses. Things like GPL, BSD, MIT. How does that restrict you?
All of the components are there. The reason Microsoft doesn't use them is -- well, go read the Halloween documents. They are actually deliberately using proprietary standards, rather than open ones. Doesn't take a conspiracy theorist to put it together when Gates said so explicitly.
Sure, I'll replace the most important app for 1000 people with " couple of Linux projects which at least claim to support that." Because I didn't bother to do your homework for you, so my language was vague. Kontact and Evolution both have exchange adapters -- I don't know how mature they are, because I haven't looked, but only because I have no need for them. You do, so you should go look -- that's what they pay you for.
Let me put this another way: Web browsing is, more and more, an essential app. Would you consider replacing IE with Firefox? If not -- maybe you have some ActiveX shit that you can't get rid of -- was it at least a sane question?
If Firefox is a sane proposition, why isn't Evolution or Kontact?
And all of this is assuming you need it to talk to Exchange. There are several projects -- again, I'm not going to do your homework for you, but at least one with commercial support -- which will run on a Linux server, and have stable and mature Linux clients.
The reason I can't give you specifics is that I did this research at least six months to a year ago. Turned out that the boss didn't want to even risk the possibility that people would have to learn a new UI -- even if it was mostly the same UI. I'm talking about differences on the order of Firefox's keyboard shortcut for "back" being alt-left instead of backspace -- this was a problem (though now it has backspace anyway).
But it's also about less heat, which means less cooling apparatus, which means a quieter machine.
And it means less power needed from a battery, if and when you need one. (Laptops, UPS, etc.)
And that's not "shaving 5-10 watts off your GPU", it's about making a 5-10 watt GPU, if I understand the grandparent -- instead of, say, a 20-30 watt GPU. Which still isn't a lot, but a little bit here, a little bit there, and it adds up -- CPUs are getting more efficient, too.
steals power from the CPU and siphons off memory from system-level RAM. Either you know what you're talking about and are oversimplifying a lot, or you don't know at all.
If I have 2 gigs of RAM, and a game takes 1 gig, wouldn't it be better if my GPU could use the other gig? Most video cards don't come with a gig of RAM, they come with much less. And I can upgrade my system RAM -- most video cards, you only upgrade the RAM when you buy a new one.
And "steals power from the CPU"? WTF? That is physically impossible. You could say that more is done in software, because less is even supported in hardware, and that would be true. But here, nothing about it being "integrated" makes a difference -- it's simply a weak chip.
Besides, you weren't using that second core anyway. It's going to be awhile before games start to really take advantage of multicore, I suspect.
Now, there is something to be said for the performance of the RAM -- it's possible that the CPU and the GPU now have to share memory bandwidth (true also for dual-core, by the way). At the same time, it means you aren't constrained by things like an AGP or PCI-Express bus in the way. But a PCI Express bus doesn't really do much...
Still, look at consoles. From what I remember, most of them still have "integrated" hardware, and when this current generation came out, they pretty much spanked the PCs of the time.
All that said, I probably don't know much more than you, but there's a lot more going on than "siphons off ram from the system..."
Yes, I love how there are absolutely rock solid, open drivers for just about every Intel card ever made (of any kind) on Linux.
Can anyone at Intel confirm that this will be the case with the new drivers? Or will ATI beat them to it? Because more than anything else, this is what will determine my next video card purchase: Rock solid open source drivers that have all the features of the Windows drivers.
Or just include source and compilers for everything you can find. Gentoo might be a good fit for that (though not for much else).
And of course, anything you can get as a shell/interpreter. irb, python, erlang, etc.
Another possibility: Xen. Make it possible for people to load whatever they want onto a (temporary) virtual machine image. See if people start writing their own OSes...
One more, while I'm at it: Core Wars. Allows you to write bots that attack each other.
Also, depending on the policies you have to work with, check out World of Padman -- Quake 3 engine, GPL'd, violent but comical and gore-free (it's like fighting with super soakers, really). Nothing educational about it, though -- purely entertainment.
Finally: Throw up a wiki, just because. Let students start to post interesting things they've discovered. The idea is to create a sense of community, not just one teen hacking on their own.
It's amazing -- you quoted it, yet you obviously didn't read it...
My focus is the 2-year old to 8-year old range, but I'm happy to hear teen-oriented suggestions too.
Re:Media production for Linux (And OSX, And Window
on
GPL Edutainment Software
·
· Score: 2, Insightful
I'll bet they'd learn it easier than you.
That's not a slight on you, just that it's well known that kids pick up things quicker than adults. That's why "child-proof" caps really end up being adult-proof -- my parents always used to ask me to open them, as a kid.
My favorite quote was from Orson Scott Card's Lost Boys, in which some character counters statements like that by saying that within a year, nobody will think of selling a computer without at least a megabyte of storage!
Slashdot Mirror
Unit tests, strictly speaking, are only the beginning. You're also going to want functional tests, and in general, you're going to want to test everything you can, unless you have a good reason for believing it doesn't need testing -- for example, you probably don't need to test things that are built-in to the language; not only is it probably better tested than any code you could write, but there's not a lot you could do if it somehow failed.
And after a "unit" of code is written "correctly", you may not be done. You may still refactor it at some point, or rewrite it with a different algorithm, and unit tests help you do that without having to worry as much about whether you broke it. More importantly, unit tests (and functional tests) also mean that you avoid the situation where you change some completely unrelated code, and it breaks your test.
They're not going to protect you 100% of the time, but they don't have to. Any bug they catch is probably going to save you enough time to be worth it -- especially because it will catch that bug early.
And then there's test-driven design -- first write a test to describe how the system is supposed to work, and then write the code that passes that test. Here, it helps you know when you're done with that particular piece of code -- that is, it prevents you from writing too much at once.
I suppose it depends how reasonably you could actually fix the incorrect behavior, or whether it makes more sense to document it explicitly and move on. For example, I might consider it a bug that I can't easily type an apostrophe as part of a contraction in a single-quoted string, but I'm fairly sure I'm happier with the explicit, simple, and predictable behavior than any hack which would allow the compiler to always detect when a ' was meant to be quoting a string, or to be an apostrophe in a string.
Take, for example, Ubuntu's Bug #1 -- certainly undesirable behavior, but really not trivial to fix. Undocumented behavior can always at least be easily fixed by documenting it.
I will say one thing, though: After haml, I never want to write any raw HTML, or any XML, by hand again. Ever.
He should find an IDE that lets him automatically do that replacement.
And you should find a better professor. Remember, they work for you, not the other way around.
There is nothing uber or elite about breaking things out into smaller functions. It's a no-brainer -- as in, if you don't do it, you have no brain, and why are you programming in the first place?
That said, use a better text editor -- one that understands the syntax of the language you're using. % in vim will bounce between opening and closing brackets. No need to pollute the source with a workaround for a bad text editor.
Well, this is very, very rarely a problem for me, for the reasons others have said -- if I make a nesting construct that is more than, say, a single page long in my text editor, then I probably should be refactoring it.
But if it's actually braces, just bounce back and forth with % in vim. Don't add comments because your text editor doesn't know how to find the other brace.
Ah, thought I was missing something. Whoops. I see the attribution now.
Sorry about that.
Your CYA point is valid: Nobody got fired for choosing IBM. I mean Microsoft.
(Hint: Where's IBM now?)
And most of your analysis is right -- 5% is optimistic. What I think you're missing is the ways in which open source is actually safer.
See, open source is generally known to work -- you can find as many known-good configurations as with Windows. It's possible to pay someone to actually stand behind it -- whereas you admit it's naive to think Microsoft will stand behind their code.
And there's the additional bonus that you always have the source code, which means you're independent of any one vendor, and you have some measure of control over the direction of the project.
In simpler terms: You can always ditch one vendor for another, if something happens to that one vendor. And you can always hire someone to develop a feature for you.
Those are two things you simply cannot get with Microsoft, or with any proprietary software vendor -- if they go away, you're SOL. Take the "Save XP" petition -- this kind of thing completely baffles Linux geeks. If Ubuntu Hardy doesn't work, you can downgrade back to Feisty. Canonical may no longer support it after awhile, but if you really can't afford to upgrade, you can always find your own support.
Or, if it's just a few things wrong with Hardy, you can fix them. No need to beg Microsoft to admit that it's a bug, not a feature.
So there it is, in terms a suit would understand. The only thing dangerous about Linux is the initial switch, and the chance that there's something you need from Windows that just won't run on Linux. So fine, buy a few nice, beefy terminal servers, put some Windows VMs on them, and use those for the 10% of your business which needs them -- and I think I'm being generous there. With the other 90% on Linux, you've got 90% more 'insurance'.
I, too, live in the real world, and I realize this isn't an easy sell. But the reality is, one by one, some of these suits are learning, and bit by bit, Linux is becoming at least competent, if not excellent, for more and more tasks.
The problem is, it would have to be absolutely perfect.
Good luck with that -- I'd put better odds on being able to run the Windows VB environment under Wine than reimplementing it ourselves.
In any case, VB should be discouraged, right? I'm assuming that when you said "lock in tool", you meant that people can't switch because they have existing stuff in VB, not because anyone sane would use it for a new project.
Fine. At least that's saner than claiming C is a good language to "dash off a quick little program".
And your pet language doesn't seem to have any code samples on its page, so it fails.
Let me put it this way:
find . -name '*.svn' -exec rm -rf '{}' \;
Not really going to beat a shell for one-liners, and I've written 100-line ruby code that does what I want. You could not pay me enough to rewrite most of those in C.
Oh, and it's easy to find clients and servers with open licenses. Things like GPL, BSD, MIT. How does that restrict you?
There's at least one that supports Linux groupware (Kontact, Evolution), and I think there's one that supports Outlook itself.
IMAP can easily support public folders.
iCal can support shared calendars.
All of the components are there. The reason Microsoft doesn't use them is -- well, go read the Halloween documents. They are actually deliberately using proprietary standards, rather than open ones. Doesn't take a conspiracy theorist to put it together when Gates said so explicitly.
Let me put this another way: Web browsing is, more and more, an essential app. Would you consider replacing IE with Firefox? If not -- maybe you have some ActiveX shit that you can't get rid of -- was it at least a sane question?
If Firefox is a sane proposition, why isn't Evolution or Kontact?
And all of this is assuming you need it to talk to Exchange. There are several projects -- again, I'm not going to do your homework for you, but at least one with commercial support -- which will run on a Linux server, and have stable and mature Linux clients.
The reason I can't give you specifics is that I did this research at least six months to a year ago. Turned out that the boss didn't want to even risk the possibility that people would have to learn a new UI -- even if it was mostly the same UI. I'm talking about differences on the order of Firefox's keyboard shortcut for "back" being alt-left instead of backspace -- this was a problem (though now it has backspace anyway).
It's about reducing power, yes...
But it's also about less heat, which means less cooling apparatus, which means a quieter machine.
And it means less power needed from a battery, if and when you need one. (Laptops, UPS, etc.)
And that's not "shaving 5-10 watts off your GPU", it's about making a 5-10 watt GPU, if I understand the grandparent -- instead of, say, a 20-30 watt GPU. Which still isn't a lot, but a little bit here, a little bit there, and it adds up -- CPUs are getting more efficient, too.
If I have 2 gigs of RAM, and a game takes 1 gig, wouldn't it be better if my GPU could use the other gig? Most video cards don't come with a gig of RAM, they come with much less. And I can upgrade my system RAM -- most video cards, you only upgrade the RAM when you buy a new one.
And "steals power from the CPU"? WTF? That is physically impossible. You could say that more is done in software, because less is even supported in hardware, and that would be true. But here, nothing about it being "integrated" makes a difference -- it's simply a weak chip.
Besides, you weren't using that second core anyway. It's going to be awhile before games start to really take advantage of multicore, I suspect.
Now, there is something to be said for the performance of the RAM -- it's possible that the CPU and the GPU now have to share memory bandwidth (true also for dual-core, by the way). At the same time, it means you aren't constrained by things like an AGP or PCI-Express bus in the way. But a PCI Express bus doesn't really do much...
Still, look at consoles. From what I remember, most of them still have "integrated" hardware, and when this current generation came out, they pretty much spanked the PCs of the time.
All that said, I probably don't know much more than you, but there's a lot more going on than "siphons off ram from the system..."
Yes, I love how there are absolutely rock solid, open drivers for just about every Intel card ever made (of any kind) on Linux.
Can anyone at Intel confirm that this will be the case with the new drivers? Or will ATI beat them to it? Because more than anything else, this is what will determine my next video card purchase: Rock solid open source drivers that have all the features of the Windows drivers.
You did say "teen-oriented"...
Firebug, for one...
Or just include source and compilers for everything you can find. Gentoo might be a good fit for that (though not for much else).
And of course, anything you can get as a shell/interpreter. irb, python, erlang, etc.
Another possibility: Xen. Make it possible for people to load whatever they want onto a (temporary) virtual machine image. See if people start writing their own OSes...
One more, while I'm at it: Core Wars. Allows you to write bots that attack each other.
Also, depending on the policies you have to work with, check out World of Padman -- Quake 3 engine, GPL'd, violent but comical and gore-free (it's like fighting with super soakers, really). Nothing educational about it, though -- purely entertainment.
Finally: Throw up a wiki, just because. Let students start to post interesting things they've discovered. The idea is to create a sense of community, not just one teen hacking on their own.
Assuming it was a re-implementation, then it probably wasn't written in hand-coded assembly.
Otherwise, that 1 meg probably includes an Apple II emulator. Did your entire Apple II box fit into a 1 meg compressed file?
I'll bet they'd learn it easier than you.
That's not a slight on you, just that it's well known that kids pick up things quicker than adults. That's why "child-proof" caps really end up being adult-proof -- my parents always used to ask me to open them, as a kid.
Sorry, I'll get off your lawn now.
Why do you need outlook?
If it's for Exchange support, there are a couple of Linux projects which at least claim to support that.
512k should be enough for anybody!
My favorite quote was from Orson Scott Card's Lost Boys, in which some character counters statements like that by saying that within a year, nobody will think of selling a computer without at least a megabyte of storage!