5 ms·

This is a significant problem for me as well, coming from C++ and Haskell. Even just going through and making a few changes here and there, there’s no way for m

This is a significant problem for me as well, coming from C++ and Haskell. Even just going through and making a few changes here and there, there’s no way for me to know without extensive testing whether my edit was even remotely correct beyond a cursory syntax check. I’ve never had to deal with testing all that heavily in statically typed languages, because I can rely on the type system to do a lot of very helpful static analysis. The lack of basic static knowledge about a Python program is frustrating and discomfiting, and ultimately discourages me from using the language for anything serious.

aangjie 15y ago
+1 on the static type checking problem.. i am beginning to feel very annoyed by the same... have found that writing and maintaining unit test cases help.. but are a PITA nevertheless...
- evincarofautumn 15y ago
  Well, as I see it, more or less every error should be expressible as a type error. In order to actually do that, you’d need full dependent types, and that’s a huge language-design “now you have two problems” feature—compiler authors are understandably uncomfortable with undecidable, non-inferable type systems. Anyway, Haskell and even C++ used intelligently can tell you a lot about your program at the outset, so ultimately your tests can be more focused.
  - aangjie 15y ago
    > more or less every error should be expressible as a type error. Am not sure i agree.. i would like to believe it's true though.... >Haskell have just begun to poke around, like the currying + function composition.. will keep poking...
  - pranjalv123 15y ago
    Yep, I agree with you - although every error should be expressible as a type error, languages like Coq where this is actually possible make writing usable code pretty difficult. I think there's a pretty wide range of middle ground, ranging from C++ to Haskell, where you get the benefit of static types without making it really difficult to write working code.
rue 15y ago
> I’ve never had to deal with testing all that heavily in statically typed languages, Lack of tests means bugs now, or later when you're refactoring. They're pretty essential in static languages, too, although you can certainly lean on the compiler for many things. Anecdotally, my bugs usually aren't caused by having passed in the wrong kind of an object.
- evincarofautumn 15y ago
  Well yeah, to be fair, neither are mine. It’s just irritating to be running a prototype thinking everything is more or less fine, then SPOOM goes a runtime error because you didn’t properly change a method invocation, which could have been caught by a static check and saved you some time. The more tools I have to help me attain my actual goal of writing software that does stuff without spooming, the better.
cdavid 15y ago
I find the focus on dynamic typing a bit fascinating: you don't see people focus so much on it on a discussion about LISP. [EDIT: I meant to say that this most likely reveals something else is at work in the particular case of python]. When a C program compiles, it really does not tell you much about whether it will work or not. Maybe it is a matter of application domains, but I tend to actually spend more time testing C parts of the code compared to the python code. But, in proportion, I spend more time testing in python than in C, because I spend so much less time doing things in python than in C. Haskell is different, because types can be used to enforced constraints in a much better fashion than C/C++/Java/etc… The one part when simple typing systems is useful is refactoring. Doing so in a dynamically typed language is difficult (but possible, as shown by smalltalk, which is supposedly even more dynamic than python).
- evincarofautumn 15y ago
  Lisp’s other useful features just make the particulars of the type system less of an issue. When writing prototypes, I move things around and refactor a lot. Python makes this easy at the cost of certainty about whether it was done right. I don’t write a lot of Lisp, but in my experience refactoring there is quite different: I’m not editing methods and classes, I’m factoring functions and macros. If I were one for supposing, I’d suppose the OO philosophy of Python forces you to create interfaces before you necessarily know that they’re correct, so you end up refactoring them, and there’s poor support for that when no static type system has your back.
  - cdavid 15y ago
    This is already a more interesting discusion. I cannot comment on Lisp, as I have too little experience with it. When you say python forces you to create interfaces, I am not sure I understand. For me, programming is mostly about creating interfaces (as the interface part of API), python or not. When I refactor some C code, static typing does not help me that much, as what's difficult in C is lifetime's object (e.g. ref counting in C extensions), things like that. What is true is that it is easy to write code that is impossible to refactor, because it is full of globals, or "stringified API" (e.g. using a dict instead of objects when the set of keys is supposed to be fixed). But I am afraid people writing this kind of code would write bad code in any language, or are at least very inexperienced in the language.

