6 ms·

This is an argument for unit tests, not for a statically typed language. Type errors tend to be very few and far between compared to logic errors. Multiple pr

This is an argument for unit tests, not for a statically typed language. Type errors tend to be very few and far between compared to logic errors. Multiple processes in most web applications are best handled by a pre-forking webserver in front of something like mod_wsgi, and using an engine like Celery for asynchronous and long-running operations on the backend, often launched with something like supervisor. I do take issue with some parts of the article, namely saying there is a good type system (there's not, but it's all fine, duck typing, etc) and that twisted is a good framework. It is definitely true however that Python is a great fit for all kinds of serious applications, but with all things, it takes discipline.

Retra 12y ago
What is the benefit to using a dynamically typed language if you have to spend all your time writing tests and verifying the static properties of your code?
- Vaskivo 12y ago
  The idea is that writing code + writing tests in a dynamically typed language is easier and faster just writing code in a statically typed language. (Of course it depends on the languages in question, the programmers and a number of other factors)
- spdy 12y ago
  Mainly the boilerplate other languages force upon you. Whenever i look at Java Code i start to chuckle. Its so much more information that you need to load into your head. To quote a picture from the post: https://www.paypal-engineering.com/wordpress/wp-content/uploads/2014/12/cpp_py_medium.png https://www.paypal-engineering.com/wordpress/wp-content/uplo... And its not like you need static typing everywhere just in some places its better to enforce it for your own sanity. Type hinting looks like a good way to solve this problem in python.
  - Retra 12y ago
    That image isn't really a fair comparison (in that C++ / Java aren't the only statically typed languages.) I imagine a statically typed Python dialect would only have an extra 15 or so lines, and the benefits would be numerous. I love python as much as anyone, but having to keep a reference manual handy just to use someone's library because they had the audacity to use a variable is not my idea of a fun time. EDIT: I'm probably exaggerating too much. Would I use Python in a large, complicated, multi-developer project? Yes, I would. And my only real complaint would probably be that I like static typing so much that I'd miss it.
    - viraptor 12y ago
      > I imagine a statically typed Python dialect would only have an extra 15 or so lines Actually you can have a statically typed Python if you want. Have a look at http://docs.cython.org/src/quickstart/cythonize.html http://docs.cython.org/src/quickstart/cythonize.html All type declarations are optional. It compiles modules to versions completely interoperable with the rest of Python code. They're importable, behave as you'd expect, etc.
  - qubitcoder 12y ago
    Consider Haskell. It's about as anti-boilerplate as they come. And with automatic type inference.
- mpdehaan2 12y ago
  I've never had to spend all my time doing that. I am making the case that type errors (passing a hash instead of an int, etc) are NOT one of the major causes of errors in software development. I'm apt to screw up other things, but that's not one of them.
  - marcosdumay 12y ago
    > I am making the case that type errors are NOT one of the major causes of errors in software development. That's symptom of a bad typing system. I'm with a moderately sized Haskell codebase right now and type errors represent the biggest share of errors on it by a huge margin - several times bigger than runtime bugs.
    - mpdehaan2 12y ago
      Haskell makes programming into a duel with the type system specifiers.
      - tome 12y ago
        I prefer to think of it as a dialectic.
      - marcosdumay 12y ago
        Yes, it does. That duel replaces a chase on unknown and strange runtime bugs. Sometimes it's a win, other times it isn't.
    - mpdehaan2 12y ago
      Haskell makes programming into a duel with the type system specifiers.
- arethuza 12y ago
  Shouldn't you be writing tests anyway? NB I'm not being flippant - I've been using Python for a couple of years and appreciate the lack of boilerplate compared to many other languages and if there are "type" problems my unit tests, which I will be writing anyway, find them. Using an IDE like PyCharm does a good job of warning you about type problems at development time so I don't have a lot of run time type problems.
  - Retra 12y ago
    Yeah, you should, but you don't have to check trivial things like "is this a list?"
    - arethuza 12y ago
      Well, I wouldn't write a unit test for that - I would write a unit test for the high level observable behavior and if I get it wrong that something is a list then it'll break and my unit test will fail.
      - viraptor 12y ago
        I think that's closer to functional testing than unit testing though...
