3 ms·

This[0] slide from Rich Hickey's Effective Programs talk[1] has really got me thinking about the benefits of costs of typing. "The Problems of Programming"

• dkarl 9y ago
  To be fair, there are languages where typos and inconsistency naturally fall in the middle tier unless programmers invest silly amounts of time writing and maintaining unit tests to push them down into the third tier where they belong. I can't blame Rich Hickey if he doesn't think much about those languages, but it's an important qualification for people to make when they read this slide in the context of their own work.
  • lewisl9029 9y ago
    I feel the context is important here. This slide is not a comment on the frequency of these problems, because typos are definitely one of most if not the most frequently occurring issue in the day-to-day work of most developers, and I'm sure Rich Hickey realizes that. Rather, this slide is a comment on what he defines as the "severity" of these problems, and one of the important manifestations of severity is the cost of getting these wrong. With the exception of certain business domains where getting things perfectly right the first time is paramount, such as financial transactions and safety/security-critical programs, the cost of typos and inconsistencies is generally minuscule because they're practically costless to debug and fix. In fact, they often cost so little that we end up instinctively fixing typos and inconsistencies countless times throughout our day to day development processes, often without ever even making a conscious effort to identify and fix them. Even if the occasional typo makes it past our tests and into production, these issues are almost always trivial to debug and fix (and if they're not, and you don't happen to be in of these domains where getting things right the very first time is paramount, then oftentimes that can be the smell of some deficiency in your deployment/monitoring setup, or a manifestation of some other more subtle, but more severe problems listed on the slide, such as brittleness/coupling, place oriented programming, weak support for concurrency/names, etc). Of course, being able to outright eliminate these entire classes of errors is a legitimate benefit of a static type system, and Rich Hickey acknowledges this benefit later in the talk. If you're in one of those business domains where you absolutely cannot afford to let typos and inconsistencies sneak their way into your production systems because the they'd be disproportionately costly to fix, or result in consequences that you're not willing to accept, then static typing can be very useful for providing those safeguards. However, I think he also brings up an important point that static type systems and the act of flowing types around in your system is often a significant source of coupling, and that coupling is a much more severe problem when it comes to maintaining a piece of software over the long term. So it's important for each team to assess that tradeoff carefully in order to gauge if they're willing to take on that additional level of coupling in exchange for eliminating the possibility of typos and inconsistencies from reaching production.
    • thesz 9y ago
      You may decrease coupling with the use of interfaces or type classes. This way you do not use concrete types in the construction, you link things with requirements on/between the parameters. Please take a look at the Expression Problem: https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem This thing is an essence of question how to design low coupled system when initially high coupling is expected. There are solutions for most languages and, probably, for your statically typed language of choice (from statically typed languages).
• vanilla_nut 9y ago
  I haven't written as much Rust as I'd like, but one of my favorite things about the language (there's a lot of competition for "favorite" things about Rust, to be fair) is the way that types are required in function signatures, but not within functions. So if you can see the declaration of something, you can always tell what it is -- it's right there. But if it's done in a function somewhere, or if you're just trying to get a sense for the types passed around in a library, it's all on the surface of the signatures. I personally find the lack of declared types in python/javascript absolutely debilitating on large projects, so that really appeals to me.
  • carlmr 9y ago
    You should check out F#! it has amazing type inference (even for functions in some simple cases, although I prefer my functions with types). The type system is still strongly typed and static. So it looks Pythonic, and behaves C#-ic. https://fsharpforfunandprofit.com/posts/type-inference/ https://fsharpforfunandprofit.com/posts/type-inference/
• s6o 9y ago
  After watching that talk, I would have loved somebody in the audience to point out instance like this https://raygun.com/blog/10-costly-software-errors-history/ https://raygun.com/blog/10-costly-software-errors-history/ and ask for Hickey's comments. Needless to say I really don't agree with that list, as history shows the inconsistency, typos, lack basic units and the ability to express them in a computation etc., have been more catastrophic than he believes them to be. And these issues cannot really be fixed without a proper type system, that will not allow stuff like that to get into production. And a good type system cannot be optional, e.g. clojure's spec, There are number of studies that show that will power, is not enough, there needs to be and environment - a type system - that helps to avoid and catch mistakes.
  • sooheon 9y ago
    I see nothing in those 10 costly errors that fundamentally disagree with Hickey's ranking, or advocate clearly for the need of type systems. I also question the value of taking too much stock in outliers. How many of us will be working on the next Mars orbiter?
  • flavio81 9y ago
    >After watching that talk, I would have loved somebody in the audience to point out instance like this https://raygun.com/blog/10-costly-software-errors-history/ https://raygun.com/blog/10-costly-software-errors-history/ and ask for Hickey's comments. Needless to say I really don't agree with that list, as history shows the inconsistency, typos, lack basic units and the ability to express them in a computation etc., have been more catastrophic than he believes them to be. From the list you cite, only three of 10 errors are caused by "typos", "lack of basic units" and type errors. And this is just a particular list. Recalling Rich Hickey list, the things that cause more problem in code, from worst to less damaging: Domain Complexity Misconception 10x Place Oriented Programming Weak support for information Brittleness/Coupling Language model complexity Parochialism/context weak support for Names Distribution Resource utilization Runtime intangibility Libraries Concurrency 10x Inconsistency Typos I'm pretty sure that if we compile a list of real-life cases where the major reasons of failure according to Rich Hickey have caused trouble, the list of examples would be immense, compared to "typos".