aangjie 15y ago

+1 on the static type checking problem.. i am beginning to feel very annoyed by the same... have found that writing and maintaining unit test cases help.. but are a PITA nevertheless...

evincarofautumn 15y ago
Well, as I see it, more or less every error should be expressible as a type error. In order to actually do that, you’d need full dependent types, and that’s a huge language-design “now you have two problems” feature—compiler authors are understandably uncomfortable with undecidable, non-inferable type systems. Anyway, Haskell and even C++ used intelligently can tell you a lot about your program at the outset, so ultimately your tests can be more focused.
- aangjie 15y ago
  > more or less every error should be expressible as a type error. Am not sure i agree.. i would like to believe it's true though.... >Haskell have just begun to poke around, like the currying + function composition.. will keep poking...
- pranjalv123 15y ago
  Yep, I agree with you - although every error should be expressible as a type error, languages like Coq where this is actually possible make writing usable code pretty difficult. I think there's a pretty wide range of middle ground, ranging from C++ to Haskell, where you get the benefit of static types without making it really difficult to write working code.

rue 15y ago

> I’ve never had to deal with testing all that heavily in statically typed languages, Lack of tests means bugs now, or later when you're refactoring. They're pretty essential in static languages, too, although you can certainly lean on the compiler for many things. Anecdotally, my bugs usually aren't caused by having passed in the wrong kind of an object.

evincarofautumn 15y ago
Well yeah, to be fair, neither are mine. It’s just irritating to be running a prototype thinking everything is more or less fine, then SPOOM goes a runtime error because you didn’t properly change a method invocation, which could have been caught by a static check and saved you some time. The more tools I have to help me attain my actual goal of writing software that does stuff without spooming, the better.

cdavid 15y ago

I find the focus on dynamic typing a bit fascinating: you don't see people focus so much on it on a discussion about LISP. [EDIT: I meant to say that this most likely reveals something else is at work in the particular case of python]. When a C program compiles, it really does not tell you much about whether it will work or not. Maybe it is a matter of application domains, but I tend to actually spend more time testing C parts of the code compared to the python code. But, in proportion, I spend more time testing in python than in C, because I spend so much less time doing things in python than in C. Haskell is different, because types can be used to enforced constraints in a much better fashion than C/C++/Java/etc… The one part when simple typing systems is useful is refactoring. Doing so in a dynamically typed language is difficult (but possible, as shown by smalltalk, which is supposedly even more dynamic than python).

evincarofautumn 15y ago
Lisp’s other useful features just make the particulars of the type system less of an issue. When writing prototypes, I move things around and refactor a lot. Python makes this easy at the cost of certainty about whether it was done right. I don’t write a lot of Lisp, but in my experience refactoring there is quite different: I’m not editing methods and classes, I’m factoring functions and macros. If I were one for supposing, I’d suppose the OO philosophy of Python forces you to create interfaces before you necessarily know that they’re correct, so you end up refactoring them, and there’s poor support for that when no static type system has your back.
- cdavid 15y ago
  This is already a more interesting discusion. I cannot comment on Lisp, as I have too little experience with it. When you say python forces you to create interfaces, I am not sure I understand. For me, programming is mostly about creating interfaces (as the interface part of API), python or not. When I refactor some C code, static typing does not help me that much, as what's difficult in C is lifetime's object (e.g. ref counting in C extensions), things like that. What is true is that it is easy to write code that is impossible to refactor, because it is full of globals, or "stringified API" (e.g. using a dict instead of objects when the set of keys is supposed to be fixed). But I am afraid people writing this kind of code would write bad code in any language, or are at least very inexperienced in the language.