5 ms·

This quote is the big takeaway for me: "We use Macs to drive these robots, with control software that was written in Objective-C. We made the decision to rewri

by svec 11y ago

This quote is the big takeaway for me: "We use Macs to drive these robots, with control software that was written in Objective-C. We made the decision to rewrite this software in Swift late last year, but only after a careful survey of the bugs that had impacted our customers over the years. That survey revealed that most of these shipped bugs would have been prevented or detected early in Swift-based code." Apparently they were able to categorize their shipped bugs and prevent those types of bugs from happening again with Swift. That's a very professional process.

ska 11y ago
That's a very professional process. Sad, but true. Not about the Swift part (I have no opinion there) but about the analysis and review of shipped bugs. It should really be "that's an industry standard practice", but a huge amount of software development seems to be done in ways that don't have any systematic way to attempt to learn from mistakes.
- noir_lord 11y ago
  Always liked > Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization It succinctly describes the "process" everywhere I've ever worked.
  - ska 11y ago
    I've always sort of disliked that one, because there are very good reasons that it is difficult for programmers to write programs the way builders/engineers build physical infrastructure. However, there are not any good reasons to avoid improving your process and output iteratively via feedback.
    - noir_lord 11y ago
      I always took it as the general way we throw piles of stuff on top of other stuff until eventually it's so unstable a woodpecker would knock it all over rather than as an accurate indictment of software practices which are of course different to building, software is part science, part art and part prayer.
      - organsnyder 11y ago
        > software is part science, part art and part prayer I've never heard that phrase before—is it yours? I really like it.
        noir_lord 11y ago
        As far as I know, I've not read it anywhere :). Google thinks its original to me so I've not accidentally stolen it unknowingly.
        tossandturn 11y ago
        It's all yours, my friend.
    - detaro 11y ago
      Or inverted: There are very good reasons why it is difficult for builders/architects to build physical things the way developers write programs.
      - ska 11y ago
        Yes that is equally true, but with different implications.
    - wcummings 11y ago
      >there are very good reasons that it is difficult for programmers to write programs the way builders/engineers build physical infrastructure Mostly we just haven't been doing it as long.
      - pathelectronica 11y ago
        builders/engineers are not as perfect as some people seem to think.
      - gregmac 11y ago
        >> write programs the way builders/engineers build physical infrastructure > Mostly we just haven't been doing it as long. This is a popular analogy (among non-programmers) but I have more recently been countering it like this: It's generally predictable how long it will take to build a house, because many have been built, and they're all more or less the same. Sure they have different layouts, number of windows, etc, but essentially it's the same materials, same tools, and same methods. Most programs written are not similar in the same way two houses are similar. They are more comparable to the way a house is different from an airport terminal, or a water treatment plant is different from a golf course. Once you've built many different types of programs, you get a bit better at estimating, but each new type of program poses brand new challenges. A builder used to building small houses from wood is going to be pretty bad at estimating how long it will take to build a missile silo from concrete, and even after building both, will still not be able to come up with a very good estimate for the time to build a railway line between two cities. Also keep in mind that typically, programmers don't build the same (or even similar) program more than once: unlike builders, we have copy+paste.
- sanderjd 11y ago
  This is probably a heretical opinion, but here goes anyway: while it's definitely great to take the time to do a full analysis of common classes of bugs, I don't think it is necessary to do so in order to have a good sense for what common issues a language like Swift solves. I don't need to evaluate my log of bugs to know that I have been bitten tons of times by having a null object or pointer at runtime when a compiler could have made sure I was checking. Languages like Swift and Rust (and Haskell and Ocaml and others) have protections for this and other no-brainer bug classes that I really don't think you need a big bug log analysis to see the advantage of.
  - AnimalMuppet 11y ago
    Sure, you can see what Swift solves, based on the experience of not writing in Swift. That doesn't tell you what new kinds of bugs Swift enables, though. It's going to take years of using it to find out. You can somewhat speed that up by doing a full analysis of the bugs you get using the new language.
    - tl 11y ago
      Well, you can start with all of the things that Objective C has that Swift does not that are likely to cause bugs. For example, static analysis returns nothing where it did something before. Not calling super.viewWillAppear() in a subclass does not raise the appropriate warning in Swift.
    - moonchrome 11y ago
      >Sure, you can see what Swift solves, based on the experience of not writing in Swift. That's actually not true. You can see the trivial stuff it solves from the promo materials - you don't know the full extent of what's realistically possible to encode in the type system. I had this thought yesterday writing C++ code - I was doing some re factoring and I copy pasted the same identifier twice instead of writing data to two separate buffers. The case where this mattered was not covered by unit testing because it's an edge case in a tightly coupled part - it's a major chore to test that kind of code for little gain. My first instinct was "just put unit test there and forget about it" but on the other hand while buffer API is the same two buffers are semantically different so I could have made them two distinct types (eg. with template argument tag) and required untyped input buffer to be wrapped in a type explicitly stating data use case - this would have made the bug obvious and compiler would catch any discrepancy. My point is there are plenty of non-obvious ways to prevent bugs trough a strong type system.