lmm 12y ago
> This is an argument for unit tests, not for a statically typed language. Static typing is like unit tests that take no maintenance. > Type errors tend to be very few and far between compared to logic errors. False distinction. If you just take your python code and write it line-by-line in another language, sure, you won't gain much. But if you actually work with the language, you turn logic errors into type errors. See e.g. http://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ http://spin.atomicobject.com/2014/12/09/typed-language-tdd-p... , and note that that's a lot more verbose than it would be in a modern language with type inference, higher kinds and so on.
- crdoconnor 12y ago
  >Static typing is like unit tests that take no maintenance. And makes your code 20% longer, which makes for a lot of extra fun not-really-so-cost-free-after-all maintenance. I found the complaint that it finds bugs earlier (at compilation time!) ironic given that, in my experience, running a suite of unit tests takes less time in python than, say, compiling does in Java, never mind compiling and running tests.
  - Dewie 12y ago
    > And makes your code 20% longer, which makes for a lot of extra fun not-really-so-cost-free-after-all maintenance. Just 20%? Sounds like a good deal, considering those that brag that brag that "over half of our code base are just tests!". I don't know if that kind of thing is fashionable or widespread any more, though.
  - jamiltron 12y ago
    > And makes your code 20% longer Not necessarily true, especially if you are using a language with type-inference or you are able to encode your logic in types. Additionally - what do you think unit tests are? They aren't additional code you have to write? I'm not someone who thinks types completely reduce the need for testing, but I absolutely do not get why dynamic language fans are like "Uhg, I HATE having to write types", but then end up basically reimplementing a type system in a much more verbose testing framework.
Dewie 12y ago
> This is an argument for unit tests, not for a statically typed language. > Type errors tend to be very few and far between compared to logic errors. The divide between type errors and logic errors is entirely dependent on the language and the discipline/inclination of the developers. In some languages, what you might think of as "logic errors" can easily be moved to "type errors". And in that regard, the difference between what is unit testable and statically typeable is also entirely dependent on the language and the discipline/inclination of the developer. So what might have to be expressed as unit tests in one language, might be checked by the static type system in another language. But I can understand how some people might think that static type systems are only for catching things like "error: expected addition of integers, but got attempt at adding an integer with a FireTruck". ;)

Retra 12y ago

What is the benefit to using a dynamically typed language if you have to spend all your time writing tests and verifying the static properties of your code?

Vaskivo 12y ago
The idea is that writing code + writing tests in a dynamically typed language is easier and faster just writing code in a statically typed language. (Of course it depends on the languages in question, the programmers and a number of other factors)
spdy 12y ago
Mainly the boilerplate other languages force upon you. Whenever i look at Java Code i start to chuckle. Its so much more information that you need to load into your head. To quote a picture from the post: https://www.paypal-engineering.com/wordpress/wp-content/uploads/2014/12/cpp_py_medium.png https://www.paypal-engineering.com/wordpress/wp-content/uplo... And its not like you need static typing everywhere just in some places its better to enforce it for your own sanity. Type hinting looks like a good way to solve this problem in python.
- Retra 12y ago
  That image isn't really a fair comparison (in that C++ / Java aren't the only statically typed languages.) I imagine a statically typed Python dialect would only have an extra 15 or so lines, and the benefits would be numerous. I love python as much as anyone, but having to keep a reference manual handy just to use someone's library because they had the audacity to use a variable is not my idea of a fun time. EDIT: I'm probably exaggerating too much. Would I use Python in a large, complicated, multi-developer project? Yes, I would. And my only real complaint would probably be that I like static typing so much that I'd miss it.
  - viraptor 12y ago
    > I imagine a statically typed Python dialect would only have an extra 15 or so lines Actually you can have a statically typed Python if you want. Have a look at http://docs.cython.org/src/quickstart/cythonize.html http://docs.cython.org/src/quickstart/cythonize.html All type declarations are optional. It compiles modules to versions completely interoperable with the rest of Python code. They're importable, behave as you'd expect, etc.
