4 ms·

It's not more marketing, Zed, it's years and years and years of evidence that poorly-managed memory is a major source of error in design, and folks in the appl

It's not more marketing, Zed, it's years and years and years of evidence that poorly-managed memory is a major source of error in design, and folks in the application development and security fields trying to pass along a message to avoid it if possible. State is also a major source of error in design, which is why stateless dogmatists keep hammering on it. You can get good design without them, and some people do. But everyone makes mistakes sometimes. Picking technologies that help you avoid making them isn't marketing, it's just good sense. People have a bad habit of calling any received wisdom they disagree with "marketing". There are people out there far smarter than I am, and possibly smarter than you are (though I'm not in a position to judge), who disagree strongly with what you say, and they're not marketeers. No need to go down that route in this debate.

zedshaw 16y ago
Bad programmers are the cause of everything you said, not the tools they use. For example, if you compile a language to machine code and use a linker, then I can inject memory errors and violate your view of state. Unless you have link time assertions, your carefully crafted "safe state free" languages aren't. "State is also a major source of error" is an unsupported claim. Show me any usability study that confirms removing state improves a programmer's source and understanding of the solution. The truth is, all of the concepts of state free, type systems, assertions, and design by contract are just specific limited cases of a more flexible assertion system. Type systems are a compile time assertion that you are getting a type you expect. Design By Contract are runtime assertions about state of the system. So is assert in C. Removal of state like in Haskell is just a very restrictive design by contract alternative compile time assertion. If all of these are specific cases of a general assertion system, then none of them cover the complete set of assertions you'd need to truly make "safer" software. You'd need link time assertions (dll hashes and version required, function prototypes required), compile time assertions more flexible than types, and runtime assertions like design by contract. Unless your language has all of those in an optional way (which would be a pain in the ass to use) then your language is truly no better than C.
- bguthrie 16y ago
  I agree that not all of the things you list necessarily reduce errors, or that those that do increase productivity over the long run, because you sort of straw-manned me a little bit there. Me, I don't love strong type systems. But garbage collection doesn't fall into that category. As for state, the concerns there are confined primarily to concurrent systems, and about a gazillion people have discussed its problems with greater eloquence than I can muster (Joshua Bloch comes to mind). But you're a great programmer--no sarcasm intended--and if you say you can produce a great concurrent system and still carry around a ton of state then I believe you. I'm genuinely looking forward to the fruits of your labor. Most people, myself included, can't. The goal isn't to twist yourself or your users into a pretzel trying to build a language that prevents any error whatsoever from occurring, as far as I'm concerned. The goal is to produce a language that shrinks the potential for bad stuff on the downside and encourages good practices (and stays out of your way) on the upside. C did, in its day, accomplish both things admirably, and for some tasks it remains the best tool. It does not, however, follow that all of its shortcomings are in fact virtues, and that those who say otherwise are marketing.
  - zedshaw 16y ago
    I'll give you a hint about how it's done: Finite State Machines. They're provable, simple, and are designed to handle state. Removing state isn't the answer. Giving programmers great FSM tools is (like in Erlang).
    - jrockway 16y ago
      You are confusing mutable state and state. Of course you need state. What you don't need is randomly overwriting blocks of memory when your program makes a state transition. Instead, you want more structured state transitions. A FSM is one way of getting that.

zedshaw 16y ago

Bad programmers are the cause of everything you said, not the tools they use. For example, if you compile a language to machine code and use a linker, then I can inject memory errors and violate your view of state. Unless you have link time assertions, your carefully crafted "safe state free" languages aren't. "State is also a major source of error" is an unsupported claim. Show me any usability study that confirms removing state improves a programmer's source and understanding of the solution. The truth is, all of the concepts of state free, type systems, assertions, and design by contract are just specific limited cases of a more flexible assertion system. Type systems are a compile time assertion that you are getting a type you expect. Design By Contract are runtime assertions about state of the system. So is assert in C. Removal of state like in Haskell is just a very restrictive design by contract alternative compile time assertion. If all of these are specific cases of a general assertion system, then none of them cover the complete set of assertions you'd need to truly make "safer" software. You'd need link time assertions (dll hashes and version required, function prototypes required), compile time assertions more flexible than types, and runtime assertions like design by contract. Unless your language has all of those in an optional way (which would be a pain in the ass to use) then your language is truly no better than C.

bguthrie 16y ago
I agree that not all of the things you list necessarily reduce errors, or that those that do increase productivity over the long run, because you sort of straw-manned me a little bit there. Me, I don't love strong type systems. But garbage collection doesn't fall into that category. As for state, the concerns there are confined primarily to concurrent systems, and about a gazillion people have discussed its problems with greater eloquence than I can muster (Joshua Bloch comes to mind). But you're a great programmer--no sarcasm intended--and if you say you can produce a great concurrent system and still carry around a ton of state then I believe you. I'm genuinely looking forward to the fruits of your labor. Most people, myself included, can't. The goal isn't to twist yourself or your users into a pretzel trying to build a language that prevents any error whatsoever from occurring, as far as I'm concerned. The goal is to produce a language that shrinks the potential for bad stuff on the downside and encourages good practices (and stays out of your way) on the upside. C did, in its day, accomplish both things admirably, and for some tasks it remains the best tool. It does not, however, follow that all of its shortcomings are in fact virtues, and that those who say otherwise are marketing.
- zedshaw 16y ago
  I'll give you a hint about how it's done: Finite State Machines. They're provable, simple, and are designed to handle state. Removing state isn't the answer. Giving programmers great FSM tools is (like in Erlang).
  - jrockway 16y ago
    You are confusing mutable state and state. Of course you need state. What you don't need is randomly overwriting blocks of memory when your program makes a state transition. Instead, you want more structured state transitions. A FSM is one way of getting that.