- svec 11y ago
  Yes, definitely! I should have said: That's a very professional process, and it should also be an inspirational process. Just because a lot of software development is haphazard doesn't mean that it has to be! Who cares if you use Swift or Ruby or C or Lisp, ignore the details - we should see the good, mature, "grown-up" things that other people do and copy & modify them! Jack Ganssle (an embedded systems guru) has a great interview about being "a grown-up engineer" here: http://embedded.fm/episodes/2014/5/27/53-being-a-grownup-engineer http://embedded.fm/episodes/2014/5/27/53-being-a-grownup-eng... It applies to all software and hardware systems, not just embedded systems.
stefantalpalaru 11y ago
> That's a very professional process. There's nothing professional about choosing the wrong platform for your application and then jumping into a new proprietary language in the hope of fixing things with a rewrite.
- drauh 11y ago
  Have you looked at the medical devices in a hospital, recently?
  - Alupis 11y ago
    > Have you looked at the medical devices in a hospital, recently? Are you trying to imply they are Apple devices and/or becoming Apple devices? Because that's entirely opposite of what's going on at the several local hospitals (admittedly all under the same organization) near me.
    - colincsl 11y ago
      They are implying that medical devices are notoriously bad at being proprietary/closed. Hospitals would be much better off if the devices could talk to each other but it isn't feasible as-is because device manufacturers want lock-in. The current situation leads to issues like alarm fatigue where nurses effectively ignore problems due to too many devices. If they were centralized then there could be one management system that intelligently alerts the nurse of any issues. We have a major effort at Hopkins going on right now to get around this. See this article more info: http://hub.jhu.edu/2015/10/19/hopkins-microsoft-patient-safety-technology http://hub.jhu.edu/2015/10/19/hopkins-microsoft-patient-safe...
- s73v3r 11y ago
  There's also nothing professional about irrational hatred of a platform, or having the need to complain about another's choice of platform.
  - stefantalpalaru 11y ago

by svec 11y ago

ska 11y ago

That's a very professional process. Sad, but true. Not about the Swift part (I have no opinion there) but about the analysis and review of shipped bugs. It should really be "that's an industry standard practice", but a huge amount of software development seems to be done in ways that don't have any systematic way to attempt to learn from mistakes.

noir_lord 11y ago
Always liked > Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization It succinctly describes the "process" everywhere I've ever worked.
- ska 11y ago
  I've always sort of disliked that one, because there are very good reasons that it is difficult for programmers to write programs the way builders/engineers build physical infrastructure. However, there are not any good reasons to avoid improving your process and output iteratively via feedback.
  - noir_lord 11y ago
    I always took it as the general way we throw piles of stuff on top of other stuff until eventually it's so unstable a woodpecker would knock it all over rather than as an accurate indictment of software practices which are of course different to building, software is part science, part art and part prayer.
    - organsnyder 11y ago
      > software is part science, part art and part prayer I've never heard that phrase before—is it yours? I really like it.
      - noir_lord 11y ago
        As far as I know, I've not read it anywhere :). Google thinks its original to me so I've not accidentally stolen it unknowingly.
      - tossandturn 11y ago
        It's all yours, my friend.
  - detaro 11y ago
    Or inverted: There are very good reasons why it is difficult for builders/architects to build physical things the way developers write programs.
    - ska 11y ago
      Yes that is equally true, but with different implications.
  - wcummings 11y ago
    >there are very good reasons that it is difficult for programmers to write programs the way builders/engineers build physical infrastructure Mostly we just haven't been doing it as long.
    - pathelectronica 11y ago
      builders/engineers are not as perfect as some people seem to think.
    - gregmac 11y ago
      >> write programs the way builders/engineers build physical infrastructure > Mostly we just haven't been doing it as long. This is a popular analogy (among non-programmers) but I have more recently been countering it like this: It's generally predictable how long it will take to build a house, because many have been built, and they're all more or less the same. Sure they have different layouts, number of windows, etc, but essentially it's the same materials, same tools, and same methods. Most programs written are not similar in the same way two houses are similar. They are more comparable to the way a house is different from an airport terminal, or a water treatment plant is different from a golf course. Once you've built many different types of programs, you get a bit better at estimating, but each new type of program poses brand new challenges. A builder used to building small houses from wood is going to be pretty bad at estimating how long it will take to build a missile silo from concrete, and even after building both, will still not be able to come up with a very good estimate for the time to build a railway line between two cities. Also keep in mind that typically, programmers don't build the same (or even similar) program more than once: unlike builders, we have copy+paste.
