5 ms·

The problems exposed by languages like Ruby are not necessarily problems with dynamic types. For example you can do reasoning about purity, side-effects and wha

The problems exposed by languages like Ruby are not necessarily problems with dynamic types. For example you can do reasoning about purity, side-effects and whatnot in languages of the LISP family as well. Clojure for example is much, much saner than Ruby in all the points listed by TFA - static typing is for example by definition anti-modularity and anti-adaptability and note that I prefer static typing over dynamic typing and Scala over Clojure. On the issue of static versus dynamic one has to view this as a different school of thought and to apply one versus the other depending on the needs of the project. Uncontrolled side-effects are the real issue behind most of the accidental complexity that we are seeing. We all badly need to adopt more abstractions and techniques from functional programming. Also, changing languages or idioms doesn't necessarily help with the exposed problems. We also need a change of mentality in how we are doing software development. Lets face it, when we need to do something right now, urgent, that should have been done yesterday - no matter the language, no matter the abstractions or idioms involved, we are bound to do stupid shit - because there's accidental complexity and then there's inherent complexity and nothing saves you from inherent complexity other than thinking really well about the problem at hand and splitting it into simpler, more manageable parts. This is also why TDD is a failure and complete bullshit in how it is advertised. Tests don't save you from doing stupid shit. Tests don't tell you whether your architecture is any good, they only tell you if your architecture is testable. Tests don't prove the absence of bugs, they only prove their presence. Tests only tell if you reached a desired target, not what that target should be. And perhaps most importantly since this is touching the core of their purpose, when uncontrolled side-effects are happening in your system, tests are a poor safety net - anybody that had to deal with concurrency issues can attest to that. Agile methodologies are also trying to paint a turd. Yes, we should deploy or publish as soon as we've got something to publish. We should pivot a lot. We should communicate more with the end-users or within the team. And so on and so forth. But it's an indisputable fact that some problems are hard enough that they can't be solved by puking code and tests in a matter of hours or days, or by adding more people to the team.

austinz 12y ago
I think a large part of good software design involves making the implicit into the explicit (although there are always tradeoffs). Instead of writing six different very similar functions that implicitly do the same thing but on different types, we write a single function with generic type parameters. Instead of writing a bunch of nested for loops working on a bunch of mutable state in an imperative way, we use map, filter, reduce, fold, etc to explicitly describe the transformations we are trying to accomplish. Instead of allowing our code to crash when bad inputs cause an error, we use asserts to declare pre- and post-conditions. And so forth. TDD style tests have their place, but they don't do all that much to make the implicit into the explicit. If you use tests as a source of truth or a form of documentation, you are essentially saying your specification doesn't actually exist except as some weird emergent phenomenon - and then you have to take the time to disentangle the assumptions inherent in the tests from the assumptions inherent in the choices of test inputs and outputs. Tests can, by their nature, only exercise an infinitesimally small fraction of the possible combinations of inputs and state transitions that your code can go through. So tests, which serve to validate the code, need themselves to be validated. How can we even arrive at the intuition that our tests are covering some useful sample of this gigantic state-space? Metrics like code coverage and the size of a test suite are only meaningful if you assume the tests themselves are sound in the first place.
Ygg2 12y ago
> This is also why TDD is a failure and complete bullshit in how it is advertised. Tests don't save you from doing stupid shit. Why do people think tests are for that? Tests are basically same as free climbers safety lines. They won't protect you from everything and sure they are tedious to place, but once they save your tush, you'll be glad they were there, and you weren't splattered across the floor. I've seen lack of tests in practice and it's not pretty. Nope. Not pretty at all. Basically lots of entangled undocumented, untested systems that you can't refactor because your refactor just broke some code somewhere. To demonstrate some of the bugs, if you accidentally type your username wrong, the whole server crashes and resets. It was not pretty.
- CmonDev 12y ago
  "you can't refactor because your refactor just broke some code somewhere" - picking a language that is not matched with first-class automated refactoring (ReSharper, IDEA) was their first mistake (rather than lack of unit testing).
  - dozzie 12y ago
    Renaming stuff and pushing variables around is not refactoring. It's just some editing work.
    - coldtea 12y ago
      You'd be surprised what transformation modern IDEs can do that IS refactoring, not just renaming and pushing variables around. Plus, you're wrong: a lot of refactoring is also about renaming stuff and pushing variables around. You don't always have to rewrite everything in new hierarchies and patterns in order to do a refactor.
      - fenomas 12y ago
        Anyone who doubts this should watch Jim Weirich's talk "Adventures in Functional Programming" - the last (and most mind-blowing) quarter of the talk is almost entirely made up of automatic refactoring. [1] http://vimeo.com/45140590 http://vimeo.com/45140590
