7 ms·

My thought process upon seeing this: "Python, huh? Seems like typos in uncommon branches of the code would cause it to randomly fail at runtime, losing your w

by evmar 11y ago

My thought process upon seeing this: "Python, huh? Seems like typos in uncommon branches of the code would cause it to randomly fail at runtime, losing your work!" "Now evmar, don't be such a internet nay-sayer, plenty of people write reliable Python code. You just need tests and... yep, there's a tests directory right there in the repository." "Let's take a look. ...there's only one test!?" It looks pretty neat other than that, though.

david-given 11y ago
I am, right now, or at least two minutes ago before I started reading HN, refactoring big chunks of _my_ text editor, WordGrinder. It's a almost-pure-Lua word processor. In the process I have been writing unit tests. Previously the program didn't have any, which was really dumb. It was dumb because, in the three days I've spent doing this, I have found (and fixed) so, _so_ many bugs. And now I have a decent set of tests, I can change something, rerun them, and have a pretty good idea of whether it worked or not. I don't even have to run the program! Unit tests. They Will Save You Time™.
- teacup50 11y ago
 Types. They Will Save You Tests™ :-)
 - keslag 11y ago
 Types will create a false sense of security...
 - vhost- 11y ago
 Can you elaborate?
 - _yosefk 11y ago
 print(arr[i]) Compiles, runs, fails if i is out of bounds. Which means that you need to test the code that you write, and that even if you have 100% line coverage (or branch coverage or MC/DC coverage or...), it doesn't mean i won't get the wrong value. People who claim that "once my C++/Haskell/Agda/whatever program compiles, I know it probably has no bugs" thus tempt others to mention "a false sense of security." (Agda might be going further than anyone else with proving that i cannot be out of bounds, AFAIK... though a generally undecidable problem will remain generally undecidable.)
 bsummer4 11y ago
 You can't write this in Haskell: print(arr[i]) You can write this, but you probably wouldn't. print (arr `V.unsafeIndex` i)
 dllthomas 11y ago
 Unfortunately, unsafeIndex is often spelled "!". There is a push (which I support!) away from partial functions, but there are still plenty of partial functions provided by standard libraries under names that sound reasonable.
 tomjakubowski 11y ago
 I've never seen anyone claim that types (even a very strong type system like Haskell or Rust) mean you don't have to write tests. They just mean you don't have to write the very silly tests you would otherwise have to to feel secure in a dynamically typed language.
 codygman 11y ago
 > They just mean you don't have to write the very silly tests I have seen claims and have a hunch that more than just very silly tests can be eliminated by types, but I'm struggling to come up with or remember any examples. I'm hoping someone who has one will reply with one of these claims or any examples.
 Manishearth 11y ago
 - gaze 11y ago
 You know, I hear people use this excuse to justify bad behavior a lot. I once heard a bike messenger tell me that brakes gave him a false sense of security so that's why he didn't have a brake on his fixed gear bicycle.
 - hyperbovine 11y ago
 OTOH, I also see a lot of people justifying their point with a single random anecdote. (But I agree wholeheartedly re: fixies and brakes.)
 coldtea 11y ago
 To disprove an absolute statement ("all X are Y") all you need is a single random anecdote.
 - ahuth 11y ago
 Types don't tell you if the behavior is correct or not.
 - wz1000 11y ago
 Ahem, http://en.wikipedia.org/wiki/Dependent_type http://en.wikipedia.org/wiki/Dependent_type
 - dllthomas 11y ago
 Yes they do. Ignoring trivial cases and dependent types, types tell you one of two things: "this might be correct" or "this is incorrect". Again ignoring trivial cases where exhaustive checking is possible, that's the same thing that tests tell you - and it's a hugely useful thing to be told!
 - hueving 11y ago
 No they don't. They only tell you that you are matching function signatures correctly. This is valuable but it's not a substitution for unit tests.
 dllthomas 11y ago
 "it's not a substitution for unit tests" It is a substitute for those unit tests that are essentially checking type invariants. It is not a substitute for all unit tests, but I don't think anyone made (much less intended to make) that claim anywhere in this thread. "They only tell you that you are matching function signatures correctly." All of computation can be expressed as application of functions, so for sufficiently expressive function signatures that's not much of a limitation. Of course, if you want to guarantee that your compiles terminate, you need to apply some limits to the expressiveness of your function signatures... but there are powerful guarantees you can get out of even so simplistic a type system as C's, if you work with it rather than against it.
 curryhoward 11y ago
 Type signatures can completely encode specifications in systems with dependent types. Of course no mainstream programming language supports dependent types, but it's worth pointing out that in principle a type can encode any property checked by a unit test. Actually, dependent types are strictly more powerful, since you can prove undecidable properties which can't be checked by unit tests (e.g., that a function does the right thing for all possible inputs).
 - david-given 11y ago
 I had actually gone and looked for Lua static type checkers. Some exist, but none that'll work with Lua 5.2. I had a really hilarious bug today where under some circumstances all the text in the display would be replaced by numbers. Small integers, each placed where the word should be. What had happened is that I'd added a layer of indirection; where previously, after line wrapping, the data structure for a rendered paragraph was an array of pointers to the word objects, now it was an array of indices into the paragraph's word array. And I'd forgotten about one particular exotic code path. Lua was seeing the array of indices, automatically casting the ints to strings, and then using those strings instead of the word data itself... Static types would have made this bug impossible. ...way back when, there was a really nice and thoroughly obscure language called Strongtalk; it was a Smalltalk 80 clone with optional strict types. You could annotate your classes and methods with type information. If it was there, it would be checked; if it wasn't, you got the traditional behaviour. The JIT knew about the type information and could use it to produce really fast code. It combined the ultimate dynamic language with an expressive static type system (complete with parametric polymorphism). It was open sourced in 2006 and sank without trace. Sigh.
 - Jach 11y ago
 For your example bug I think you're wrong that static types would have made the bug impossible. What you need is strong type checking and a lack of auto-conversion. For example, in Java, this compiles: int[] bodies = {1, 2, 3}; for (int body : bodies) { String formatted_body = "" + body + ""; callMethodWithStrArg(formatted_body); } And if in this hypothetical case it was previously a `String[] bodies` and a `String body`, I bet a lot of programmers would use an auto-refactoring tool because "static types and auto-refactoring go together for being confident in changes like apples and pie" and I bet the error wouldn't have been noticed even at review time. God help you if you're using a static language without generics that has implicit type conversions. In Python, though, this raises an error: bodies = [1, 2, 3] for body in bodies: formatted_body = '' + body + '' The error is: "TypeError: cannot concatenate 'str' and 'int' objects". Dynamically typed languages still have types.
 - 11y ago
 - randomfool 11y ago
 Here's some research on the topic, limited to just types- http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-enough-you-need.html?m=1 http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-eno... Types are one mechanism for static analysis. Better contracts (nullability, valid ranges, etc) goes much further.
 - coldtea 11y ago
 Nullability and ranges can also be encoded as types in the appropriate type system.
