"Her assertion should not be misread to infer that she never broke school rules," the district said of Ms. Redding in a brief, "only that she was never caught."
That's known as "covering one's ass", ironically something they prevented Ms. Redding from doing.
I don't know about consumer desktops frequently cycling, but I have second or third hand knowledge that 24/7 systems running for a decade can physically crumble when turned off, due to the temperature change.
Offtopic, but it makes me feel smart to repeat trivia I heard elsewhere.
Ah, I remember my mudding days. I used a few MUSE-like servers regularly, and had a lot of fun completing various programming tasks in the textual in-game scripting language. It got to the point that I was using higher-order functions to query graphical information about the state of the game.
Makes me wish I were old enough to have been hacking around back when it was comparatively mainstream and more in-sync with the limitations of the technology of the time. Nowadays there's not much thrill in small, simple systems.
In some ways that's just a natural consequence of the fact that consoles are not modular like PCs. For all the grief hardware variety has caused PC software (including games) developers and users, it does cause consumer choice (free market, yada yada) to force the best parts to the top.
Eight replacements is a bit absurd, but if it was going to happen to any consumer electronics hardware, it'd be a 360. Microsoft has had a terrible time designing and producing it, as has been well documented over the years.
I don't know what I'm more shocked about - the idea of Sun and IBM becoming one company, or that Sun is only worth $6.5 billion. I always had the impression that they were giants.
I'd like to offer you my sympathies. I don't envy the task of any parent in the current Internet age.
Some parents are just ignorant of the social implications of the Internet until they see some scare report from the media. Others are aware of the basic threats on the net, but do a poor job of structuring the extent of their children's interactions with it. But what really gets me is when parents underestimate the value of some of their children's net usage, and overreact by "taking away the computer" or being generally closed-minded to technology.
I welcome exposing kids to the exponential browser-tab-producing effect of reading wikipedia, the life experience gained by interacting on online communities, and the critical thinking skills learned by reading/assimilating contrasting and independent viewpoints.
As you're a slashdotter, I'm in no way suggesting you fall into the above categories. I just wanted to point out that there's a lot of value and danger on the net for kids besides something as mundane as porn.
Sarcastic absolutism in the face of technical solutions? A general indifference towards children's exposure to porn? A laissez-faire parental attitude that abdicates responsibility for mediating kids' contact with the unsheltered world?
My main objection was to the notion that a design principle like the LSP could be used to call individual programs flawed in their implementation, when in fact the implementation may follow perfectly from their poor design. It strikes me as extremely presumptuous. I of course welcome flaming a designer for choosing not to follow the LSP*, but that's separate from the concept of a bug.
I'm glad we appear to agree on that.
Not having formally studied type theory yet (although we are beginning to cover it in both my graduate level Programming Languages and Compilers classes), I'm unclear in what scope you're talking about formal proofs of correctness. Do you mean we would be unable to formally prove that all programs using the base type will function correctly when instead given the derived type, which makes total sense? Because we can of course prove what we want about individual programs without much difficulty, at least in principle.
* (I get ticked off a Java for disregarding the LSP in many cases. Classes should not claim to implement an interface and then throw a NotImplemented exception at run time. Equals() should not take in an Object and then complain at run time that the argument is bad due to runtime type identification.)
Casting from a container of Derived to a container of Base should be safe. In fact I believe that's one of the forms of covariance. Did you mean the other way around, or that the language just didn't happen to support that form of covariance?
As long as we're talking about MIT people, I also like Scott Aaronson's informal writings, particularly his essay on large numbers. It's a must read for anyone with a remote interest in math, just as Feynman's "Personal Observations on the Reliability of the Shuttle" is required for engineers. (http://www.scottaaronson.com/writings/bignumbers.html)
Sure, you can write provably error-free code... but you have to solve the halting problem [wikipedia.org] first.
No, all the Halting Problem does is prevent you from writing an algorithm to prove that programs written in a Turing-complete language are error-free. This is due to Rice's Theorem, which casts a similar shadow on any other problem that tries to determine a non-trivial property of a Turing machine's language.
You can still write specialized programs in weaker non-Turing-complete languages if you badly need automated proofs of correctness. Of course, you could also eliminate the automation requirement and just have the programmer write the proof. This is much easier in declarative languages than imperative ones, with the drawback that your programmers have to be computer scientists / mathematicians.
Now some bugs are inexcusable. Divide by 0 crashes spring to mind as the most glaringly obvious inexcusable bug.
Why is everyone talking about all these obvious elementary bugs? Division by zero, integer overflow, illegal input... I haven't even heard anyone mention anything as sophisticated as a NULL pointer dereference, much less a memory deallocation problem or God forbid a race condition.
It's just that everyone around this thread is trying to have this profound discussion of fundamental software errors, yet talks like they're in a high school programming class.
The difference between the hardware failing and a two's complement number overflowing is that in the former case the software can do absolutely nothing to guard against the non-zero possibility of undefined behavior, while the latter behavior is completely predictable in principle. Whether it's easy is another matter (I would argue "Yes: Stop being a panzy";) ).
when I started, we didn't have all these libraries to link to. When we wanted a function to happen, we wrote it. And when we wrote it, we checked for overflows, underflows, error status and illegal input. We didn't rely on what few functions that already existed.
Have fun coding a modern operating system from scratch. Monolithic all-original code might work fine when you're working in tens of kilobytes, but we're in a different world now. And a different economy - why reinvent when the future (present too I guess) is about linking components together?
For those of you out there who agree with me, it probably doesn't apply to you. For those that disagree, tell me why? Why is a programming error FIXABLE but not PREVENTABLE?
It's both fixable and preventable. But at what cost? You mention SQL injection errors - that's the kind of thing that I'd be pissed off about, and maybe we can expect more from vendors on that front. But I have higher goals: entirely bug-free, provably correct code. And that's likely not attainable for most commercial software.
I disagree with your choice of who to blame. Individual developers are not ultimately responsible for the quality of the product. They are in fact only responsible to their employers, and it's wrong for you to choose whose doorstep to lay this at (why not the managers who push something out too soon and cut off project resources?).
Really, the LSP is the kernel of wisdom behind most design patterns. If you already know OO design, DPs form a nice augmenting toolbox. But you could always craft your own design for your specific situation. It may very well be that this overlaps with an existing design pattern - just further proof that you didn't need the DP to begin with.
What are you talking about? It's not a theory, it's a definition. One specific definition out of several, I would imagine. Moreover, nothing in it says "OBEY ME OR YOU'RE BUGGED"; it's a very good guideline for sensible program design, but it has nothing to do with the completely independent definition of a bug in the general sense. Of course, you can always *make* the LSP part of your design criteria so that violations of it do in fact constitute bugs for your project, but that's a different matter.
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T
If you write code to work with a Polygon reference but it fails to work with a Triangle reference, and Triangle is a subclass of Polygon, that does not indicate that you have a bug in your code. It merely indicates that Triangle, despite being a subclass, does not constitute a subtype under this definition.
If that's not good enough for you, notice that the statement is an if, not an iff (if and only if). Therefore, that sentence alone does nothing to rule out what can be a subtype of T.
Slashdot Mirror
"Her assertion should not be misread to infer that she never broke school rules," the district said of Ms. Redding in a brief, "only that she was never caught."
That's known as "covering one's ass", ironically something they prevented Ms. Redding from doing.
I don't know about consumer desktops frequently cycling, but I have second or third hand knowledge that 24/7 systems running for a decade can physically crumble when turned off, due to the temperature change.
Offtopic, but it makes me feel smart to repeat trivia I heard elsewhere.
Ah, I remember my mudding days. I used a few MUSE-like servers regularly, and had a lot of fun completing various programming tasks in the textual in-game scripting language. It got to the point that I was using higher-order functions to query graphical information about the state of the game.
Makes me wish I were old enough to have been hacking around back when it was comparatively mainstream and more in-sync with the limitations of the technology of the time. Nowadays there's not much thrill in small, simple systems.
As far as I know, psychic powers aren't a documented feature of the Cell processor.
Actually, that's not the impression I got from Sony's adverts a couple years ago. In fact, it was pretty explicitly the opposite.
In some ways that's just a natural consequence of the fact that consoles are not modular like PCs. For all the grief hardware variety has caused PC software (including games) developers and users, it does cause consumer choice (free market, yada yada) to force the best parts to the top.
Eight replacements is a bit absurd, but if it was going to happen to any consumer electronics hardware, it'd be a 360. Microsoft has had a terrible time designing and producing it, as has been well documented over the years.
Sigh.
Today I am very, very disappointed. You see, I thought I would never have to say this. But I see that I now have no choice, so here it goes.
LOL WUT
> just wait for them to erupt and the news media will monitor them for us!
Ah, another job better done by the private sector.
Problem is it's one of the more expensive drugs money can buy.
I don't know what I'm more shocked about - the idea of Sun and IBM becoming one company, or that Sun is only worth $6.5 billion. I always had the impression that they were giants.
I'd like to offer you my sympathies. I don't envy the task of any parent in the current Internet age.
Some parents are just ignorant of the social implications of the Internet until they see some scare report from the media. Others are aware of the basic threats on the net, but do a poor job of structuring the extent of their children's interactions with it. But what really gets me is when parents underestimate the value of some of their children's net usage, and overreact by "taking away the computer" or being generally closed-minded to technology.
I welcome exposing kids to the exponential browser-tab-producing effect of reading wikipedia, the life experience gained by interacting on online communities, and the critical thinking skills learned by reading/assimilating contrasting and independent viewpoints.
As you're a slashdotter, I'm in no way suggesting you fall into the above categories. I just wanted to point out that there's a lot of value and danger on the net for kids besides something as mundane as porn.
Good luck striking a balance.
Sarcastic absolutism in the face of technical solutions? A general indifference towards children's exposure to porn? A laissez-faire parental attitude that abdicates responsibility for mediating kids' contact with the unsheltered world?
Bennett Haselton, is that you?
You could've tried a less common topic, something esoteric and technical, like Python - oh, wait...
Why the hell am I being linked to a registration-required site? What is this, reddit?
My main objection was to the notion that a design principle like the LSP could be used to call individual programs flawed in their implementation, when in fact the implementation may follow perfectly from their poor design. It strikes me as extremely presumptuous. I of course welcome flaming a designer for choosing not to follow the LSP*, but that's separate from the concept of a bug.
I'm glad we appear to agree on that.
Not having formally studied type theory yet (although we are beginning to cover it in both my graduate level Programming Languages and Compilers classes), I'm unclear in what scope you're talking about formal proofs of correctness. Do you mean we would be unable to formally prove that all programs using the base type will function correctly when instead given the derived type, which makes total sense? Because we can of course prove what we want about individual programs without much difficulty, at least in principle.
* (I get ticked off a Java for disregarding the LSP in many cases. Classes should not claim to implement an interface and then throw a NotImplemented exception at run time. Equals() should not take in an Object and then complain at run time that the argument is bad due to runtime type identification.)
Casting from a container of Derived to a container of Base should be safe. In fact I believe that's one of the forms of covariance. Did you mean the other way around, or that the language just didn't happen to support that form of covariance?
Then how do you explain Michael Sipser?
As long as we're talking about MIT people, I also like Scott Aaronson's informal writings, particularly his essay on large numbers. It's a must read for anyone with a remote interest in math, just as Feynman's "Personal Observations on the Reliability of the Shuttle" is required for engineers. (http://www.scottaaronson.com/writings/bignumbers.html)
I didn't read his sig. I just saw the Bible citation and assumed it was something witty and sarcastic.
Sure, you can write provably error-free code... but you have to solve the halting problem [wikipedia.org] first.
No, all the Halting Problem does is prevent you from writing an algorithm to prove that programs written in a Turing-complete language are error-free. This is due to Rice's Theorem, which casts a similar shadow on any other problem that tries to determine a non-trivial property of a Turing machine's language.
You can still write specialized programs in weaker non-Turing-complete languages if you badly need automated proofs of correctness. Of course, you could also eliminate the automation requirement and just have the programmer write the proof. This is much easier in declarative languages than imperative ones, with the drawback that your programmers have to be computer scientists / mathematicians.
Now some bugs are inexcusable. Divide by 0 crashes spring to mind as the most glaringly obvious inexcusable bug.
Why is everyone talking about all these obvious elementary bugs? Division by zero, integer overflow, illegal input... I haven't even heard anyone mention anything as sophisticated as a NULL pointer dereference, much less a memory deallocation problem or God forbid a race condition.
It's just that everyone around this thread is trying to have this profound discussion of fundamental software errors, yet talks like they're in a high school programming class.
The difference between the hardware failing and a two's complement number overflowing is that in the former case the software can do absolutely nothing to guard against the non-zero possibility of undefined behavior, while the latter behavior is completely predictable in principle. Whether it's easy is another matter (I would argue "Yes: Stop being a panzy" ;) ).
http://xkcd.com/485/
No, Brian Greene is reliable. He's been knitting furiously since the beginning of the universe, and isn't likely to quit anytime soon.
Quantum mechanics suffers from being far more difficult to understand than a tiny man controlling reality.
when I started, we didn't have all these libraries to link to. When we wanted a function to happen, we wrote it. And when we wrote it, we checked for overflows, underflows, error status and illegal input. We didn't rely on what few functions that already existed.
Have fun coding a modern operating system from scratch. Monolithic all-original code might work fine when you're working in tens of kilobytes, but we're in a different world now. And a different economy - why reinvent when the future (present too I guess) is about linking components together?
For those of you out there who agree with me, it probably doesn't apply to you. For those that disagree, tell me why? Why is a programming error FIXABLE but not PREVENTABLE?
It's both fixable and preventable. But at what cost? You mention SQL injection errors - that's the kind of thing that I'd be pissed off about, and maybe we can expect more from vendors on that front. But I have higher goals: entirely bug-free, provably correct code. And that's likely not attainable for most commercial software.
I disagree with your choice of who to blame. Individual developers are not ultimately responsible for the quality of the product. They are in fact only responsible to their employers, and it's wrong for you to choose whose doorstep to lay this at (why not the managers who push something out too soon and cut off project resources?).
Really, the LSP is the kernel of wisdom behind most design patterns. If you already know OO design, DPs form a nice augmenting toolbox. But you could always craft your own design for your specific situation. It may very well be that this overlaps with an existing design pattern - just further proof that you didn't need the DP to begin with.
What are you talking about? It's not a theory, it's a definition. One specific definition out of several, I would imagine. Moreover, nothing in it says "OBEY ME OR YOU'RE BUGGED"; it's a very good guideline for sensible program design, but it has nothing to do with the completely independent definition of a bug in the general sense. Of course, you can always *make* the LSP part of your design criteria so that violations of it do in fact constitute bugs for your project, but that's a different matter.
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T
If you write code to work with a Polygon reference but it fails to work with a Triangle reference, and Triangle is a subclass of Polygon, that does not indicate that you have a bug in your code. It merely indicates that Triangle, despite being a subclass, does not constitute a subtype under this definition.
If that's not good enough for you, notice that the statement is an if, not an iff (if and only if). Therefore, that sentence alone does nothing to rule out what can be a subtype of T.