Slashdot Mirror


Barbara Liskov Wins Turing Award

jonniee writes "MIT Professor Barbara Liskov has been granted the ACM's Turing Award. Liskov, the first US woman to earn a PhD in computer science, was recognized for helping make software more reliable, consistent and resistant to errors and hacking. She is only the second woman to receive the honor, which carries a $250,000 purse and is often described as the 'Nobel Prize in computing.'"

187 comments

  1. Turing test by ignishin · · Score: 5, Funny

    Does this mean she passed the turing test?

    1. Re:Turing test by MrEricSir · · Score: 5, Funny

      I hope not. MIT professors are not human.

      --
      There's no -1 for "I don't get it."
    2. Re:Turing test by dedazo · · Score: 2, Funny

      At MIT, they give the test to the professors the award to the machines. Yeeeaaahhh

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    3. Re:Turing test by Anonymous Coward · · Score: 1, Interesting

      While there's no doubting her accomplishments, I will say that my enjoyment of 6.170 was in spite of her.

    4. Re:Turing test by rockNme2349 · · Score: 4, Funny
      --
      Sewage Treatment Facilities - "Our duty is clear."
    5. Re:Turing test by Stormwatch · · Score: 3, Funny

      No, it means she is turing-complete.

    6. Re:Turing test by PylonHead · · Score: 1

      I guess that means she can halt her research now. But it's hard to say for sure. If she kept going and won it again she's be a turing-machine...

      --
      # (/.);;
      - : float -> float -> float =
    7. Re:Turing test by Bozdune · · Score: 2, Interesting

      While there's no doubting her accomplishments, I will say that my enjoyment of 6.170 was in spite of her.

      Not surprised.

      I had no use for her in 1978. She actively assisted in flunking a good friend of mine out of the PhD program. She turned down a thesis idea I had, called it "totally the wrong direction" -- and three years later a guy got a PhD and an award with the same idea at Waterloo.

      Maybe she mellowed with age, but given your comment, I guess not.

    8. Re:Turing test by Anonymous Coward · · Score: 0

      From TFA:

      Q: When you began studying computer science at Stanford, computers were big mainframes and the Internet was still in the distant future. Today, computers fit in the palm of our hands -- many are much smaller -- and the Internet is ubiquitous. Given that you have watched these transformations over the last five decades from a front-row seat, what do you think the next half-century will hold?

      A: I don't have a crystal ball! It seems obvious that computers and the Internet will continue to be very important to individuals, companies and society. But I don't know the exact form this will take.

      I think I like this lady. Not the typical pontificating blowhard one might expect.

  2. Good for her... by Em+Emalb · · Score: 4, Funny

    I bet she has some stories from "the old days" of being about the only female geek around.

    Good for her.

    --
    Sent from your iPad.
    1. Re:Good for her... by Anonymous Coward · · Score: 0

      "She" sure as hell didn't win this award for her looks.

    2. Re:Good for her... by saiha · · Score: 3, Funny

      Yeah, there are like twice as many now.

    3. Re:Good for her... by Anonymous Coward · · Score: 0

      Yeah, there are like twice as many now.

      What? You mean there's actually an entire woman in the field now?

    4. Re:Good for her... by geekoid · · Score: 1

      There weren't in geeks in those days, just nerds.

      In technology, there were certianly circus geeks.

      And that 'comic book' guy? he was a dork.
      But there wasn't the market to have a geek in the way we think of it now.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    5. Re:Good for her... by NightFears · · Score: 1

      Barbara Liskov and your sister?

  3. Purses and wallets? by interkin3tic · · Score: 4, Funny

    She is only the second woman to receive the honor, which carries a $250,000 purse and is often described as the 'Nobel Prize in computing

    Did they give $250,000 wallets to the men who won previously?

    1. Re:Purses and wallets? by CaptainPatent · · Score: 4, Funny

      No, they're just bragging about the luxurious accessories the award lugs around all day.

      --
      Well, back to rejecting software patent applications.
    2. Re:Purses and wallets? by morgan_greywolf · · Score: 1

      Well, if it isn't Italian leather and made by Gucci, they certainly got ripped off.

    3. Re:Purses and wallets? by cthulu_mt · · Score: 1

      Horses also win purses. I hope this is not a commentary on her appearance.

      --
      Virginia is for lovers. EVE is for griefers.
    4. Re:Purses and wallets? by Anonymous Coward · · Score: 0

      Yea, it's more like an insult to the horses.

    5. Re:Purses and wallets? by Anonymous Coward · · Score: 0

      I would've held out for Corinthian leather.

    6. Re:Purses and wallets? by Anonymous Coward · · Score: 0

      Did the men win $312,500 wallets?

    7. Re:Purses and wallets? by Anonymous Coward · · Score: 0

      She is only the second woman to receive the honor, which carries a $250,000 purse and is often described as the 'Nobel Prize in computing

      Did they give $250,000 wallets to the men who won previously?

      nice pick!!!

  4. Her biggest achievement by Anonymous Coward · · Score: 0

    She was the chief architect for Internet Explorer.

  5. So does that mean... by Chris+Mattern · · Score: 2, Funny

    ...we can't tell her apart from a computer over a teletype link?

    No, wait...

  6. Relations all the way down by Baldrson · · Score: 3, Informative
    Liskov says: "Today the field is on a very sound foundation."

    If only it were true.

    I recall, in fact, the point in time when I first ran across Liskov's CLU in the context of working one of the first commercial distributed computing environments for the mass market, VIEWTRON, and determining the real problem with distributed programming was finding an appropriate relational formalism.

    We're still struggling with the object-relational impedance mismatch today. The closest we are to finding a "solid basis" for computer science is a general field of philosophy called "structural realism" which attempts to find the proper roles of relations vs relata in creating our models of the world.

    If anything, our descriptions should be "relations all the way down" unless we can find a good way, as some are attempting, to finally unify the two concepts as conjugates of one another.

    1. Re:Relations all the way down by Anonymous Coward · · Score: 0

      I didn't understand a word of that and I currently study for my bachelor's degree (though still on the first half of it).

      Should I be worried? Y/N

    2. Re:Relations all the way down by Anonymous Coward · · Score: 0

      No, the gp was pretty much garbage.

    3. Re:Relations all the way down by Anonymous Coward · · Score: 0

      [fancy, $3 words omitted]

      Is that just a fancy way of saying, "She's got boobies!"

    4. Re:Relations all the way down by Anonymous Coward · · Score: 0

      Is this the blowhard's way of saying that if computer science were bridge building we'd still be chucking large rocks for stepping stones into the middle of the river hoping they don't wash away?

    5. Re:Relations all the way down by Baldrson · · Score: 1

      If this "blowhard" didn't care about getting CS out that condition.

    6. Re:Relations all the way down by Charan · · Score: 1

      We're still struggling with the object-relational impedance mismatch today. The closest we are to finding a "solid basis" for computer science is a general field of philosophy called "structural realism" which attempts to find the proper roles of relations vs relata in creating our models of the world.

      If your biggest problem is how to represent objects in a relational database, I'd say the foundation is solid enough.

      More broadly, your problem is that we don't know exactly what we should be modeling with our computers, not questioning whether computers are capable of modeling it. That's progress.

    7. Re:Relations all the way down by Anonymous Coward · · Score: 0

      We're still struggling with the object-relational impedance mismatch today. The closest we are to finding a "solid basis" for computer science is a general field of philosophy called "structural realism" which attempts to find the proper roles of relations vs relata in creating our models of the world.

      Wow, I mean... Wow... Do you actually talk like that to other people, or do you just go from forum to forum impressing the local indigenous nerd-population with your pseudo-intellectual jibber-jabber.

      I mean, imagine talk like this in a professional environment. Your manager would be expecting you to come in any day with an excuse like "I'm sorry we missed the deadline, the code was having an existential crisis".

    8. Re:Relations all the way down by Baldrson · · Score: 1
      Boy, I guess you really got my number there because one day I said:

      Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

      and you know what the damn boss said?

      "You're fired."

      Here I thought he'd be impressed...

  7. Coincidentally by counterplex · · Score: 5, Informative
    I happen to have a printout of an article on "The Liskov Substitution Principle" and was wondering just yesterday how it is that as programmers we use these principles in everyday life yet don't know their names or the stories of how they came about. As the first US woman to earn a PhD in CS, I'm sure there are some interesting stories to tell about it.

    For those who might not have her original text handy, the Liskov Substitution Principle states (rather obviously):

    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

    which, when stated in the words of Robert "Uncle Bob" Martin as something we probably all intuitively understand from our daily work, is:

    Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

    --
    $x = ($x * 10) % 10 >= 5 ? 1 + int $x : int $x
    1. Re:Coincidentally by ranjix · · Score: 1

      the "behavior" should not change, or the results? if we can't change the "behavior" in subclasses, then I guess we're not allowed to overwrite methods (behavior) either.

      --
      I had another sig before, but this one is better
    2. Re:Coincidentally by shutdown+-p+now · · Score: 3, Insightful

      I happen to have a printout of an article on "The Liskov Substitution Principle" and was wondering just yesterday how it is that as programmers we use these principles in everyday life yet don't know their names or the stories of how they came about.

      To be honest, I would consider anyone who does not know what LSP is, to be OO-ignorant, even if (s)he does code in an OO language. It is a very fundamental rule, much more important that all the fancy design patterns. I guess it's possible to "invent" it on your own, just as it's possible to normalize databases without remembering, or even knowing about the strict NF definitions, but in either case, chances are high you'll get it wrong eventually.

    3. Re:Coincidentally by Workaphobia · · Score: 1

      I love the substitution principle. I don't understand the extent of her contributions to the field: particularly, how novel they were and what the world of computer science would be like today if she never existed. Anyone care to enlighten me?

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    4. Re:Coincidentally by Workaphobia · · Score: 1

      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.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    5. Re:Coincidentally by shutdown+-p+now · · Score: 2, Insightful

      On a side note... I remember a lot of people complaining about how Java 5 generics were oh-so-unobvious and hard when it came to lower and upper bounds etc. Meanwhile, the topic "why can't I cast List to List - this must be broken!" is recurring on microsoft.public.dotnet.languages.csharp probably about every two weeks. Both cases are absolutely trivial when one understands and carefully applies LSP to the problem.

      Which, I guess, just shows that many Java and .NET programmers don't really understand the theory behind their tools, even when it's directly applicable to the code they write every day. Sad...

    6. Re:Coincidentally by Estanislao+Mart�nez · · Score: 1

      Meanwhile, the topic "why can't I cast List to List - this must be broken!" is recurring on microsoft.public.dotnet.languages.csharp probably about every two weeks.

      Did Slashdot swallow your angle brackets?

    7. Re:Coincidentally by shutdown+-p+now · · Score: 2, Informative

      Yes, of course... I hate this thing. It should have been List<Derived> to List<Base>, of course.

      The even sadder part of the story is that Java 5 allows the cast because of type erasure (with a warning, but still...).

    8. Re:Coincidentally by Raenex · · Score: 1

      (s)he

      This just sucks. How do you even pronounce that when reading aloud? Singulary they" sounds so much more natural.

    9. Re:Coincidentally by Workaphobia · · Score: 1

      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?

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    10. Re:Coincidentally by Estanislao+Mart�nez · · Score: 2, Informative

      Casting from a container of Derived to a container of Base should be safe.

      Not if your container supports an operation to add elements to the collection. If you could do that cast, you could cast the Container of Derived to Container of Base and add an arbitrary element of type Base, but not of type Derived.

      More generally, if X(Y) is a type parametrized over Y, and Z is a subtype of Y, then asserting that X(Z) is a subtype of X(Y) fails, because X might have an operation that takes an argument of the parameter type.

    11. Re:Coincidentally by shutdown+-p+now · · Score: 2, Informative

      class Base { }
      class Derived1 : Base { }
      class Derived2 : Base { }
       
      List<Derived1> derived1List = new List<Derived1>();
      List<Base> baseList = derived1List; // you may think that it is okay ...
      baseList.Add(new Derived2());
      Derived1 derived1 = derivedList[0]; // ... up until this moment

      The correct way to handle this sort of thing is covariance (and contravariance) at point of use, not at point of type declaration. So you declare a method as taking "a List where T is derived from Base" - and now you can pass List to it, and within the body of the method, you can call operator[] (since it's covariant), but you cannot call Add(Base), since it's not. Java 5 wildcards "? extends T" and "? super T" cover this ground, for covariance and contravariance, respectively

      Eiffel falls into this trap, by the way - it makes all generic types covariant with respect to type parameters without any restrictions. The above code (or rather its Eiffel analog) will compile, but at run-time, the behavior is essentially undefined - it will usually raise an exception for non-primitive types at element insertion, but for primitive types it doesn't even bother to check, so you can insert a REAL into an ARRAYED_LIST{INTEGER} (since both types derive from NUMERIC), and will silently get garbage. Ouch!

    12. Re:Coincidentally by ChunderDownunder · · Score: 2, Interesting

      I survived 8 years as a OO programmer without hearing this term. Even then, only as a question on a recruitment agency test.

      So either I went to the wrong university, and consistently the wrong employers, or it's one of those self-evident principles that just didn't have a name before Barbara turned up.

    13. Re:Coincidentally by shutdown+-p+now · · Score: 4, Insightful

      So either I went to the wrong university, and consistently the wrong employers

      Employers aren't there to teach you these things, and a lot don't care so long as you crank out code that mostly works (and, let's face it, it's not always easy to tell for them, and the concepts of "formal correctness" and "readability" and "maintainability" are often not even on their radar, unless a developer brings that up). And as for university - it may well be. If they had an OOD design course and never mentioned it, or at least described it in a formal way, then they wasted your time.

      Of course, it had somehow become an established norm that "object-oriented design" course in the uni is basically just applied Java programming; from what I've seen, the best you can expect from a typical graduate when it comes to OOD theory is to be able to recite "encapsulation, inheritance, polymorphism" when asked what OO even is. It's especially ironic as only one of those three is actually a required ingredient, and even that is wrongly named. The very notion of MI gets people educated that way thoroughly confused when they first meet it, and you can forget about multimethods...

      or it's one of those self-evident principles that just didn't have a name before Barbara turned up.

      It was formulated by her in 1987. Unless your 8 years were mostly in Simula or Smalltalk, it did have a name by the time you've started working with OO. Definitely so if you've been doing Java or .NET.

      As for self-evidence... I sort of wish it was, and it really is very simple conceptually, but the fact that so many people still get it wrong over and over again shows that, apparently, it's not all that self-evident for your typical coder.

    14. Re:Coincidentally by Anonymous Coward · · Score: 0

      I happen to have a printout of an article on "The Liskov Substitution Principle" and was wondering just yesterday how it is that as programmers we use these principles in everyday life yet don't know their names or the stories of how they came about. As the first US woman to earn a PhD in CS, I'm sure there are some interesting stories to tell about it.

      For those who might not have her original text handy, the Liskov Substitution Principle states (rather obviously):

      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

      which, when stated in the words of Robert "Uncle Bob" Martin as something we probably all intuitively understand from our daily work, is:

      Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

      in one word polymorphism

  8. 1968 by MoellerPlesset2 · · Score: 4, Informative

    Since it's not in the article, I looked it up. She got her PhD in 1968.

    I initially thought that kind of sucked (Cambridge's 'Diploma in Computer Science' has been awarded since 1954), but apparently the first US PhD in CS named as such was in 1965 (University of Pennsylvania).

    The field could still use more women though.

    1. Re:1968 by UnknownSoldier · · Score: 2, Insightful

      > The field could still use more women though.

      Why?

      Do you complain that we need more pregnant men also?

    2. Re:1968 by MoellerPlesset2 · · Score: 5, Insightful

      Why? Do you complain that we need more pregnant men also?

      Men aren't capable of becoming pregnant. I however, happen to believe women are just as capable of being good computer scientists as men are.
      The fact that only a small minority of computer scientists are women, means that upwards of half our best CS talent is going to waste.

      I think that's a pity.

    3. Re:1968 by pjt33 · · Score: 1

      Cambridge's 'Diploma in Computer Science' has been awarded since 1954

      It would be more accurate to say "was first awarded in..." because they recently shut it down after years of trying without much success to keep up the numbers.

    4. Re:1968 by drewvr6 · · Score: 1

      "I" could use more women. But I don't see any government agency offering awards to subsidize that area. But good for her for getting the recognition she deserves.

      --
      Now we see the violence inherent in the system.
    5. Re:1968 by geekoid · · Score: 2, Insightful

      "The field could still use more women though."

      Why?
      Not that there shouldn't, but you are blindly stating something without any argument.
      WHat does a women bring that a man doesn? or vise versa?

      When we can determine that, then maybe we can find out why the field continues to attracts so few women. Even in the presence of programs that push very hard to get door open and to give women priority in the education there just aren't a lot of women.

      I am genuinely interested in why?
      Yhe more I think about it, the more I wonder if it is the type of work.

      Hey mods:
      There is a difference between genuinely wondering why a disparity exists(as I am) then sexism or bigotry.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    6. Re:1968 by davidsyes · · Score: 1

      http://www.malepregnancy.com/

      http://www.cbsnews.com/video/watch/?id=4234033n

      Barbara Walters Exclusive: Pregnant Man Expecting Second Child
      http://abcnews.go.com/Health/Story?id=6244878&page=1

      Was yours a pregnant assumption? (Disclaimer: i am willing to be open that the above links may be hoaxes...)

      --
      Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
    7. Re:1968 by CrimsonAvenger · · Score: 1, Troll

      The fact that only a small minority of computer scientists are women, means that upwards of half our best CS talent is going to waste.

      Either that, or most of our women are much too sensible to waste time in a field like CS.

      In other words, just because you think a field is important, doesn't imply that everyone agrees with you.

      --

      "I do not agree with what you say, but I will defend to the death your right to say it"
    8. Re:1968 by Briareos · · Score: 1

      (Disclaimer: i am willing to be open that the above links may be hoaxes...)

      *cough cough*

      np: 808 State - Goa (808 Archives Part IV)

      --

      "I'm not anti-anything, I'm anti-everything, it fits better." - Sole

    9. Re:1968 by Kerrigann · · Score: 2, Insightful

      I don't know why in recent times there is such a disparity of men and women in C.S., but I imagine your attitude might have something to do with it...

      I really don't know how to respond to this... you're either trying to be funny (but got modded +3 insightful), or are seriously trying to imply that a woman who's good at C.S. is as much of a freak as a pregnant man.

      All of a sudden I feel very alone in this field.

    10. Re:1968 by turing_m · · Score: 4, Funny

      Why?

      Just a guess, but maybe his tastes don't lean towards guys with beards and questionable personal hygiene.

      --
      If I have seen further it is by stealing the Intellectual Property of giants.
    11. Re:1968 by Anonymous Coward · · Score: 0

      Your beliefs mean nothing.

      Reality, with empirical evidence, contradicts your precious "beliefs."

    12. Re:1968 by UnknownSoldier · · Score: 2, Interesting

      > you're either trying to be funny (but got modded +3 insightful), or are seriously trying to imply that a woman who's good at C.S. is as much of a freak as a pregnant man.

      Try neither. I had no emoticon, and I had no implications -- I just asked a simple question, in order to why find out where this assumption is coming from.

      I have seen this slippery-slope type of Political Censorship before and all it does is lead to reverse discrimination. Replace Women with Ethnic / Religion / X of your choice.

      This completely focuses on the wrong problem by making a problem where one doesn't exist. The gender of a Computer Scientist doesn't fucking matter -- the only things that do are...
        a) Are they competent? How well do they know their doman? How well can they solve problems?
        b) How professional are they when interacting with
              i) colleagues?
              ii) the layman?

      A better question to ask is "How effective are we teaching computer scientists?"

      I still have never seen a good answer to this question.

    13. Re:1968 by UnknownSoldier · · Score: 1

      > happen to believe women are just as capable of being good computer scientists as men are.

      Of course they can, that's not the point.

      The question why does it matter what percentage the gender is split?

      > means that upwards of half our best CS talent is going to waste.

      That's an assumption, and have yet to see any stats to back that up in _any_ field.

    14. Re:1968 by Charan · · Score: 2, Insightful

      WHat does a women bring that a man doesn? or vise versa?

      A different perspective. And maybe a less-confrontational attitude.

    15. Re:1968 by Lunzo · · Score: 3, Interesting

      The field could still use more women though.

      Better rhetorical questions:
      * Do you complain we need more male nurses?
      * Do you complain we need more male teachers?
      * Do you complain we need more female garbage collectors?

      Gender equality is not the same as having a 50/50 male/female split in every field.

    16. Re:1968 by RightSaidFred99 · · Score: 0, Offtopic

      Ahh yes. The "different perspective" argument. Yeah, I had to take that class too. The one where diversity really helps us all because we get "different perspectives".

      You, however, seem to have taken that claptrap seriously. You get "different perspectives" in computing because two people have different backgrounds and interests, not because of skin color differences or hormonal/chromosomal differences.

      If I'm running a hip marketing company or writing sitcoms you bet your ass I want men and women, and people of different races. Writing software - those things are meaningless.

    17. Re:1968 by JoCat · · Score: 1

      I have no issue with women in computer science. Quite the contrary, I'd like to see more. However, I'd like to see more women who are in the field because they enjoy it, not because of awards/grants/bribes to pull them in for the sole purpose of 'more women in cs'.

    18. Re:1968 by nacturation · · Score: 1

      The fact that only a small minority of computer scientists are women, means that upwards of half our best CS talent is going to waste.

      I think that's a pity.

      Is it a pity that upwards of half of our best nail salon talent is going to waste as well?

      --
      Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
    19. Re:1968 by zombie_monkey · · Score: 1

      >Gender equality is not the same as having a 50/50 male/female split in every field.

      I think it is you who should explain why anything but a 50/50 split would be natural.

    20. Re:1968 by Jedi+Alec · · Score: 1

      I think it is you who should explain why anything but a 50/50 split would be natural.

      There are some things women are better at than men, and vice versa?

      --

      People replying to my sig annoy me. That's why I change it all the time.
    21. Re:1968 by Kerrigann · · Score: 1

      I don't think that wishing there were more women in C.S. is "Political Censorship". There *used* to be a higher percentage of women in C.S., and there are higher percentages of women in other equally technical fields.

      Either women are somehow biologically inferior to men in C.S., or upwards of half of our C.S. talent is going to waste. You don't find this to be a problem?

      I guess if you think that we have too many Computer Scientists as it is that's one thing... or if women just tend to migrate to other technical fields and the whole equation balances itself out. I just think that the world would be better without such artificial cultural barriers.

      Maybe I'm biased because I am a woman in a C.S. career. I've also never worked directly with any other woman since I got out of college. Just saying I was lonely, I guess.

    22. Re:1968 by steelfood · · Score: 1

      WHat does a women bring that a man doesn?

      Eye candy.

      --
      "If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
  9. Goddamn media by Anonymous Coward · · Score: 0

    Liskov, [...] was recognized for helping make software more reliable, consistent and resistant to errors and hacking.

    Who would want to make their software resistant to hacking? Let me guess: she worked on OpenOffice on behalf of Sun Microsystems.

    Patronising git will miss irony of the above and correct me on the media meaning of 'hacking' in three... two... one...

  10. making software more reliable? by erroneus · · Score: 3, Interesting

    Software is ALWAYS reliable. It is the code that people write that sucks.

    I don't know how many people come from the "old school" of programming, but 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.

    Most fatal program flaws are ridiculously easy to prevent, but bad programming habits prevail and short of creating some human language interpreter that writes code as it should be written, nothing will replace lazy programmers who trust library functions too much. And yes, I know about deadlines and not having time to waste and all that stuff. But there is something most people are also missing -- pride! I know that when I do something, I am putting my name on it whether it is directly or otherwise. And if my name gets associated with something, I make damned sure that it works and is of good quality. With the stuff that goes out these days (especially SQL injection?! PLEASE! What could be more fundamental than screening out acquired text data for illegal characters and lengths?!) it is clear that pride in one's own work is not something that commonly exists.

    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?

    1. Re:making software more reliable? by Anonymous Coward · · Score: 5, Insightful

      Software is ALWAYS reliable. It is the code that people write that sucks.

      No, computers are reliable. They'll do exactly what you tell them to do. Software, however, sucks, since it is simply a representation of the code that people write, which also sucks.

    2. Re:making software more reliable? by ChienAndalu · · Score: 5, Funny

      No, electrons are reliable. They'll do what you tell them to do. Hardware engineers however design crappy hardware.

    3. Re:making software more reliable? by morgan_greywolf · · Score: 2, Insightful

      but when I started, we didn't have all these libraries to link to. When we wanted a function to happen, we wrote it.

      Functions? Back when I started, we didn't have functions. We had jump instructions.

      You kids and your newfangled 'functions' and 'libraries'. Now get off my lawn!

    4. Re:making software more reliable? by Colonel+Korn · · Score: 3, Interesting

      No, quantum mechanics is reliable. It defines physical uncertainties in a robust way. Electrons suffer from crappy positional and momentum certainty.

      --
      "I zero-index my hamsters" - Willtor (147206)
    5. Re:making software more reliable? by wakingrufus · · Score: 1

      well, actually, electrons aren't so reliable:
      http://en.wikipedia.org/wiki/Electron#Quantum_mechanics_2

    6. Re:making software more reliable? by oldhack · · Score: 1
      Having a nice day? Or are you always like this?

      If you run your own shop, you'd already have some hints as to why things are the way they are. If you're salaried, ask your boss.

      --
      Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    7. Re:making software more reliable? by Ardeaem · · Score: 4, Funny

      No, electrons are reliable. They'll do what you tell them to do.

      I, for one, am never sure quite what my electrons are doing. After that Heisenberg guy, they've been a bit flaky...

    8. Re:making software more reliable? by Ardeaem · · Score: 2, Interesting

      Functions? Back when I started, we didn't have functions. We had jump instructions.

      When I first learned to program as a kid, I taught myself how to write pseudo-functions using goto. I looked back at those programs a few years later, and they were completely unreadable. Now, my wife does a little programming on the side (we're both researchers) and she loves goto. I keep trying to tell her NOT TO USE GOTO, but she never listens. It's painful to read her code. I think we might need counseling for this...

    9. Re:making software more reliable? by n3tcat · · Score: 1

      As with all things, pride comes at a cost. If it's worth it to you to "finish" fewer projects at the expense of less $dollars, good for you. I'm with you on that one. But I totally respect anyone elses decision to go balls to the wall and ignore all proper coding technique so they can Get The Job Done and get paid. Especially with teh current economic climate.

    10. Re:making software more reliable? by Anonymous Coward · · Score: 0

      Most fatal program flaws are ridiculously easy to prevent, but bad programming habits prevail and short of creating some human language interpreter that writes code as it should be written, nothing will replace lazy programmers who trust library functions too much.

      Only trust libraries as far as they are guaranteed to work. If you can't confirm that a library function will work in the way you intend to use it then don't use it. Yes, I'm saying that we need to use contracts and specifications. If nothing else, it assigns blame where it is due. You break the contract, you get the blame. I'm not asking for machine-checkable certifications of library code (although that would be most welcome). Any sort of consistent standard for interface specification would be a huge step forward at this point. I'm not going to assume that a library does sensible input validation until I get it in writing.

    11. Re:making software more reliable? by AuMatar · · Score: 1

      Eh, I know exactly where my electrons are. I just have no clue where they're going.

      --
      I still have more fans than freaks. WTF is wrong with you people?
    12. Re:making software more reliable? by Anonymous Coward · · Score: 0

      Yes clearly the biggest problem is that people are too good at using existing libraries, and should reinvent everything because that would be alot more stable. Sigh, there is a whole subject on that kind of thinking here; http://en.wikipedia.org/wiki/Not_Invented_Here

      Its the absolute opposite. The biggest problem is that people are NOT using existing libraries enough. Your halfassed reinventions are not going to be any safer or faster.

      I make good use of existing libraries. I go through the extra steps and make sure that no function I write will ever break for any input. Not hard, just a bit tedious at times and judging from the code from other projects i see that barely nothing can handle bad input, so it's not that common practice unfortunally. People suck.

    13. Re:making software more reliable? by AdamTrace · · Score: 1

      "And when we wrote it, we checked for overflows, underflows, error status and illegal input."

      And you also wrote bugs that you didn't immediately realize you were creating.

      Not all bugs are due to laziness. Sometimes people make mistakes, or misunderstand requirements, or the operating parameters change, or, or, or...

    14. Re:making software more reliable? by Anonymous Coward · · Score: 0

      Functions? Back when I started, we didn't have functions. We had jump instructions.

      When I first learned to program as a kid, I taught myself how to write pseudo-functions using goto. I looked back at those programs a few years later, and they were completely unreadable. Now, my wife does a little programming on the side (we're both researchers) and she loves goto. I keep trying to tell her NOT TO USE GOTO, but she never listens. It's painful to read her code. I think we might need counseling for this...

      She's a woman. Fully known, fully explainable, and able to be followed at every step from start to finish threatens her control. Over you and over the programs.

    15. Re:making software more reliable? by Chibi+Merrow · · Score: 2, Insightful

      I don't know how many people come from the "old school" of programming, but 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.

      That's great. Now that you guys built up the roads, bridges, and traffic lights... The rest of us are interested in actually using them to GET SOMEWHERE.

      Rewriting OpenGL, a scene graph, network interface code, XML Readers, etc, etc, etc. for each project would only lead to increasing the amount of buggy code in existence and no actual work getting done. We really should be past reinventing the square wheel...

      Seriously, you've gone beyond the stereotypical "In my day..." old coot bullshit and straight into loony "uphill both ways in a snowstorm" territory. Using library functions instead of writing your own isn't any different than using power tools over hand tools, the quality of the result has to do with the person using them, not how easy the tools are to use. And while something built by hand may *seem* nicer, the difference in the end doesn't really matter--and you're able to get a hell of a lot more done with modern tools.

      --
      Maxim: People cannot follow directions.
      Increases in truth directly with the length of time spent explaining them
    16. Re:making software more reliable? by oGMo · · Score: 1

      Software is ALWAYS reliable. It is the code that people write that sucks.

      Yeah right. Even a simple ADD instruction will give the wrong result when the hardware fails. And hardware will fail.

      Software isn't "reliable, but." It's only as reliable as it can be. "Those damn kids and their fancy functions" isn't the problem. The problem is fundamental complexity; no magic wand will make that go away.

      For those that disagree, tell me why? Why is a programming error FIXABLE but not PREVENTABLE?

      Sure, you can write provably error-free code... but you have to solve the halting problem first.

      --

      Don't think of it as a flame---it's more like an argument that does 3d6 fire damage

    17. Re:making software more reliable? by erroneus · · Score: 1

      You must not be terribly familiar with some of the nasty exploits that affected numerous programs because they all used the same faulty library eh? This goes for Linux/Unix as well as Windows.

    18. Re:making software more reliable? by geekoid · · Score: 1

      Becasue the spec wasn't written well.

      I'm tlaking about millions of lines here. Software that effectivly gets the [programmers compartmentalized becasue no human can track everything everyone is doing at the same time.
      So a poorly defined document dictating the layers is a bug waiting to happen.

      Now some bugs are inexcusable. Divide by 0 crashes spring to mind as the most glaringly obvious inexcusable bug.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    19. Re:making software more reliable? by geekoid · · Score: 1

      Make here debug here own code, keep your hands off.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    20. Re:making software more reliable? by rkit · · Score: 1

      ... but bad programming habits prevail ...

      as promptly demonstrated by the following rant:

      PLEASE! What could be more fundamental than screening out acquired text data for illegal characters and lengths?!

      Answer: usage of prepared statements.

      --
      sig intentionally left blank
    21. Re:making software more reliable? by davidsyes · · Score: 1

      What, no "if then, else" in the way of "pre-else-tuals"? hehehe

      --
      Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
    22. Re:making software more reliable? by iminplaya · · Score: 3, Funny

      No, quantum mechanics is reliable. It defines physical uncertainties in a robust way.

      Only when you're watching. Behind your back it's complete chaos.

      --
      What?
    23. Re:making software more reliable? by jc42 · · Score: 1, Informative

      Even a simple ADD instruction will give the wrong result when the hardware fails.

      True, but the reality is much worse than that. A simple ADD instruction will also give a wrong result, on all current "popular" CPUs, when the hardware is working exactly as designed.

      To the people who design CPUs, adding two positive integers and getting a negative result is exactly what the hardware should do in some cases, depending on the values of the integers. This wreaks havoc with software designs that assume the mathematical definition of integer addition.

      Yes, I know that the hardware also sets an overflow flag bit somewhere to indicate that the result isn't (mathematically) correct. But the implementations of most programming languages, including all the common ones, knowingly and intentionally hides the overflow flag from the software. If you pick up a few of the top-selling programming-language texts, and look through the index for information on how the language handles things like integer overflows, you typically won't find any mention of it. The people working at "higher" levels can't be bothered with such mundane details.

      They get away with all this because the people paying money for the computer systems and the software aren't generally willing to pay for hardware or software that always produces correct results. Programmers who insist on such correctness tend to find themselves shuffled off to the side or laid off, in favor of programmers who can write software to management's release schedules.

      This is all hardly a secret. People have learned that you don't have to be secretive about how crappy most software (or hardware) is, because the people in positions to control purchasing don't read the technical literature and don't particularly care about such geeky stuff as overflow bits. So we can talk about it all we like amongst ourselves; it makes no difference to the people signing the purchase orders and paying our salaries.

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    24. Re:making software more reliable? by spacefiddle · · Score: 1

      I'm not too certain where they've really been, either...

    25. Re:making software more reliable? by spacefiddle · · Score: 2, Funny

      Now get off my lawn!

      10 PRINT LAWN
      20 GOTO CURB

    26. Re:making software more reliable? by spacefiddle · · Score: 1

      Even a simple ADD instruction

      10 POKE RITALIN
      20 GOTO WHEEE

      ... i'll get me coat.

    27. Re:making software more reliable? by Anonymous Coward · · Score: 0

      ...which is why this ``was recognized for helping make software more reliable, consistent and resistant to errors and hacking'' is funny, 'cause it seems she failed in things she's recognized for.

    28. Re:making software more reliable? by Anonymous Coward · · Score: 0

      No, electrons are reliable. They'll do what you tell them to do.

      I, for one, am never sure quite what my electrons are doing. After that Heisenberg guy, they've been a bit flaky...

      What if you program a machine to go back in time and prevent Heisenberg from promulgating his theory?

    29. Re:making software more reliable? by Workaphobia · · Score: 1

      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?).

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    30. Re:making software more reliable? by Workaphobia · · Score: 2, Funny

      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.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    31. Re:making software more reliable? by Workaphobia · · Score: 1

      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" ;) ).

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    32. Re:making software more reliable? by Workaphobia · · Score: 2, Insightful

      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.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    33. Re:making software more reliable? by Workaphobia · · Score: 1

      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.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    34. Re:making software more reliable? by torroid · · Score: 1

      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.

      It's turtles all the way down.

    35. Re:making software more reliable? by jc42 · · Score: 1

      Whether it's easy is another matter (I would argue "Yes: Stop being a panzy" ;) ).

      Is a panzy someone who drives a Panzer? ;-)

      Anyway, I found it sorta fun to argue on that side of the issue, since my usual "devil's advocate" approach is to argue in favor of C, which provides no checking of anything, but supplies the low-level bit/byte access that lets me easily program my own checking. That way, my code doesn't need to check data that is provably within range. This makes the code faster than in most other languages, which check (almost) everything whether it's logically necessary or not.

      Thus, if x's value just came from x = y & 0xF, and the array z has a size > 16, it's not necessary to check z[x]. In a language that always checks array indexes, this is a waste of CPU cycles.

      Of course, C is notoriously a bad idea for programmers without the sense to implement lots of sanity checks. These also help to document the assumptions that earlier programmers made about the data, something that few programmers ever bother to document clearly. So someone tweaking or retargeting my C code years later doesn't unknowingly call a routine with out-of-range args, because the routine generates error messages. (So the programmer goes into the routine and deletes the range check ;-).

      But it's easy to see the other side of the issue. And I have worked on machines that did array bounds checking in hardware, with no time cost (just a bit of extra cpu circuitry). It's disappointing that we've known for decades what a good idea this can be, but the people in charge of purchase decisions have decided that they don't want it. So we get lots of malware that takes advantage of out-of-bounds array references in commercial software written by programmers working under marketing-driven time schedules.

      In any case, it's always fun to try to find ways to argue both sides of an issue.

      (And I'm a bit bemused by the fact that my post got an "overrated" mod, when it hasn't been rated at all by anyone. ;-)

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    36. Re:making software more reliable? by erroneus · · Score: 1

      You make an excellent point. The common errors being mentioned are experienced at the high school or lower programming level! These more sophisticated types of bugs are worth mentioning, but the fact that these more simple bugs are so elementary and yet so common that it goes to show what "professional" programmers are putting out into the wild which brings me to my ultimate conclusion. This conclusion is that there are far too many people coding that are simply unqualified for the task.

      Using the famous "car" reference, I may be pretty good at changing the oil in my car, but I am NOT a mechanic even though I may, at times, be capable of doing things like changing the master cylinder or spark plugs as well.

    37. Re:making software more reliable? by badkarmadayaccount · · Score: 1

      Adderal FTW!, N00Bz0R!!11!!!!1111eleventyone!!1!

      *meducks*

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  11. seriously? by Evan55 · · Score: 1

    I had to read one of her books for a grad school class. It was terrible. Chock full of errors, and tangents that were largely unrelated to software development.

    1. Re:seriously? by Kozar_The_Malignant · · Score: 2, Insightful

      tangents that were largely unrelated to software development.

      Tangents are related to geometry, not software development. Besides, professors write textbooks so they can make their students buy them, and the professors get some of the students' money; not because they're any good at it. I thought everyone knew that.

      --
      Some mornings it's hardly worth chewing through the restraints to get out of bed.
    2. Re:seriously? by Workaphobia · · Score: 1

      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)

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    3. Re:seriously? by Anonymous Coward · · Score: 0

      My diff eq professor wrote a great book. I've compared it to other books and it rocks.

  12. LSP it's not a guideline, it's a rule. by refactored · · Score: 4, Interesting
    Sadly, too many people still think it's a guideline, not a rule. Sorry, if your code violates the LSP, you've got a bug, it just hasn't bitten you yet.

    She deserves recognition for the vast number of latent defects she has effectively removed from the worlds software with the LSP alone, I'm glad she got the award.

    1. Re:LSP it's not a guideline, it's a rule. by ClosedSource · · Score: 0

      "Sadly, too many people still think it's a guideline, not a rule. Sorry, if your code violates the LSP, you've got a bug, it just hasn't bitten you yet."

      It's really a very common design convention, but not following the convention isn't necessarily a bug. A bug is a deviation from requirements and requirements should never be assumed.

    2. Re:LSP it's not a guideline, it's a rule. by geekoid · · Score: 1

      "if your code violates the LSP, you've got a bug, it just hasn't bitten you yet. ..."

      False.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    3. Re:LSP it's not a guideline, it's a rule. by Catiline · · Score: 2, Interesting

      "if your code violates the LSP, you've got a bug, it just hasn't bitten you yet. ..."

      False.

      Proof, please; you are contesting an award-winning theory, and I for one side with prevailing theory until further evidence is provided.

    4. Re:LSP it's not a guideline, it's a rule. by davidsyes · · Score: 1

      "but not following the convention isn't necessarily a bug."

      Not following the convention may not be a bug, but it may be annoy... This very suck, this condition...

      --
      Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
    5. Re:LSP it's not a guideline, it's a rule. by ObsessiveMathsFreak · · Score: 1

      It's really a very common design convention, but not following the convention isn't necessarily a bug.

      But without it you'll end up with situations where a function will not accept a pointer to a triangle, because it will only take pointers to data type "polygon" from which triangle is derived.

      If the rule is correctly applied, the relationships between base and derived classes should also be a lot clearer. If it doesn't make sense for a derived type to be passed as a base type, you've probably made a wrong decision in your code design.

      --
      May the Maths Be with you!
    6. Re:LSP it's not a guideline, it's a rule. by vishbar · · Score: 1

      Okay, so, stupid question. Wouldn't the very existence of virtual methods violate this principle? For example, if I have a method:

      void notifyUsers(Publisher pub) { pub.publish(); }

      where class Publisher contains a void method publish(). You have two subclasses of Publisher: EmailPublisher and SmsPublisher (functionality should be obvious, let's just say that it sends a message to users via email/sms). Would the behavior not be different based on whether I passed either of those two subtypes (assuming publish() was declared as virtual in the superclass and is overridden in both subclasses). Of course, I am probably misunderstanding the entire LSP...

      --
      Ride the skies
    7. Re:LSP it's not a guideline, it's a rule. by Workaphobia · · Score: 1

      The point the parent was making is that it's conceivable to have a design spec in which *there shouldn't be any triangles* and thus the fault (bug) is not in the code that doesn't work with triangles.

      That is, enumerating subtypes may be bad design style but doesn't constitute a tangible bug in and of itself.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    8. Re:LSP it's not a guideline, it's a rule. by Workaphobia · · Score: 2, Interesting

      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.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    9. Re:LSP it's not a guideline, it's a rule. by Estanislao+Mart�nez · · Score: 2, Informative

      My understanding is that OP's formulation of the LSP just won't work, because the term "behavior" is too broad. (For reference, here's the formulation I'm referring to: "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.")

      The Wikipedia article has a better formulation, in terms of properties proveable of objects of the types in question (which I suspect is still not quite right, but that's another topic). Basically, for your supertype Publisher, there is some set of properties that should be proveable of every object of that type; for example, the type signature of the methods in question, and invariants that the operations on the type respect. Those properties should be respected by the subtypes for them to be correctly called subtypes at all.

      In your example, given the premise that an object is of type Publisher, then it can be proven that the object has the operation publish(). Given that premise, however, it cannot be proven that the publish() operation sends either email or SMS.

      A violation of the principle would be to implement SMSPublisher as a subclass of EmailPublisher. In that case, given the premise that an object is of type EmailPublisher, then it can be proven that its publish() method sends email. However, given the premise that an object is of type SMSPublisher, it cannot be proven that its publish() method sends email; therefore, SMSPublisher is not semantically a subtype of EmailPublisher.*

      * I don't think this argument is quite right, actually, because we haven't defined very clearly what we mean by "object" and "type" very well. A better, but less precise formulation is that if your code relies on the invariant (i.e., proveable property) that objects of type EmailPublisher send email, then making SMSPublisher a subclass of EmailPublisher will break your code.

    10. Re:LSP it's not a guideline, it's a rule. by refactored · · Score: 1
      A bug is a deviation from requirements and requirements should never be assumed.

      Contrariwise. The requirement is clear. When you specified a parameter type, you are specifying the requirement that the parameter passed IS one of those types.

      Inheritance means "IS A", if you specify that something uses the parent class, then you have specified the requirement that it works with the subclass since an instance of the subclass "IS (also) A" instance of the parent class.

      If it doesn't, then you have violated your clearly specified requirement. Hence you have a bug. It may not bite you in this release, it may not bite on this test. It will bite you in the long run. Sorry mate. Consciously violate LSP, you are consciously introducing a defect. It's not a management proclaimed Best Practice. It's solid mathematics.

      It's a guideline in the sense that "Don't drop bricks on your toes" is a guideline. Having let go of the brick, hard physics takes over. Violate LSP, hard mathematics takes over which results at some point in pain for someone.

    11. Re:LSP it's not a guideline, it's a rule. by ClosedSource · · Score: 1

      The mere fact that you have a class hierarchy does not a requirement make.

      Polymorphism is a capability that most if not all OO languages support, but like any capability it's entirely optional.

    12. Re:LSP it's not a guideline, it's a rule. by Anonymous Coward · · Score: 0

      "if your code violates the LSP, you've got a bug, it just hasn't bitten you yet. ..."

      False.

      Remind me *never* to run *any* software you've written.
      Thanks.

    13. Re:LSP it's not a guideline, it's a rule. by Catiline · · Score: 1

      What are you talking about? It's not a theory, it's a definition. One specific definition out of several, I would imagine.

      The substitution principle is a litte more than just "one definition out of several": in part, it is the definition for what inheritance means, in any object oriented programming language. Here's the Wikipedia version of the Liskov Substituion Principle:
      Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

      You may notice this doesn't say anyhing about behavior directly; any program behavior referenced is considerd "a property provable about objects x of type T". For those following along at home, let's reword this slightly to talk about classes:
      Let q(x) be a property provable about objects x of class T. Then q(y) should be true for objects y of type S where S is a subclass of T.

      Now let's simplify this by taking out some of the formalism in the definition of terms and use a familiar, C++-style reference:
      Let T.q be a public function or variable for objects of class T. Then S.q should exist for objects of class S where S is a subclass of T.

      Hey, this is looking familiar; in fact, that sounds like the typical definition of class inheritance to me! Sure, I may have cut out anything that references program behavior, but we'll get to that next.

      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 you limit the substitution principle to only referring to program behavior, then what you say is true — it isn't a limiting constraint on how you define classes and subclasses. I also must agree the principle does not define what a bug is in any manner at all; instead, it is concerned with formal proof there are no bugs. If that is all you care about, try this phrasing:
      Given a class T and its' subclass S, you cannot formally verify all programs referencing members of class S as a type of T if any public behavior of class S differs from class T.

      So yes, I will recognize there are bug-free programs out there that may have classes which are not "proper subtypes" of each other; however, the principle only states that you cannot FORMALLY PROVE that such programs contain no bugs, which is quite a different question.

    14. Re:LSP it's not a guideline, it's a rule. by vishbar · · Score: 1

      I think I understand...the LSP would essentially attempt to avoid logic such as if (typeof(pub)==EmailPublisher) { ((EmailPublisher)pub).sendEmail(); }?

      --
      Ride the skies
    15. Re:LSP it's not a guideline, it's a rule. by xouumalperxe · · Score: 1

      Polymorphism is a capability that most if not all OO languages support, but like any capability it's entirely optional.

      True, but you opted in, right when you used inheritance. And for as long as that code's in there, it's more binding than most contracts.

    16. Re:LSP it's not a guideline, it's a rule. by ClosedSource · · Score: 1

      "True, but you opted in, right when you used inheritance."

      No. Inheritance is possible without polymorphism and polymorphism is possible without inheritance.

    17. Re:LSP it's not a guideline, it's a rule. by Workaphobia · · Score: 1

      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.)

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    18. Re:LSP it's not a guideline, it's a rule. by badkarmadayaccount · · Score: 1

      Case in point: concatenative prototype systems.

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  13. She's been handing out Linux&BSD disks in clas by Anonymous Coward · · Score: 0

    was recognized for helping make software more reliable, consistent and resistant to errors and hacking

    A very welcome change indeed... ;-)

  14. Ceremony for prize was like this... by stimpleton · · Score: 1

    ...which carries a $250,000 purse.

    A woman's purse!!

    --

    In post Patriot Act America, the library books scan you.
  15. You had a lawn! by ClosedSource · · Score: 1

    We just had dirt. Young whipper-snapper!

    1. Re:You had a lawn! by Anonymous Coward · · Score: 0

      You had dirt? When I came to this planet, this was just a big ball of magma. Now get off my solar system.

  16. oblig. by Eil · · Score: 1

    Liskov, the first US woman to earn a PhD in computer science, was recognized for helping make software more reliable, consistent and resistant to errors and hacking.

    Clearly, she's never worked for Microsoft.

    Zing!

  17. I, for one, welcome our new age by Tiber · · Score: 0, Troll

    of moody computing technology!

  18. More women in the old days by Simian+Road · · Score: 5, Interesting

    Apparently there were far more women in computing in "the old days". The dominance of the male geeks is a relatively recent phenomenon.

    1. Re:More women in the old days by shutdown+-p+now · · Score: 1

      I blame Unix! I mean, "man" - isn't that sexist? ~

  19. Yes by Baldrson · · Score: 2, Informative

    Aside from academic pissing contests you have a much more immediate worry: The lack of bankruptcy protection afforded student loans coupled with the trend in life-time income prospects for CS graduates.

  20. Don't let the award fool you. by Penguinoflight · · Score: 1

    Liskov is a horrible author, and given my experience with her thoughts from "Program Development in Java," I would guess she is a horrible coder as well. Don't be conned into buying books based an award; her works are conflicting where they aren't simply wrong.

    --
    "And we have seen and do testify that the Father sent the Son to be the Savior of the World"
    1 John 4:14
    1. Re:Don't let the award fool you. by geekoid · · Score: 2, Funny

      HAHAHahahhaha...
      Someone with your sig has the gall to write that about a book?

      Irony is rich today.

      Oh, and how about an example of where she is wrong? I don't think I ahve ever read her stuff but I would like to see an example of what you are talking about.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    2. Re:Don't let the award fool you. by Workaphobia · · Score: 1

      I didn't read his sig. I just saw the Bible citation and assumed it was something witty and sarcastic.

      --
      Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
    3. Re:Don't let the award fool you. by MadMidnightBomber · · Score: 1

      I'm surprised this comment didn't cause mysql, or whatever back-end /. uses, to die in a huge embarrassment overload.

      I look forward to next week on /.: Quantum Electrondynamics: Feynmann's work is "conflicting where not simply wrong" and other inspiring comments.

      --
      "It doesn't cost enough, and it makes too much sense."
    4. Re:Don't let the award fool you. by Anonymous Coward · · Score: 0

      Liskov is a horrible author, and given my experience with her thoughts from "Program Development in Java," I would guess she is a horrible coder as well. Don't be conned into buying books based an award; her works are conflicting where they aren't simply wrong.

      it's a troll it's a troll
      don'tanswerit don'tanswerit don'tanswerit!!!

      Aaaargl!!!!!

  21. Translation for Americans by thewils · · Score: 0, Offtopic

    That stuff she's talking about - "Toilet Paper", it's the same stuff you guys, for some weird reason, call "Bathroom Tissue".

    --
    Once I was a four stone apology. Now I am two separate gorillas.
    1. Re:Translation for Americans by Chris+Burke · · Score: 3, Informative

      We don't call it that. We call it toilet paper like normal people. Makers of toilet paper call it bathroom tissue, I guess because they want a name that's a little more distant from "ass wipe" or less evocative of a porcelain bowl filled with crap or something, though they'll talk about their "bathroom tissue" in advertisements while showing cartoon bears (chosen because as everyone knows, bears shit in the woods) with little scraps of toilet paper all over their fat bear asses, which I can't help but wonder who the fuck has this problem and why, but I'm afraid of the answer, and apparently the right brand of ass wipe will solve it so lets just try to forget about that okay?

      What were we talking about? Oh right. It's called "pop". "Soda" is okay too I guess.

      --

      The enemies of Democracy are
    2. Re:Translation for Americans by slyrat · · Score: 1

      What were we talking about? Oh right. It's called "pop". "Soda" is okay too I guess.

      Well, I know this is completely off topic but here is the actual breakdown: pop soda coke map
      So pop there really isn't one term used in this case. Somewhat curious what the "other" sections represent.

    3. Re:Translation for Americans by Chris+Burke · · Score: 1

      I don't appreciate you sabotaging my attempt to start an off-topic pop vs soda vs coke flamewar with your stupid 'facts'. ;)

      --

      The enemies of Democracy are
  22. This is obviously a lie... by Anonymous Coward · · Score: 0

    everyone knows that there are no girls on the interweb

    1. Re:This is obviously a lie... by Anonymous Coward · · Score: 0

      None who don't sit in their bra and panties gyrating to a webcam anyway

  23. Re:Purses and wallets? Nahh... she got a $250k by davidsyes · · Score: 1

    purse, so she should be Prada of herself. If it's another brand, she can curl up with it and grope it and say, "Gucci gucci gnu... Gucci gucci gnu...", but she can always ln with LV... I wonder if that purse will hold CUPS...

    --
    Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
  24. She was not the first woman to get the turring awd by addininja · · Score: 3, Informative
  25. Re:oblig. Obviously, someone envied her... by davidsyes · · Score: 0, Offtopic

    LESKO!

    http://en.wikipedia.org/wiki/Matthew_Lesko

    Must've gone on an all-out CRAYZE to sub-do her...

    --
    Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
  26. Re:Purses and wallets? Nahh... she got a $250k by vishbar · · Score: 2, Insightful

    Fashion jokes aren't gonna go to far on Slashdot, buddy. Just a word of advice.

    --
    Ride the skies
  27. I have nothing against LSP by ClosedSource · · Score: 1

    "But without it you'll end up with situations where a function will not accept a pointer to a triangle, because it will only take pointers to data type "polygon" from which triangle is derived."

    Yes, I understand the implications.

    "If the rule is correctly applied, the relationships between base and derived classes should also be a lot clearer. If it doesn't make sense for a derived type to be passed as a base type, you've probably made a wrong decision in your code design."

    There are no "wrong decisions" unless some requirement is unfulfilled.

    My point is that we sometimes we confuse dogma with correctness.

    1. Re:I have nothing against LSP by MadKeithV · · Score: 1

      In my opinion and experience, any use of public inheritance that does not satisfy the LSP is indeed wrong.
      That's what protected and private inheritance are for, or even more often just plain aggregation.
      Object Oriented programming has become a vague religion rather than a specific tool. People are equating the mechanics of it with actual good practice. I just tutored someone who had their first OO class and it's all about the mechanics without any of the reasoning. And all that leads to me earning my paycheck by fixing the crap code these people end up putting out because they've been taught the wrong things the wrong way.

    2. Re:I have nothing against LSP by ClosedSource · · Score: 1

      "Object Oriented programming has become a vague religion rather than a specific tool."

      It would appear that you treat it like religion yourself except that you aren't vague about it.

      I've been using C++ since the mid-eighties and I doubt that I've ever violated LSP, but I have broad enough experience in software development to realize that I can't foresee every possible scenario.

      To paraphrase Hamlet:

      There are more things in heaven and earth, MadKeithV, than are dreamt of in your philosophy.

  28. Only the women by HornWumpus · · Score: 1

    We judge all of them on their appearance. Deny it all you want but it's true. Women do it as well.

    Their are only two kinds of women...

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    1. Re:Only the women by Pseudonym · · Score: 1

      Their are only two kinds of women...

      ...the kind with PhDs in computer science and the kind without.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    2. Re:Only the women by SuperAndy · · Score: 1

      Don't you mean, there are only 10 types of women?

  29. Nobel Prizei in Computing? by Anonymous Coward · · Score: 0

    it's becoming more like the Oscar Awards in Computing.

  30. That's a mutilated female! by HornWumpus · · Score: 0, Offtopic

    Not a man.

    Men have a X and a Y chromosome (sometimes an extra X or Y). Women have no Y chromosome.

    How about we agree that men have the right to bear children even though they can't, not having a womb, which is no ones fault, not even the Romans.

    We can also agree that women have the right to study CS, even though most can't, being bad a math, which is no ones fault, not even the Republicans.

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    1. Re:That's a mutilated female! by TheSunborn · · Score: 1

      And just to add a note:
      Girls are in general not worse at math then men. If you look at the math grade after 7 years in school there is no real difference between the genders.

    2. Re:That's a mutilated female! by HornWumpus · · Score: 1

      You are correct as far as you take it.

      There is no difference in math ability between the genders until puberty.

      Put another way girls are just a good as boys at math.

      Women on the other hand are generally worse then men at math.

      I see three possible explantions: 1. Testosterone improves math ability 2. Estrogen decreases math ability 3. Some pretty girls figure out how to bounce their tits and get boys to do the hard work for them so they don't learn tough subjects after puberty.

      The difference isn't huge but I still suspect it's a combination of all three.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  31. Proof, hmm, would you like a price tag on that? by refactored · · Score: 3, Insightful

    How about a billion dollars for violating LSP. http://developers.slashdot.org/article.pl?sid=09/03/03/1459209 If you think about it, That's exactly what Tony Hoares mistake was. A violation of LSP. Sometimes the thing pointed to by "T *" does not behave as an instance of T. When it doesn't, as all too often it doesn't. Bad Shit happens. Sorry, type checking compiler can't help you thanks to Hoare's mistake.

  32. Re:She was not the first woman to get the turring by elfleco · · Score: 1

    of course she wasn't... she was the first woman "the first US woman to earn a PhD in computer science" RTFA, or at least the summary!

  33. Re:Purses and wallets? Nahh... she got a $250k by morgan_greywolf · · Score: 1

    You're right. Nobody got mine, either. :/ The married men must've all left. ;)

  34. Re:Loans by Lunzo · · Score: 1

    They still teach Computer Science in countries where university is free or priced at much more affordable fees than in the USA.

  35. In context of history of languages by dpigott · · Score: 3, Interesting

    CLU drew on the lessons learned with both Alphard and Vers. Alphard was from CMU and written by Wulf and Shaw, Wulf also writing the famous BLISS. Vers was made by Jay Early, whose parser was hugely important in all the compilers of the time. THe language itself (and its V-graphs) was heavily influenced by the Mem-theory of Anatol Holt (who was on the Alogl Committee and was a principle in designing the astonishing GP and GPX systems for the UNIVAC - first languages to explicitly feature ADTs per se. That became ACT, the adaptable programming system for the Army's Fieldata portable computers (portable in a completely different sense to the modern usage. He also hated Unicode, but that was a rival programming system back then. So reading the reports at the time can be misleading - "don't use Unicode on Portable Computers!"). Holt's ideas permeate computing, the notion of making any system of data representation as abstract as possible goes back to him.

    CLU was written using MDL (pronounced muddle) which was a protoreplacement for LISP which featured ADTs. MDL was cowritten by Sussmann of LISP fame as a basis for PLANNER which became Scheme, and perhaps more geekly interesting is that is was also used for writing ZIL (and if you don't know about ZIL, you shouldn't be reading Slashdot)

    CLU evolved into Argus, but the ideas were also used in the Theta programming system for the Thor OO database, and was also in PolyJ which was (as it suggests) a Polymorphic Java

    Another fascinating development of the CLU ideas the SPIL system that Liskov co-wrote at the USAF-sponsored MITRE corp, which was in turn used for writing the VENUS operating system

    Liskov has pioneered the notion of abstraction per se in language design for 40 years, and this generics-based approached is now taken for granted. She fully deserved the award for her insights as well as for her determination in fighting the reductionism represented by previous recipients (eg Dijkstra) although opposed by others (eg Iverson)

    I have extracts for reports for all language of these on the HOPL website HOPL.murdoch.edu.au (too many URLs to paste in individually). Find CLU http://hopl.murdoch.edu.au/showlanguage.prx?exp=637&name=CLU and follow the genealogy links. And if you haven't yet seen my 4000-strong programming-language family tree it is worth printing out for wallpaper if you have an A1 plotter.

  36. Re:Loans by Anonymous Coward · · Score: 0

    Now if only those countries could get online forums!

  37. two women in three years... by Anonymous Coward · · Score: 0

    is it just coincidence that two of the last three awards have been given to women, after decades of male dominance?

  38. Do you realize.... by jotaeleemeese · · Score: 1

    That any developer over 38 or thereabouts would have not heard about this while in University then (I know I didn't).

    It is like demanding that all physicists become conversant with relativity theory in the 1920s...

    --
    IANAL but write like a drunk one.
    1. Re:Do you realize.... by kmsigel · · Score: 1

      I just turned 39. I have BS and MS degrees in Computer Science from MIT (1988-1993). Before today, I had never heard the term "Liskov Substitution Principle," though of course I understand, use, and rely upon it every day.

      The LSP is not mentioned in the index of my copy of "Abstraction and Specification in Program Development" (Liskov and Guttag). Btw, I never had Prof. Liskov as a teacher. Guttag taught 6.170 when I took it.

    2. Re:Do you realize.... by shutdown+-p+now · · Score: 1

      That any developer over 38 or thereabouts would have not heard about this while in University then (I know I didn't).

      That's normal in and of itself. A question, though - did you have a course titled "Object-Oriented Design" in the university? My rant was directed against those who claim to teach OOD, not those who teach CS or IT in general.

      It is like demanding that all physicists become conversant with relativity theory in the 1920s...

      Not really. The point was that if the physicists want to work in this area, they better know the underlying theory well, whether they've studied it in the past or not.

  39. Oh the irony. by jotaeleemeese · · Score: 1

    Your reply is a perfect example of why we need more of them.

    Only they know all the reticence and outright discrimination suffered by women in the workplace, sometimes disguised as "curiosity" funnily enough.

    --
    IANAL but write like a drunk one.
  40. That is the reason I don't have a cat. by jotaeleemeese · · Score: 1

    It scares me shitless to think about a cat that can annoy me either dead or alive.

    --
    IANAL but write like a drunk one.
  41. Lack of preventability: complexity. by jotaeleemeese · · Score: 1

    In theory you could find all bugs in a program by simply following it step by step and then providing all the possible values for the relevant variables at each point and checking the outcomes at each point.

    Good luck with that one. To give you an idea of the level of complexity you need to understand that we are dealing with numbers that scale in a similar fashion to any exponential function...

    --
    IANAL but write like a drunk one.
  42. The solid basis for computer science is.... by 3seas · · Score: 1
  43. Re:Purses and wallets? Nahh... she got a $250k by Anonymous Coward · · Score: 0

    No, just the married men who borrow their wives clothes.

  44. LSP issues by lwriemen · · Score: 1

    One should look at C. J. Date's papers on the LSP (WHAT DOES SUBSTITUTABILITY REALLY MEAN?), before they try to implement it.

    Code that implements e.g., squares that aren't rectangles or circles that aren't ellipses, is taking a shortcut or overcoming a technology flaw.