4 ms·

That's actually a great argument for static typing! Let's say your distant input component is changed and in some cases doesn't send lists of lists, but one fla

by adwn 10y ago

That's actually a great argument for static typing! Let's say your distant input component is changed and in some cases doesn't send lists of lists, but one flattened list. With Haskell, the compiler will immediately notify you of this bug, while with Python, you have to hope that your integration tests are sufficiently exhaustive to catch this, or you'll catch it in production. Whoops. Like I said, the coupling is still there, but it's hidden by dynamic typing.

jstimpfle 10y ago
In most cases you will not be able to write your code in Haskell in the first place. Do try to write a database query construction kit that deals with schemata read at runtime (a very reasonable requirement). Even for a non-genius it's pretty easy to make something that works, with dynamic types. http://jstimpfle.de/projects/python-wsl/main.html http://jstimpfle.de/projects/python-wsl/main.html I don't think something like that can be created in Haskell (without resorting to dynamic types).
- Filligree 10y ago
  You always have dynamic typing as an escape. If that's what it takes, then that's an option, but I think in practice you'd be able to keep that sort of purity to a small portion of the program. Haskell is a research language, which sometimes shows in the libraries. I'm not sure if I'd recommend it for general use; I'm more partial to Kotlin these days. It's definitely an interesting approach, though, and anyone who's designing languages ought to make themselves familiar.
- Filligree 10y ago
  You always have dynamic typing as an escape. If that's what it takes, then that's an option, but I think in practice you'd be able to keep that sort of purity to a small portion of the program. Haskell is a research language, which sometimes shows in the libraries. I'm not sure if I'd recommend it for general use; I'm more partial to Kotlin these days. It's definitely an interesting approach, though, and anyone who's designing languages ought to make themselves familiar.
crdoconnor 10y ago
>with Python, you have to hope that your integration tests are sufficiently exhaustive to catch this If there is a border between code I trust and code I don't trust I put some sort of sanity type-checking to catch this type of problem early. This usually gives me immediate notification of certain classes of bug when a test invokes that code. I also put other forms of sanity checking in that are not type-specific - e.g. check a file exists before passing it on to a method that will read it. I am not sure if this style of programming entirely mimics haskell's main USP in python, but it sure makes tracking down certain kinds of error much quicker. Integration tests attack the problem from one direction and strict type checking (whether static or dynamic) attacks the problem from the other direction. IMHO you have to attack from both directions. Ever increasing integration test coverage is obviously subject to diminishing returns (in terms of bugs caught/investment), but so is ever stricter type systems.
- coldtea 10y ago
  >If there is a border between code I trust and code I don't trust I put some sort of sanity type-checking to catch this type of problem early. This usually gives me immediate notification of certain classes of bug when a test invokes that code. That's still on a "due dilligence" basis, and too late.
  - crdoconnor 10y ago
    >too late. If you are severely lacking in test coverage. Otherwise no, it's not too late. Slow compilers that take ~2-10 minutes in statically typed languages give slower feedback than test suites that take seconds in dynamically typed languages. This inhibits development speed.
    - virmundi 10y ago
      As an abstract statement, I can only agree. In reality, modern compilers can do some incrementally. So when you make a change in file A, the compiler will only change things dependent on A. In practice this chains a small number of file recompiles. The end result is an instantaneous feedback loop. I get this all the time in Eclipse. Eclipse doesn't really try to do a full compile. It just updates as above. This allows me to see within a few ms if my code compiles. If it doesn't, red line and the reason. A full compile on a about 40k classes without tests (just compile, static checking) with Maven on my 2013 MBP is about 5 seconds. So still pretty fast. Probably equivalently as a fast as your dynamic language + tests. The same is true for hot swapping code. The JVM supports this a bit. Spring Boot supports it more. JRebel supports it entirely. When making a micro service or even a website in Spring Boot STS (Eclipse + Spring features), the run time will restart. Clocked time is 1.2 seconds. Not too bad. For changes to just HTML/CSS/templates/ etc, no reboot time.
jlarocco 10y ago
The problem you're describing has little to do with static or dynamic typing, and more to do with poor development practices. Regardless of language used, if a person is changing the interface to something (either in internal code, or by upgrading a 3rd party library) then it's their responsibility to make sure the change is propagated to all the places in the codebase that use the interface. It doesn't matter much if they do that by running the compiler, grepping the code, or running a test suite.
- spion 10y ago
  What ends up happening in practice instead is that large projects using dynamic languages are hesitant to change anything like that. So if you didn't know the problem domain sufficiently to guess all the interfaces up front correctly, you end up in a pretty bad place. In contrast, making such changes when you have types is an order of magnitude easier. The equivalent would be to have integration tests that exercise the entire system with all its functions and code paths checking for basic data compatibility. Seems like a worthwhile thing to have to me, as its not easy to achieve at all. Not to mention you have a tool to answer "if I change X, what will be affected" - even if you are not changing the type. Just pretend that you changed the type of X (e.g. change "name" to "firstName"), and see all the places that don't compile now. So much better than grep!
  - jstimpfle 10y ago
    Most architects of large software projects agree, in my perception. As a counterpoint, I figure that something is wrong if changes routinely affect large parts of the code. The idea is that data is "in the interfaces" instead of global. Except for a few "god objects" changes should be pretty local.
    - spion 10y ago
      Yes, what is wrong is our understanding of the problem domain. Or even the stakeholder's real understanding of the problem domain :) Maybe we should stop working on types and focus on easy, high quality languages and tools which will enable other professionals to easily solve problems from their domain doing all the programming themselves. And not just languages - heck, it takes 2 hours just to set up a basic React Native stack for a "Hello World" app.

