5 ms·

I think people tend to underestimate the amount of time they spend on problems, when those are uninteresting. A single null dereference error may be trivial to

by Peaker 13y ago

I think people tend to underestimate the amount of time they spend on problems, when those are uninteresting. A single null dereference error may be trivial to fix, but the overhead around fixing any bug may be costly. For example, you might need to deploy a whole new version, rerun test suites and have a bunch of meetings. Then after all of this, you might remember that the problem only costed you 10 minutes of fixing the bug. When you implement a red-black-tree, do you not spend any time testing your invariants? Or figuring out the bugs? That's a good example of where the Haskell type system can simply give you compile time guarantees saving you from bugs and from having to test them. I also worry about the problems you mention, many of which Haskell indeed doesn't help much with. I don't see how these problems (which you solve once, usually by reusing a library) are what costs the majority of the time. A big, non-trivial implementation has bugs and will require testing. Haskell will have less bugs, and require less tests. This is a pretty big deal. It's weird that you bring Twitter as an example, as they canned a dynamic language solution for a static language that is in many ways very similar to Haskell. I've seen multiple large scale projects in dynamic languages. They all fail to scale well, both performance-wise and maintenance-wise. Statically-typed systems scale far better along both of these axis.

TylerE 13y ago
I can't remember the last time I implemented a data-structure in a web framework. You just use the built in dictionary/hash table and get on with life.
- Peaker 13y ago
  Well, whenever you write non-trivial code, your code is going to have invariants. These invariants can be partially tested or they can be fully type-checked. The latter is better and cheaper, when available. Haskell makes the latter available far more often, so you don't have to pay for the former. This is not just useful for data structures, but code in general.
  - TylerE 13y ago
    This post kind of sums it up for me. No, I'm not thinking about invariants. We're talking about writing a web app here. Typing is pretty meaningless when 99.9% of your data is just strings.
    - Peaker 13y ago
      If 99.9% of your data is "just strings", you're probably Doing It Wrong.
      - TylerE 13y ago
        Again.... web app.
        Peaker 13y ago
        Example web app: http://www.yesodweb.com/blog/2012/04/yesod-js-todo http://www.yesodweb.com/blog/2012/04/yesod-js-todo How many Strings do you see there?
YcombRegBroken 13y ago
I'm a little confused here. You realize that Go is also statically typed, right? I'm not sure where any debate about dynamic languages started. The points you make about static vs dynamic are valid, just not relavent at the moment. It's funny, too, how you talk about "implementing a red black tree" like it's an everyday occurrence. I'm guessing you are a teacher/researcher (in which case this entire discussion makes much more sense). On any application team I've worked with (in the valley or out), implementing a binary tree from scratch would require extreme justification and literally have to be the only way possible to solve the problem.
- Peaker 13y ago
  On the dynamic..static axis, Go is much closer to the dynamic side than to Haskell's side. I am not a teacher or researcher, I am a practicing programmer writing code that is used by critical systems as well as ambitious projects that will (hopefully) be used by many real people. A red black tree is just an example with invariants that everyone is likely to know, so it's a nice way to illustrate the point about the power of types. Known problems are solved problems, and unsolved problems are unknown problems -- so either my invariants' example will not speak to you because you don't know it, or you will reject it because you can just re-use a library.
  - TylerE 13y ago
    Ok, you've finally gone and proven that you know basically f-all about go and are just out to thump the Haskell Bible.
  - YcombRegBroken 13y ago
    Ok, look, I understand that you spent a lot of time learning Haskell, and desperately want that time to not have been in vain. You have to back off the preaching though. The conversation you joined wasn't about Haskell. You barged in and made it about Haskell. On the way, to justify your comments, you have put forth some pretty ridiculous claims. Go being dynamically typed, Haskell being 30-50% quicker to develop in, glossing over the valid points about it being more difficult to learn, etc... We get it. You don't like Go. Some of us do, and would rather have a productive discussion about how to take advantage of it's features and avoid the traps rather than get into a pointless debate about a language that we are highly unlikely to ever use. (after this discussion, I certainly never will) You are giving the Haskell community a bad image with this kind of behavior, and I kindly request that you not reply to any more of my comments with anything to do with Haskell.