pekk 11y ago
It's interesting that your first thought was to post a troll about how Python is a bad language.
- deleted 11y ago
  [deleted]
- evmar 11y ago
  I regret that this post is the top of the page. I failed to anticipate that people will take any opportunity to have yet another boring static typing debate. But to be clear, in my day job I work on an app with 350k lines of Python in it and the reason I know it mostly works is due to our test coverage. As someone else mentioned in this thread, a lack of tests should not give you confidence regardless of the language.
  - deleted 11y ago
    [deleted]
  - drivingmenuts 11y ago
    From the project docs "There is no roadmap. I mostly implement the stuff which I need or interests me, or which gives me the opportunity to learn." Pretty much says it all. Seems it was primarily written to satisfy personal needs, not be the end-all, be-all of professionally written software. It is, incidentally, potentially interesting to others who might want to learn from it, or use it, knowing the background. So, you might cut the guy a break. The requirements for personal projects aren't the same.
shangxiao 11y ago
vs random memory bugs that will fail randomly at runtime ;)
bbcbasic 11y ago
Yes indeed any 'rewritten in ...' project should target Haskell.
jonjacky 11y ago
> "Python, huh? Seems like typos in uncommon branches of the code would cause it to randomly fail at runtime, losing your work!" Maybe not - Python itself can provide some crash protection. Run it this way: python -i run_pyvim.py. Then if pyvim crashes, Python will still be running with all your work still there. Maybe you can just type run() at the Python prompt to resume the session in almost the state you left it -- depending on how run() is coded, how much re-initialization it does.