collyw 12y ago
Part of the problem I see after 11 years in the business, is that now I can see problems like you describe. I try and push as much work to the database as possible, not for performance (though that is a consideration) but because it is declarative, so you get less side effects. Its not as natural to think in sets as it is to think imperatively. But do people want to pay me more for this knowledge? Not here (in Spain). They want to pay extra for people using the latest fad technology, not people who know how to avoid problems at the design stage.
- dozzie 12y ago
  It's not natural to think imperatively, otherwise people would have no trouble with learning programming. It's just the way we were taught to write programs.
  - collyw 12y ago
    Its generally easier that thinking in sets. Certainly my not so talented team leader always describes database queries in terms of "if it has this then do this". I translate these into "give me the set where".
    - dozzie 12y ago
      No, it's not generally easier. You can't generalize because people around you, who were taught to think imperatively, are thinking imperatively. You don't know how would it be if they were taught to think in terms of set theory. It might be the other way around or it could be not. That's the point: we don't have the data to generalize on which thinking is easier.
      - collyw 12y ago
        I was taught both. Who is generalising now?
        dozzie 12y ago
sfvisser 12y ago
> static typing is for example by definition anti-modularity and anti-adaptability This is so painfully wrong. Static types are not in the way of modularity and type correct programs are not hard to adapt to another type correct program. I would say it's the exact opposite. Types are perfectly modular and compose beautifully. Adapting your program's design in a type safe environment is a breeze, because your compiler/types more often than not tell you exactly what you can and cannot do.
- bad_user 12y ago
  No, I'm right, because people smarter than me have said it. Here's the quintessence of this argument: https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem And also, imagine trying to build a system that works like our body does, particularly fascinating is the process of wound healing: https://en.wikipedia.org/wiki/Wound_healing https://en.wikipedia.org/wiki/Wound_healing You know, there's a reason for why Akka's actors, a library built for a fairly static and expressive language (Scala), are dynamically typed. Try finding out why that is.
  - chongli 12y ago
    No, I'm right, because people smarter than me have said it. Wow. Just... wow. Seriously? No! The expression problem can be solved in Haskell in a straightforward manner using type classes[0]. You know, there's a reason for why Akka's actors, a library built for a fairly static and expressive language (Scala), are dynamically typed. Try finding out why that is. Because Scala is a crappy, broken language built out of compromises with the JVM? Take a look at Haskell's distributed-process[1] library. It solves the problem that Akka punted on (namely type-safe serialization of function closures). [0] http://paulkoerbitz.de/posts/Solving-the-Expression-Problem-in-Haskell-and-Java.html http://paulkoerbitz.de/posts/Solving-the-Expression-Problem-... [1] http://hackage.haskell.org/package/distributed-process http://hackage.haskell.org/package/distributed-process
    - bad_user 12y ago
      Akka has to expose the actor registry, has to handle network connectivity issues and scalability issues, which means messages have to go through actors posing as proxies and routers; and actors may be dynamically created - and also because of the async model, actors can and must change/adapt their interface asynchronously, like when doing back-pressure and waiting for acknowledgement that a message was received on the other end, during which there can be no progress, as in "context.become", fundamental for the actor model - which actually renders static typing useless. Saying that Haskell's distributed-process solves the problems that Akka is solving is short-sighted and wrong. But then again, the main reason for why Haskell hasn't attracted me has nothing to do with technicalities and everything to do with a vocal minority of Haskell users that I find totally repulsive.

austinz 12y ago

I think a large part of good software design involves making the implicit into the explicit (although there are always tradeoffs). Instead of writing six different very similar functions that implicitly do the same thing but on different types, we write a single function with generic type parameters. Instead of writing a bunch of nested for loops working on a bunch of mutable state in an imperative way, we use map, filter, reduce, fold, etc to explicitly describe the transformations we are trying to accomplish. Instead of allowing our code to crash when bad inputs cause an error, we use asserts to declare pre- and post-conditions. And so forth. TDD style tests have their place, but they don't do all that much to make the implicit into the explicit. If you use tests as a source of truth or a form of documentation, you are essentially saying your specification doesn't actually exist except as some weird emergent phenomenon - and then you have to take the time to disentangle the assumptions inherent in the tests from the assumptions inherent in the choices of test inputs and outputs. Tests can, by their nature, only exercise an infinitesimally small fraction of the possible combinations of inputs and state transitions that your code can go through. So tests, which serve to validate the code, need themselves to be validated. How can we even arrive at the intuition that our tests are covering some useful sample of this gigantic state-space? Metrics like code coverage and the size of a test suite are only meaningful if you assume the tests themselves are sound in the first place.

Ygg2 12y ago