agentS 13y ago
> I think people tend to underestimate the amount of time they spend on problems... Again, the implication is that people who use languages with looser type-systems than Haskell spend lots of time dealing with the problems that you mention. In my experience, that is not the case. You can claim that I'm underestimating the impact of such bugs if you'd like. > When you implement a red-black-tree, do you not spend any time testing your invariants? Testing is, as far as I can tell, the reason that these problems don't come up. In the process of solving all of those problems I listed above, you tend to write a bunch of tests that exercise the same code that is run in production. > It's weird that you bring Twitter as an example, as they canned a dynamic language solution for a static language that is in many ways very similar to Haskell. I assure you that this transition is far less complete than you might think, and even when complete, will have more Java than Scala. Note that both of these languages allow shared mutable data, both allow null pointers. > They all fail to scale well, both performance-wise and maintenance-wise. Statically-typed systems scale far better along both of these axis. Oh, I agree. Go is statically-typed. However, you're advocating going even further along the spectrum, and I'm saying that going further brings diminishing returns, and starts costing you in terms of available engineers, and your productivity in writing code. I think Go occupies a good point along this spectrum, where I can write robust code without arguing with a compiler.
- Peaker 13y ago
  > Testing is, as far as I can tell, the reason that these problems don't come up. Testing is a cost. It is more code to write, more code to maintain. It gives no guarantees about correctness, even of the exact feature under test. Consider the 10 lines starting from https://github.com/yairchu/red-black-tree/blob/master/RedBlackTree.hs#L27 https://github.com/yairchu/red-black-tree/blob/master/RedBla... They guarantee the correctness of the invariants of the Red Black Tree, and they easily replace hundreds of lines of test code which give no guarantee. We might still need to write tests, but a lot fewer of them. Also, those we write will give us far more "bang for buck" because we can use QuickCheck property testing. > Note that both of these languages allow shared mutable data, both allow null pointers. Scala shuns null - and only has it for Java interop. All Scala developers I've discussed this with program as if null did not exist, and never use it to signify lack of a value. > I think Go occupies a good point along this spectrum, where I can write robust code without arguing with a compiler. When "arguing with a compiler", you're really being faced with bugs now rather than later, when the code is no longer in your head - or worse, in production. If the type checker rejects your program, it is almost certainly broken, and it is better to "argue with a compiler" than to just compile and get a runtime error later. Availability of engineers is a good point, though as a Haskeller, I know both companies seeking Haskell employees and Haskellers seeking employment (preferably in Haskell). Consider the flip-side of the engineers availability is the "Python paradox".

by Peaker 13y ago

TylerE 13y ago

I can't remember the last time I implemented a data-structure in a web framework. You just use the built in dictionary/hash table and get on with life.

Peaker 13y ago
Well, whenever you write non-trivial code, your code is going to have invariants. These invariants can be partially tested or they can be fully type-checked. The latter is better and cheaper, when available. Haskell makes the latter available far more often, so you don't have to pay for the former. This is not just useful for data structures, but code in general.
- TylerE 13y ago
  This post kind of sums it up for me. No, I'm not thinking about invariants. We're talking about writing a web app here. Typing is pretty meaningless when 99.9% of your data is just strings.
  - Peaker 13y ago
    If 99.9% of your data is "just strings", you're probably Doing It Wrong.
    - TylerE 13y ago
      Again.... web app.
      - Peaker 13y ago
        Example web app: http://www.yesodweb.com/blog/2012/04/yesod-js-todo http://www.yesodweb.com/blog/2012/04/yesod-js-todo How many Strings do you see there?

YcombRegBroken 13y ago

I'm a little confused here. You realize that Go is also statically typed, right? I'm not sure where any debate about dynamic languages started. The points you make about static vs dynamic are valid, just not relavent at the moment. It's funny, too, how you talk about "implementing a red black tree" like it's an everyday occurrence. I'm guessing you are a teacher/researcher (in which case this entire discussion makes much more sense). On any application team I've worked with (in the valley or out), implementing a binary tree from scratch would require extreme justification and literally have to be the only way possible to solve the problem.