by adwn 10y ago

jstimpfle 10y ago

In most cases you will not be able to write your code in Haskell in the first place. Do try to write a database query construction kit that deals with schemata read at runtime (a very reasonable requirement). Even for a non-genius it's pretty easy to make something that works, with dynamic types. http://jstimpfle.de/projects/python-wsl/main.html http://jstimpfle.de/projects/python-wsl/main.html I don't think something like that can be created in Haskell (without resorting to dynamic types).

Filligree 10y ago
You always have dynamic typing as an escape. If that's what it takes, then that's an option, but I think in practice you'd be able to keep that sort of purity to a small portion of the program. Haskell is a research language, which sometimes shows in the libraries. I'm not sure if I'd recommend it for general use; I'm more partial to Kotlin these days. It's definitely an interesting approach, though, and anyone who's designing languages ought to make themselves familiar.
Filligree 10y ago
You always have dynamic typing as an escape. If that's what it takes, then that's an option, but I think in practice you'd be able to keep that sort of purity to a small portion of the program. Haskell is a research language, which sometimes shows in the libraries. I'm not sure if I'd recommend it for general use; I'm more partial to Kotlin these days. It's definitely an interesting approach, though, and anyone who's designing languages ought to make themselves familiar.

crdoconnor 10y ago

>with Python, you have to hope that your integration tests are sufficiently exhaustive to catch this If there is a border between code I trust and code I don't trust I put some sort of sanity type-checking to catch this type of problem early. This usually gives me immediate notification of certain classes of bug when a test invokes that code. I also put other forms of sanity checking in that are not type-specific - e.g. check a file exists before passing it on to a method that will read it. I am not sure if this style of programming entirely mimics haskell's main USP in python, but it sure makes tracking down certain kinds of error much quicker. Integration tests attack the problem from one direction and strict type checking (whether static or dynamic) attacks the problem from the other direction. IMHO you have to attack from both directions. Ever increasing integration test coverage is obviously subject to diminishing returns (in terms of bugs caught/investment), but so is ever stricter type systems.

coldtea 10y ago
>If there is a border between code I trust and code I don't trust I put some sort of sanity type-checking to catch this type of problem early. This usually gives me immediate notification of certain classes of bug when a test invokes that code. That's still on a "due dilligence" basis, and too late.
- crdoconnor 10y ago
  >too late. If you are severely lacking in test coverage. Otherwise no, it's not too late. Slow compilers that take ~2-10 minutes in statically typed languages give slower feedback than test suites that take seconds in dynamically typed languages. This inhibits development speed.
  - virmundi 10y ago
    As an abstract statement, I can only agree. In reality, modern compilers can do some incrementally. So when you make a change in file A, the compiler will only change things dependent on A. In practice this chains a small number of file recompiles. The end result is an instantaneous feedback loop. I get this all the time in Eclipse. Eclipse doesn't really try to do a full compile. It just updates as above. This allows me to see within a few ms if my code compiles. If it doesn't, red line and the reason. A full compile on a about 40k classes without tests (just compile, static checking) with Maven on my 2013 MBP is about 5 seconds. So still pretty fast. Probably equivalently as a fast as your dynamic language + tests. The same is true for hot swapping code. The JVM supports this a bit. Spring Boot supports it more. JRebel supports it entirely. When making a micro service or even a website in Spring Boot STS (Eclipse + Spring features), the run time will restart. Clocked time is 1.2 seconds. Not too bad. For changes to just HTML/CSS/templates/ etc, no reboot time.

jlarocco 10y ago

The problem you're describing has little to do with static or dynamic typing, and more to do with poor development practices. Regardless of language used, if a person is changing the interface to something (either in internal code, or by upgrading a 3rd party library) then it's their responsibility to make sure the change is propagated to all the places in the codebase that use the interface. It doesn't matter much if they do that by running the compiler, grepping the code, or running a test suite.

spion 10y ago
What ends up happening in practice instead is that large projects using dynamic languages are hesitant to change anything like that. So if you didn't know the problem domain sufficiently to guess all the interfaces up front correctly, you end up in a pretty bad place. In contrast, making such changes when you have types is an order of magnitude easier. The equivalent would be to have integration tests that exercise the entire system with all its functions and code paths checking for basic data compatibility. Seems like a worthwhile thing to have to me, as its not easy to achieve at all. Not to mention you have a tool to answer "if I change X, what will be affected" - even if you are not changing the type. Just pretend that you changed the type of X (e.g. change "name" to "firstName"), and see all the places that don't compile now. So much better than grep!
- jstimpfle 10y ago
  Most architects of large software projects agree, in my perception. As a counterpoint, I figure that something is wrong if changes routinely affect large parts of the code. The idea is that data is "in the interfaces" instead of global. Except for a few "god objects" changes should be pretty local.
  - spion 10y ago
    Yes, what is wrong is our understanding of the problem domain. Or even the stakeholder's real understanding of the problem domain :) Maybe we should stop working on types and focus on easy, high quality languages and tools which will enable other professionals to easily solve problems from their domain doing all the programming themselves. And not just languages - heck, it takes 2 hours just to set up a basic React Native stack for a "Hello World" app.