4 ms·

Sounds to me like you're doing it wrong. I write scientific Python code every single day for work and I (nor anyone else who works with me) never run in to thos

by kisielk 15y ago

Sounds to me like you're doing it wrong. I write scientific Python code every single day for work and I (nor anyone else who works with me) never run in to those kinds of problems. Why are you running simulations that take an hour before you even know your code work? Where are your unit and integration tests? Every piece of our software stack has (or should have...) tests that verify all the bits fit together correctly in a matter of seconds or perhaps minutes tops. Strong typing would be nice to have sometimes, but in practice I think it limits the amount of ad-hoc data analysis and exploration you can do while trying to piece together a piece of software. I think the scientists in our company would murder the software engineering team if they had to deal with strong typing to get things done.

gaius 15y ago
The point is that a whole class of things that you would have to write unit tests for, you get "for free" with strong typing, and for a lot of the others, there's QuickCheck. Or as the old saying goes, why get a dog and bark yourself?
- vidarh 15y ago
  Except you don't get them "for free". You get them in the form a ton of restrictions on you that you need to be mindful of when writing it in the first place. You just pay for it in different ways. The biggest difference is that in dynamic languages, you can sometimes get away with being lazy and not writing the tests to verify the things static languages enforce to varying degrees (whether or not that's a good thing is another issue).
  - SkyMarshal 15y ago
    Haskell frontloads type considerations and tests via a required, tightly-coupled type system. Dynamic languages backload them via optional testing. In either case you still have to think about those issues when correctness is a requirement. When it isn't (ad-hoc analysis, prototyping), dynamic languages are more pleasant to work with. When it is a requirement, Haskell is uniquely powerful. Problem is, many projects are subject to both requirements at the different times. Exploratory at the start, strict once the problem to be solved is identified. Know the tradeoffs and pick your poison.
  - nightski 15y ago
    Who wants to explore errors? Seriously a well designed array library would not limit exploration at all while preventing one from wasting time with trivial mistakes.
radarsat1 15y ago
Funny that you mention ad-hoc data analysis in the bottom part of your comment, because while i was reading the top part, i was thinking "ha, no _way_ am i going to be writing extensive unit tests while doing exploratory data analysis..." For what it's worth, of course i do rudimentary testing before running things for an hour, but there's often small things that are missed that don't show up on smaller datasets for one reason or another. Of course it couldn't catch every possible runtime error, but in my real-world experience I have definitely come across things that would have shown up during compilation with strong type, _especially_ if the array sizes were encoded into the type system. There's something practical about how Haskell makes you think about program structure and data representations ahead of time instead of it being an afterthought; but I agree, this can also be restrictive when you are being exploratory.

by kisielk 15y ago

gaius 15y ago

The point is that a whole class of things that you would have to write unit tests for, you get "for free" with strong typing, and for a lot of the others, there's QuickCheck. Or as the old saying goes, why get a dog and bark yourself?

vidarh 15y ago
Except you don't get them "for free". You get them in the form a ton of restrictions on you that you need to be mindful of when writing it in the first place. You just pay for it in different ways. The biggest difference is that in dynamic languages, you can sometimes get away with being lazy and not writing the tests to verify the things static languages enforce to varying degrees (whether or not that's a good thing is another issue).
- SkyMarshal 15y ago
  Haskell frontloads type considerations and tests via a required, tightly-coupled type system. Dynamic languages backload them via optional testing. In either case you still have to think about those issues when correctness is a requirement. When it isn't (ad-hoc analysis, prototyping), dynamic languages are more pleasant to work with. When it is a requirement, Haskell is uniquely powerful. Problem is, many projects are subject to both requirements at the different times. Exploratory at the start, strict once the problem to be solved is identified. Know the tradeoffs and pick your poison.
- nightski 15y ago
  Who wants to explore errors? Seriously a well designed array library would not limit exploration at all while preventing one from wasting time with trivial mistakes.

radarsat1 15y ago

Funny that you mention ad-hoc data analysis in the bottom part of your comment, because while i was reading the top part, i was thinking "ha, no _way_ am i going to be writing extensive unit tests while doing exploratory data analysis..." For what it's worth, of course i do rudimentary testing before running things for an hour, but there's often small things that are missed that don't show up on smaller datasets for one reason or another. Of course it couldn't catch every possible runtime error, but in my real-world experience I have definitely come across things that would have shown up during compilation with strong type, _especially_ if the array sizes were encoded into the type system. There's something practical about how Haskell makes you think about program structure and data representations ahead of time instead of it being an afterthought; but I agree, this can also be restrictive when you are being exploratory.