by evmar 11y ago

david-given 11y ago

I am, right now, or at least two minutes ago before I started reading HN, refactoring big chunks of _my_ text editor, WordGrinder. It's a almost-pure-Lua word processor. In the process I have been writing unit tests. Previously the program didn't have any, which was really dumb. It was dumb because, in the three days I've spent doing this, I have found (and fixed) so, _so_ many bugs. And now I have a decent set of tests, I can change something, rerun them, and have a pretty good idea of whether it worked or not. I don't even have to run the program! Unit tests. They Will Save You Time™.

teacup50 11y ago
Types. They Will Save You Tests™ :-)
- keslag 11y ago
 Types will create a false sense of security...
 - vhost- 11y ago
 Can you elaborate?
 - _yosefk 11y ago
 print(arr[i]) Compiles, runs, fails if i is out of bounds. Which means that you need to test the code that you write, and that even if you have 100% line coverage (or branch coverage or MC/DC coverage or...), it doesn't mean i won't get the wrong value. People who claim that "once my C++/Haskell/Agda/whatever program compiles, I know it probably has no bugs" thus tempt others to mention "a false sense of security." (Agda might be going further than anyone else with proving that i cannot be out of bounds, AFAIK... though a generally undecidable problem will remain generally undecidable.)
 - bsummer4 11y ago
 You can't write this in Haskell: print(arr[i]) You can write this, but you probably wouldn't. print (arr `V.unsafeIndex` i)
 dllthomas 11y ago
 Unfortunately, unsafeIndex is often spelled "!". There is a push (which I support!) away from partial functions, but there are still plenty of partial functions provided by standard libraries under names that sound reasonable.
 - tomjakubowski 11y ago
 I've never seen anyone claim that types (even a very strong type system like Haskell or Rust) mean you don't have to write tests. They just mean you don't have to write the very silly tests you would otherwise have to to feel secure in a dynamically typed language.
 codygman 11y ago
 > They just mean you don't have to write the very silly tests I have seen claims and have a hunch that more than just very silly tests can be eliminated by types, but I'm struggling to come up with or remember any examples. I'm hoping someone who has one will reply with one of these claims or any examples.
 Manishearth 11y ago
 - gaze 11y ago
 You know, I hear people use this excuse to justify bad behavior a lot. I once heard a bike messenger tell me that brakes gave him a false sense of security so that's why he didn't have a brake on his fixed gear bicycle.
 - hyperbovine 11y ago
 OTOH, I also see a lot of people justifying their point with a single random anecdote. (But I agree wholeheartedly re: fixies and brakes.)
 - coldtea 11y ago
 To disprove an absolute statement ("all X are Y") all you need is a single random anecdote.
- ahuth 11y ago
 Types don't tell you if the behavior is correct or not.
 - wz1000 11y ago
 Ahem, http://en.wikipedia.org/wiki/Dependent_type http://en.wikipedia.org/wiki/Dependent_type
 - dllthomas 11y ago
 Yes they do. Ignoring trivial cases and dependent types, types tell you one of two things: "this might be correct" or "this is incorrect". Again ignoring trivial cases where exhaustive checking is possible, that's the same thing that tests tell you - and it's a hugely useful thing to be told!
 - hueving 11y ago
 No they don't. They only tell you that you are matching function signatures correctly. This is valuable but it's not a substitution for unit tests.
 - dllthomas 11y ago
 "it's not a substitution for unit tests" It is a substitute for those unit tests that are essentially checking type invariants. It is not a substitute for all unit tests, but I don't think anyone made (much less intended to make) that claim anywhere in this thread. "They only tell you that you are matching function signatures correctly." All of computation can be expressed as application of functions, so for sufficiently expressive function signatures that's not much of a limitation. Of course, if you want to guarantee that your compiles terminate, you need to apply some limits to the expressiveness of your function signatures... but there are powerful guarantees you can get out of even so simplistic a type system as C's, if you work with it rather than against it.
 - curryhoward 11y ago
 Type signatures can completely encode specifications in systems with dependent types. Of course no mainstream programming language supports dependent types, but it's worth pointing out that in principle a type can encode any property checked by a unit test. Actually, dependent types are strictly more powerful, since you can prove undecidable properties which can't be checked by unit tests (e.g., that a function does the right thing for all possible inputs).