> This is also why TDD is a failure and complete bullshit in how it is advertised. Tests don't save you from doing stupid shit. Why do people think tests are for that? Tests are basically same as free climbers safety lines. They won't protect you from everything and sure they are tedious to place, but once they save your tush, you'll be glad they were there, and you weren't splattered across the floor. I've seen lack of tests in practice and it's not pretty. Nope. Not pretty at all. Basically lots of entangled undocumented, untested systems that you can't refactor because your refactor just broke some code somewhere. To demonstrate some of the bugs, if you accidentally type your username wrong, the whole server crashes and resets. It was not pretty.

CmonDev 12y ago
"you can't refactor because your refactor just broke some code somewhere" - picking a language that is not matched with first-class automated refactoring (ReSharper, IDEA) was their first mistake (rather than lack of unit testing).
- dozzie 12y ago
  Renaming stuff and pushing variables around is not refactoring. It's just some editing work.
  - coldtea 12y ago
    You'd be surprised what transformation modern IDEs can do that IS refactoring, not just renaming and pushing variables around. Plus, you're wrong: a lot of refactoring is also about renaming stuff and pushing variables around. You don't always have to rewrite everything in new hierarchies and patterns in order to do a refactor.
    - fenomas 12y ago
      Anyone who doubts this should watch Jim Weirich's talk "Adventures in Functional Programming" - the last (and most mind-blowing) quarter of the talk is almost entirely made up of automatic refactoring. [1] http://vimeo.com/45140590 http://vimeo.com/45140590

collyw 12y ago

Part of the problem I see after 11 years in the business, is that now I can see problems like you describe. I try and push as much work to the database as possible, not for performance (though that is a consideration) but because it is declarative, so you get less side effects. Its not as natural to think in sets as it is to think imperatively. But do people want to pay me more for this knowledge? Not here (in Spain). They want to pay extra for people using the latest fad technology, not people who know how to avoid problems at the design stage.

dozzie 12y ago
It's not natural to think imperatively, otherwise people would have no trouble with learning programming. It's just the way we were taught to write programs.
- collyw 12y ago
  Its generally easier that thinking in sets. Certainly my not so talented team leader always describes database queries in terms of "if it has this then do this". I translate these into "give me the set where".
  - dozzie 12y ago
    No, it's not generally easier. You can't generalize because people around you, who were taught to think imperatively, are thinking imperatively. You don't know how would it be if they were taught to think in terms of set theory. It might be the other way around or it could be not. That's the point: we don't have the data to generalize on which thinking is easier.
    - collyw 12y ago
      I was taught both. Who is generalising now?
      - dozzie 12y ago

sfvisser 12y ago

> static typing is for example by definition anti-modularity and anti-adaptability This is so painfully wrong. Static types are not in the way of modularity and type correct programs are not hard to adapt to another type correct program. I would say it's the exact opposite. Types are perfectly modular and compose beautifully. Adapting your program's design in a type safe environment is a breeze, because your compiler/types more often than not tell you exactly what you can and cannot do.

bad_user 12y ago
No, I'm right, because people smarter than me have said it. Here's the quintessence of this argument: https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem And also, imagine trying to build a system that works like our body does, particularly fascinating is the process of wound healing: https://en.wikipedia.org/wiki/Wound_healing https://en.wikipedia.org/wiki/Wound_healing You know, there's a reason for why Akka's actors, a library built for a fairly static and expressive language (Scala), are dynamically typed. Try finding out why that is.
- chongli 12y ago
  No, I'm right, because people smarter than me have said it. Wow. Just... wow. Seriously? No! The expression problem can be solved in Haskell in a straightforward manner using type classes[0]. You know, there's a reason for why Akka's actors, a library built for a fairly static and expressive language (Scala), are dynamically typed. Try finding out why that is. Because Scala is a crappy, broken language built out of compromises with the JVM? Take a look at Haskell's distributed-process[1] library. It solves the problem that Akka punted on (namely type-safe serialization of function closures). [0] http://paulkoerbitz.de/posts/Solving-the-Expression-Problem-in-Haskell-and-Java.html http://paulkoerbitz.de/posts/Solving-the-Expression-Problem-... [1] http://hackage.haskell.org/package/distributed-process http://hackage.haskell.org/package/distributed-process
  - bad_user 12y ago
    Akka has to expose the actor registry, has to handle network connectivity issues and scalability issues, which means messages have to go through actors posing as proxies and routers; and actors may be dynamically created - and also because of the async model, actors can and must change/adapt their interface asynchronously, like when doing back-pressure and waiting for acknowledgement that a message was received on the other end, during which there can be no progress, as in "context.become", fundamental for the actor model - which actually renders static typing useless. Saying that Haskell's distributed-process solves the problems that Akka is solving is short-sighted and wrong. But then again, the main reason for why Haskell hasn't attracted me has nothing to do with technicalities and everything to do with a vocal minority of Haskell users that I find totally repulsive.