sanderjd 11y ago
This is probably a heretical opinion, but here goes anyway: while it's definitely great to take the time to do a full analysis of common classes of bugs, I don't think it is necessary to do so in order to have a good sense for what common issues a language like Swift solves. I don't need to evaluate my log of bugs to know that I have been bitten tons of times by having a null object or pointer at runtime when a compiler could have made sure I was checking. Languages like Swift and Rust (and Haskell and Ocaml and others) have protections for this and other no-brainer bug classes that I really don't think you need a big bug log analysis to see the advantage of.
- AnimalMuppet 11y ago
  Sure, you can see what Swift solves, based on the experience of not writing in Swift. That doesn't tell you what new kinds of bugs Swift enables, though. It's going to take years of using it to find out. You can somewhat speed that up by doing a full analysis of the bugs you get using the new language.
  - tl 11y ago
    Well, you can start with all of the things that Objective C has that Swift does not that are likely to cause bugs. For example, static analysis returns nothing where it did something before. Not calling super.viewWillAppear() in a subclass does not raise the appropriate warning in Swift.
  - moonchrome 11y ago
    >Sure, you can see what Swift solves, based on the experience of not writing in Swift. That's actually not true. You can see the trivial stuff it solves from the promo materials - you don't know the full extent of what's realistically possible to encode in the type system. I had this thought yesterday writing C++ code - I was doing some re factoring and I copy pasted the same identifier twice instead of writing data to two separate buffers. The case where this mattered was not covered by unit testing because it's an edge case in a tightly coupled part - it's a major chore to test that kind of code for little gain. My first instinct was "just put unit test there and forget about it" but on the other hand while buffer API is the same two buffers are semantically different so I could have made them two distinct types (eg. with template argument tag) and required untyped input buffer to be wrapped in a type explicitly stating data use case - this would have made the bug obvious and compiler would catch any discrepancy. My point is there are plenty of non-obvious ways to prevent bugs trough a strong type system.
svec 11y ago
Yes, definitely! I should have said: That's a very professional process, and it should also be an inspirational process. Just because a lot of software development is haphazard doesn't mean that it has to be! Who cares if you use Swift or Ruby or C or Lisp, ignore the details - we should see the good, mature, "grown-up" things that other people do and copy & modify them! Jack Ganssle (an embedded systems guru) has a great interview about being "a grown-up engineer" here: http://embedded.fm/episodes/2014/5/27/53-being-a-grownup-engineer http://embedded.fm/episodes/2014/5/27/53-being-a-grownup-eng... It applies to all software and hardware systems, not just embedded systems.

stefantalpalaru 11y ago

> That's a very professional process. There's nothing professional about choosing the wrong platform for your application and then jumping into a new proprietary language in the hope of fixing things with a rewrite.

drauh 11y ago
Have you looked at the medical devices in a hospital, recently?
- Alupis 11y ago
  > Have you looked at the medical devices in a hospital, recently? Are you trying to imply they are Apple devices and/or becoming Apple devices? Because that's entirely opposite of what's going on at the several local hospitals (admittedly all under the same organization) near me.
  - colincsl 11y ago
    They are implying that medical devices are notoriously bad at being proprietary/closed. Hospitals would be much better off if the devices could talk to each other but it isn't feasible as-is because device manufacturers want lock-in. The current situation leads to issues like alarm fatigue where nurses effectively ignore problems due to too many devices. If they were centralized then there could be one management system that intelligently alerts the nurse of any issues. We have a major effort at Hopkins going on right now to get around this. See this article more info: http://hub.jhu.edu/2015/10/19/hopkins-microsoft-patient-safety-technology http://hub.jhu.edu/2015/10/19/hopkins-microsoft-patient-safe...
s73v3r 11y ago
There's also nothing professional about irrational hatred of a platform, or having the need to complain about another's choice of platform.
- stefantalpalaru 11y ago