Peaker 13y ago
On the dynamic..static axis, Go is much closer to the dynamic side than to Haskell's side. I am not a teacher or researcher, I am a practicing programmer writing code that is used by critical systems as well as ambitious projects that will (hopefully) be used by many real people. A red black tree is just an example with invariants that everyone is likely to know, so it's a nice way to illustrate the point about the power of types. Known problems are solved problems, and unsolved problems are unknown problems -- so either my invariants' example will not speak to you because you don't know it, or you will reject it because you can just re-use a library.
- TylerE 13y ago
  Ok, you've finally gone and proven that you know basically f-all about go and are just out to thump the Haskell Bible.
- YcombRegBroken 13y ago
  Ok, look, I understand that you spent a lot of time learning Haskell, and desperately want that time to not have been in vain. You have to back off the preaching though. The conversation you joined wasn't about Haskell. You barged in and made it about Haskell. On the way, to justify your comments, you have put forth some pretty ridiculous claims. Go being dynamically typed, Haskell being 30-50% quicker to develop in, glossing over the valid points about it being more difficult to learn, etc... We get it. You don't like Go. Some of us do, and would rather have a productive discussion about how to take advantage of it's features and avoid the traps rather than get into a pointless debate about a language that we are highly unlikely to ever use. (after this discussion, I certainly never will) You are giving the Haskell community a bad image with this kind of behavior, and I kindly request that you not reply to any more of my comments with anything to do with Haskell.

agentS 13y ago

> I think people tend to underestimate the amount of time they spend on problems... Again, the implication is that people who use languages with looser type-systems than Haskell spend lots of time dealing with the problems that you mention. In my experience, that is not the case. You can claim that I'm underestimating the impact of such bugs if you'd like. > When you implement a red-black-tree, do you not spend any time testing your invariants? Testing is, as far as I can tell, the reason that these problems don't come up. In the process of solving all of those problems I listed above, you tend to write a bunch of tests that exercise the same code that is run in production. > It's weird that you bring Twitter as an example, as they canned a dynamic language solution for a static language that is in many ways very similar to Haskell. I assure you that this transition is far less complete than you might think, and even when complete, will have more Java than Scala. Note that both of these languages allow shared mutable data, both allow null pointers. > They all fail to scale well, both performance-wise and maintenance-wise. Statically-typed systems scale far better along both of these axis. Oh, I agree. Go is statically-typed. However, you're advocating going even further along the spectrum, and I'm saying that going further brings diminishing returns, and starts costing you in terms of available engineers, and your productivity in writing code. I think Go occupies a good point along this spectrum, where I can write robust code without arguing with a compiler.

Peaker 13y ago
> Testing is, as far as I can tell, the reason that these problems don't come up. Testing is a cost. It is more code to write, more code to maintain. It gives no guarantees about correctness, even of the exact feature under test. Consider the 10 lines starting from https://github.com/yairchu/red-black-tree/blob/master/RedBlackTree.hs#L27 https://github.com/yairchu/red-black-tree/blob/master/RedBla... They guarantee the correctness of the invariants of the Red Black Tree, and they easily replace hundreds of lines of test code which give no guarantee. We might still need to write tests, but a lot fewer of them. Also, those we write will give us far more "bang for buck" because we can use QuickCheck property testing. > Note that both of these languages allow shared mutable data, both allow null pointers. Scala shuns null - and only has it for Java interop. All Scala developers I've discussed this with program as if null did not exist, and never use it to signify lack of a value. > I think Go occupies a good point along this spectrum, where I can write robust code without arguing with a compiler. When "arguing with a compiler", you're really being faced with bugs now rather than later, when the code is no longer in your head - or worse, in production. If the type checker rejects your program, it is almost certainly broken, and it is better to "argue with a compiler" than to just compile and get a runtime error later. Availability of engineers is a good point, though as a Haskeller, I know both companies seeking Haskell employees and Haskellers seeking employment (preferably in Haskell). Consider the flip-side of the engineers availability is the "Python paradox".