- qubitcoder 12y ago
  Consider Haskell. It's about as anti-boilerplate as they come. And with automatic type inference.
mpdehaan2 12y ago
I've never had to spend all my time doing that. I am making the case that type errors (passing a hash instead of an int, etc) are NOT one of the major causes of errors in software development. I'm apt to screw up other things, but that's not one of them.
- marcosdumay 12y ago
  > I am making the case that type errors are NOT one of the major causes of errors in software development. That's symptom of a bad typing system. I'm with a moderately sized Haskell codebase right now and type errors represent the biggest share of errors on it by a huge margin - several times bigger than runtime bugs.
  - mpdehaan2 12y ago
    Haskell makes programming into a duel with the type system specifiers.
    - tome 12y ago
      I prefer to think of it as a dialectic.
    - marcosdumay 12y ago
      Yes, it does. That duel replaces a chase on unknown and strange runtime bugs. Sometimes it's a win, other times it isn't.
  - mpdehaan2 12y ago
    Haskell makes programming into a duel with the type system specifiers.
arethuza 12y ago
Shouldn't you be writing tests anyway? NB I'm not being flippant - I've been using Python for a couple of years and appreciate the lack of boilerplate compared to many other languages and if there are "type" problems my unit tests, which I will be writing anyway, find them. Using an IDE like PyCharm does a good job of warning you about type problems at development time so I don't have a lot of run time type problems.
- Retra 12y ago
  Yeah, you should, but you don't have to check trivial things like "is this a list?"
  - arethuza 12y ago
    Well, I wouldn't write a unit test for that - I would write a unit test for the high level observable behavior and if I get it wrong that something is a list then it'll break and my unit test will fail.
    - viraptor 12y ago
      I think that's closer to functional testing than unit testing though...

lmm 12y ago

> This is an argument for unit tests, not for a statically typed language. Static typing is like unit tests that take no maintenance. > Type errors tend to be very few and far between compared to logic errors. False distinction. If you just take your python code and write it line-by-line in another language, sure, you won't gain much. But if you actually work with the language, you turn logic errors into type errors. See e.g. http://spin.atomicobject.com/2014/12/09/typed-language-tdd-part1/ http://spin.atomicobject.com/2014/12/09/typed-language-tdd-p... , and note that that's a lot more verbose than it would be in a modern language with type inference, higher kinds and so on.

crdoconnor 12y ago
>Static typing is like unit tests that take no maintenance. And makes your code 20% longer, which makes for a lot of extra fun not-really-so-cost-free-after-all maintenance. I found the complaint that it finds bugs earlier (at compilation time!) ironic given that, in my experience, running a suite of unit tests takes less time in python than, say, compiling does in Java, never mind compiling and running tests.
- Dewie 12y ago
  > And makes your code 20% longer, which makes for a lot of extra fun not-really-so-cost-free-after-all maintenance. Just 20%? Sounds like a good deal, considering those that brag that brag that "over half of our code base are just tests!". I don't know if that kind of thing is fashionable or widespread any more, though.
- jamiltron 12y ago
  > And makes your code 20% longer Not necessarily true, especially if you are using a language with type-inference or you are able to encode your logic in types. Additionally - what do you think unit tests are? They aren't additional code you have to write? I'm not someone who thinks types completely reduce the need for testing, but I absolutely do not get why dynamic language fans are like "Uhg, I HATE having to write types", but then end up basically reimplementing a type system in a much more verbose testing framework.

Dewie 12y ago

> This is an argument for unit tests, not for a statically typed language. > Type errors tend to be very few and far between compared to logic errors. The divide between type errors and logic errors is entirely dependent on the language and the discipline/inclination of the developers. In some languages, what you might think of as "logic errors" can easily be moved to "type errors". And in that regard, the difference between what is unit testable and statically typeable is also entirely dependent on the language and the discipline/inclination of the developer. So what might have to be expressed as unit tests in one language, might be checked by the static type system in another language. But I can understand how some people might think that static type systems are only for catching things like "error: expected addition of integers, but got attempt at adding an integer with a FireTruck". ;)