9 ms·

I've started to feel the same way. I feel like a lot of developers would be better off in a dynamically-typed language because it is such common practice to com

I've started to feel the same way. I feel like a lot of developers would be better off in a dynamically-typed language because it is such common practice to completely subvert the type system and there are such strong resources available for improving testing practices. My last job was in C#, and it seemed like so many things were stringly typed, entirely nullable, or used something else to weaken the type system. In addition to this failure to use the type systems, testing is becoming a much more rich environment. I think popular resources on effective testing are much better and numerous than popular resources on effective typing. There are great books and tools around helping developers test their software more thoroughly and efficiently. Comparing these testing resources with typing resources, the closest popular book I can think of for typing is Design Patterns, and I don't think most popular type systems are built with the program correctness as a top priority. I think rich type systems like haskell's will play more of a role in the future, and I think current users of these systems do experience a benefit. But if you have only ever done dynamically typed programming or used Java/C#, you are probably going to improve your correctness more over the next year by using a property based testing tool like propr (ruby), hypothesis (python), fscheck (.net), scalacheck (jvm), or jsverify (js), spec (clojure).

DRMacIver 10y ago
FWIW, rantly (https://github.com/abargnesi/rantly https://github.com/abargnesi/rantly) rather than propr seems to be the most active and usable Ruby property based testing library. (I maintain a list here: http://hypothesis.works/articles/quickcheck-in-every-language/ http://hypothesis.works/articles/quickcheck-in-every-languag...)
- natec425 10y ago
  Ah. Thank you for the links. Also, thanks for hypothesis.
- LeonidasXIV 10y ago
  For OCaml I'd argue that the canonical QuickCheck is https://github.com/vincent-hugot/iTeML https://github.com/vincent-hugot/iTeML (aka qtest). It looks like it is a unit test tool (which it also is), but it has merged in QCheck which I have used before.
d357r0y3r 10y ago
> My last job was in C#, and it seemed like so many things were stringly typed, entirely nullable, or used something else to weaken the type system. This sounds like C# as written by people that don't really know or like C#. If you're stuffing everything into strings or a dynamic, you missed the point of the type system in a very serious way. > In addition to this failure to use the type systems, testing is becoming a much more rich environment. I think popular resources on effective testing are much better and numerous than popular resources on effective typing. There are great books and tools around helping developers test their software more thoroughly and efficiently. Comparing these testing resources with typing resources, the closest popular book I can think of for typing is Design Patterns, and I don't think most popular type systems are built with the program correctness as a top priority. There is some overlap between problems that can solved by type systems and test suites, but there are many problems that can only be caught by one or the other. It also strikes me as strange that people can't be bothered to use the type system provided by the language, but they can be bothered to maintain and add unit tests for their programs. Correctness enforced by types is fused with the code; if you get the types right, you should be all set. There's no additional maintenance beyond making sure that the code compiles.
- deleted 10y ago
  [deleted]
- natec425 10y ago
  > This sounds like C# as written by people that don't really know or like C#. If you're stuffing everything into strings or a dynamic, you missed the point of the type system in a very serious way. I agree, but I think it is the reality. Software development is a job, not divine appointment. And assuming it is reality, I think the best short term gain those developers isn't doubling down on type systems. > It also strikes me as strange that people can't be bothered to use the type system provided by the language, but they can be bothered to maintain and add unit tests for their programs. Correctness enforced by types is fused with the code; if you get the types right, you should be all set. There's no additional maintenance beyond making sure that the code compiles. I'm totally with you. I remember a friend being so impressed when a hypothesis test caught a bug in an example that I set up. The funny thing was that I made the example from a function over an F# Union. A lot of people seem to get super irritated by compiler errors but seem to be really impressed by clever testing. I think it has to do with the error messages. Property based testing frameworks tend to show you the simplest concrete example of your error. Type checkers tend to show you the most abstract example of your error. Maybe if type checkers started to to incorporate more concrete examples of error, people would generally find them more appealing.
FLUX-YOU 10y ago
>My last job was in C#, and it seemed like so many things were stringly typed, entirely nullable, or used something else to weaken the type system. I see this happen when a bad database design was born before the C# code, e.g. varchar NULL types everywhere.
- natec425 10y ago
  That does happen, but I think the issue is more with education around using types. A lot of people nowadays spend a few years in python/js/java/etc before they have the chance to spend time in a community that really embraces types as the fundamental design tool. Also, it is hard to see the benefits of good typing if my first statically typed language is Java and I'm constantly told to cast into and out of Object. So, I put a lot of blame on the way people are taught to program. People tend to have a pretty hard time uprooting years of experience.
  - nsomaru 10y ago
    Could you offer a learning path for one with experience in js/python?
    - natec425 10y ago
      I don't know if i could offer a "path", but here are a few ideas to try out: 1. Start using hypothesis or jsverify. 2. Play around with Elm. 3. Participate in a community that highly values types. ## Properties vs Types Just to explain a bit, types and properties are about program correctness. So they serve the same purpose for us. Types are essentially properties that your type checker can prove for you. Sometimes it is hard or impossible to prove something, so you might reach for property based tests to "approximate" the proof. So when I'm thinking about my code correctness: 1. write a type where I can 2. write a property where I want to write a type 3. write examples to keep me grounded Property based testing frameworks will help you move up that ladder. ## Elm Of course, it will also be helpful to start actually leveraging a type system. I think Elm is a good option for people who are new to using types this way. It has a powerful, but relatively simple, type system that can help you learn good type design without having to deal with all of the features that Haskell/Scala/Rust/Ocaml/etc would have. Also, it has pretty great compiler error messages. So it should be less intimidating than a lot of nearby options. ## Community Community might be the most important element. Participating in a community that values types (again, I suggest Elm) will be a great investment. Downloading Elm and a property based testing library could be a recipe to feel overwhelmed. Be sure to have a slack channel/mailing list/irc channel ready to help you when you start to feel overwhelmed.

DRMacIver 10y ago

FWIW, rantly (https://github.com/abargnesi/rantly https://github.com/abargnesi/rantly) rather than propr seems to be the most active and usable Ruby property based testing library. (I maintain a list here: http://hypothesis.works/articles/quickcheck-in-every-language/ http://hypothesis.works/articles/quickcheck-in-every-languag...)

natec425 10y ago
Ah. Thank you for the links. Also, thanks for hypothesis.
LeonidasXIV 10y ago
For OCaml I'd argue that the canonical QuickCheck is https://github.com/vincent-hugot/iTeML https://github.com/vincent-hugot/iTeML (aka qtest). It looks like it is a unit test tool (which it also is), but it has merged in QCheck which I have used before.

d357r0y3r 10y ago

> My last job was in C#, and it seemed like so many things were stringly typed, entirely nullable, or used something else to weaken the type system. This sounds like C# as written by people that don't really know or like C#. If you're stuffing everything into strings or a dynamic, you missed the point of the type system in a very serious way. > In addition to this failure to use the type systems, testing is becoming a much more rich environment. I think popular resources on effective testing are much better and numerous than popular resources on effective typing. There are great books and tools around helping developers test their software more thoroughly and efficiently. Comparing these testing resources with typing resources, the closest popular book I can think of for typing is Design Patterns, and I don't think most popular type systems are built with the program correctness as a top priority. There is some overlap between problems that can solved by type systems and test suites, but there are many problems that can only be caught by one or the other. It also strikes me as strange that people can't be bothered to use the type system provided by the language, but they can be bothered to maintain and add unit tests for their programs. Correctness enforced by types is fused with the code; if you get the types right, you should be all set. There's no additional maintenance beyond making sure that the code compiles.

deleted 10y ago
[deleted]
natec425 10y ago
> This sounds like C# as written by people that don't really know or like C#. If you're stuffing everything into strings or a dynamic, you missed the point of the type system in a very serious way. I agree, but I think it is the reality. Software development is a job, not divine appointment. And assuming it is reality, I think the best short term gain those developers isn't doubling down on type systems. > It also strikes me as strange that people can't be bothered to use the type system provided by the language, but they can be bothered to maintain and add unit tests for their programs. Correctness enforced by types is fused with the code; if you get the types right, you should be all set. There's no additional maintenance beyond making sure that the code compiles. I'm totally with you. I remember a friend being so impressed when a hypothesis test caught a bug in an example that I set up. The funny thing was that I made the example from a function over an F# Union. A lot of people seem to get super irritated by compiler errors but seem to be really impressed by clever testing. I think it has to do with the error messages. Property based testing frameworks tend to show you the simplest concrete example of your error. Type checkers tend to show you the most abstract example of your error. Maybe if type checkers started to to incorporate more concrete examples of error, people would generally find them more appealing.

FLUX-YOU 10y ago

>My last job was in C#, and it seemed like so many things were stringly typed, entirely nullable, or used something else to weaken the type system. I see this happen when a bad database design was born before the C# code, e.g. varchar NULL types everywhere.

natec425 10y ago
That does happen, but I think the issue is more with education around using types. A lot of people nowadays spend a few years in python/js/java/etc before they have the chance to spend time in a community that really embraces types as the fundamental design tool. Also, it is hard to see the benefits of good typing if my first statically typed language is Java and I'm constantly told to cast into and out of Object. So, I put a lot of blame on the way people are taught to program. People tend to have a pretty hard time uprooting years of experience.
- nsomaru 10y ago
  Could you offer a learning path for one with experience in js/python?
  - natec425 10y ago
    I don't know if i could offer a "path", but here are a few ideas to try out: 1. Start using hypothesis or jsverify. 2. Play around with Elm. 3. Participate in a community that highly values types. ## Properties vs Types Just to explain a bit, types and properties are about program correctness. So they serve the same purpose for us. Types are essentially properties that your type checker can prove for you. Sometimes it is hard or impossible to prove something, so you might reach for property based tests to "approximate" the proof. So when I'm thinking about my code correctness: 1. write a type where I can 2. write a property where I want to write a type 3. write examples to keep me grounded Property based testing frameworks will help you move up that ladder. ## Elm Of course, it will also be helpful to start actually leveraging a type system. I think Elm is a good option for people who are new to using types this way. It has a powerful, but relatively simple, type system that can help you learn good type design without having to deal with all of the features that Haskell/Scala/Rust/Ocaml/etc would have. Also, it has pretty great compiler error messages. So it should be less intimidating than a lot of nearby options. ## Community Community might be the most important element. Participating in a community that values types (again, I suggest Elm) will be a great investment. Downloading Elm and a property based testing library could be a recipe to feel overwhelmed. Be sure to have a slack channel/mailing list/irc channel ready to help you when you start to feel overwhelmed.