- david-given 11y ago
 I had actually gone and looked for Lua static type checkers. Some exist, but none that'll work with Lua 5.2. I had a really hilarious bug today where under some circumstances all the text in the display would be replaced by numbers. Small integers, each placed where the word should be. What had happened is that I'd added a layer of indirection; where previously, after line wrapping, the data structure for a rendered paragraph was an array of pointers to the word objects, now it was an array of indices into the paragraph's word array. And I'd forgotten about one particular exotic code path. Lua was seeing the array of indices, automatically casting the ints to strings, and then using those strings instead of the word data itself... Static types would have made this bug impossible. ...way back when, there was a really nice and thoroughly obscure language called Strongtalk; it was a Smalltalk 80 clone with optional strict types. You could annotate your classes and methods with type information. If it was there, it would be checked; if it wasn't, you got the traditional behaviour. The JIT knew about the type information and could use it to produce really fast code. It combined the ultimate dynamic language with an expressive static type system (complete with parametric polymorphism). It was open sourced in 2006 and sank without trace. Sigh.
 - Jach 11y ago
 For your example bug I think you're wrong that static types would have made the bug impossible. What you need is strong type checking and a lack of auto-conversion. For example, in Java, this compiles: int[] bodies = {1, 2, 3}; for (int body : bodies) { String formatted_body = "" + body + ""; callMethodWithStrArg(formatted_body); } And if in this hypothetical case it was previously a `String[] bodies` and a `String body`, I bet a lot of programmers would use an auto-refactoring tool because "static types and auto-refactoring go together for being confident in changes like apples and pie" and I bet the error wouldn't have been noticed even at review time. God help you if you're using a static language without generics that has implicit type conversions. In Python, though, this raises an error: bodies = [1, 2, 3] for body in bodies: formatted_body = '' + body + '' The error is: "TypeError: cannot concatenate 'str' and 'int' objects". Dynamically typed languages still have types.
 - 11y ago
- randomfool 11y ago
 Here's some research on the topic, limited to just types- http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-enough-you-need.html?m=1 http://evanfarrer.blogspot.com/2012/06/unit-testing-isnt-eno... Types are one mechanism for static analysis. Better contracts (nullability, valid ranges, etc) goes much further.
 - coldtea 11y ago
 Nullability and ranges can also be encoded as types in the appropriate type system.

pekk 11y ago

It's interesting that your first thought was to post a troll about how Python is a bad language.

deleted 11y ago
[deleted]
evmar 11y ago
I regret that this post is the top of the page. I failed to anticipate that people will take any opportunity to have yet another boring static typing debate. But to be clear, in my day job I work on an app with 350k lines of Python in it and the reason I know it mostly works is due to our test coverage. As someone else mentioned in this thread, a lack of tests should not give you confidence regardless of the language.
- deleted 11y ago
  [deleted]
- drivingmenuts 11y ago
  From the project docs "There is no roadmap. I mostly implement the stuff which I need or interests me, or which gives me the opportunity to learn." Pretty much says it all. Seems it was primarily written to satisfy personal needs, not be the end-all, be-all of professionally written software. It is, incidentally, potentially interesting to others who might want to learn from it, or use it, knowing the background. So, you might cut the guy a break. The requirements for personal projects aren't the same.

shangxiao 11y ago

vs random memory bugs that will fail randomly at runtime ;)

bbcbasic 11y ago

Yes indeed any 'rewritten in ...' project should target Haskell.

jonjacky 11y ago

> "Python, huh? Seems like typos in uncommon branches of the code would cause it to randomly fail at runtime, losing your work!" Maybe not - Python itself can provide some crash protection. Run it this way: python -i run_pyvim.py. Then if pyvim crashes, Python will still be running with all your work still there. Maybe you can just type run() at the Python prompt to resume the session in almost the state you left it -- depending on how run() is coded, how much re-initialization it does.