4 ms·

i don't know. in college i wrote static and dynamic program analyzers, and was in a very pro-java-typing group. when i moved to python i was sure the lack of ty

by diN0bot 17y ago

i don't know. in college i wrote static and dynamic program analyzers, and was in a very pro-java-typing group. when i moved to python i was sure the lack of typing would be problematic. the lack of static typing has NEVER caused a bug. a few times i will have a bug because i mispell a variable name, thereby inadvertantly creating a new variable, but i have always found those problems on the next run of the program. vastly more useful are creating tests and using them often. to be fair to my college days, i still create object models (ish...i have my own version) and other diagrams, which i find crucial for design and frequent reference aftewards. the whole "type" thing must be important for other problem domains.

cracki 17y ago
the type thing is important to the kinds of people who get a woody thinking about the maths that deal not in numbers.
derefr 17y ago
Pretend there was a type "numbers between 1 and 4." Then, when you try to cast a 5 to that type, it would fail. Types are just sets of possible instance values; that most languages limit them to reasoning only about the outermost features of the type (e.g. capacity of 1 vs N, mutability, signedness or realness) makes them orders of magnitude less useful than they could be.
- omouse 17y ago
  Pretend there was a type "numbers between 1 and 4." Pascal and Ada have this I think. I think Eiffel has contracts to enforce that type of thing instead.
snprbob86 17y ago
I've written a lot of Java, C++, and C#. I currently write a lot of MSBuild (not by choice) and Python. Static vs dynamic typing is neither a mutually exclusive choice, nor a choice which can occur in a vacuum. Use the right tool for the job, or else one of these things will happen: Java/Swing: You will be woefully unequipped for the natural cascading property nature of GUI applications; forcing you to jump through giant hoops to get anything to not look awful. C++/COM: You'll cast IUnknown to ISomethingElse so many times that it will lose meaning. MSBuild: You will make a typo in a parameter name, but won't find out until two hours into your build when you get an error that could have been caught by a compiler. -- Static typing works for problems that demand rigor, but may be hard to unit test. That includes most larger projects worked on by companies of overworked and slightly disinterested developers. Dynamic typing works when you can iterate as fast as you can refresh the browser, or when your application is small enough that it is reasonable to full text search the entire thing anytime you refactor anything. You can build dynamic type systems on top of static ones, but it is ugly. Don't be WPF's DependencyObject system cringe. It is safe, however, to layer dynamic code above static code. Feel free to use a dynamic language for scripting a statically build application. You can build static type systems on top of dynamic ones, but they will leak. It is also awkward to layer static code above dynamic code. Odds are your code will be dynamic, but more verbose because of the type system getting in your way.
berntb 17y ago
>>a few times i will have a bug because i mispell a variable name Huh, that spelling problem would give me errors every page. Python have no warnings for uniquely created/used variables? There is no possibility to demand some declaration of existing variables? It is quite easy to parse Python(?), so the IDEs should catch this, at least?
- tetha 17y ago
  Python requires you to initialize a variable before reading it, so: foo = object ofo.__call__() will cause a (runtime) error. Thus, if you use your declared variables, errors will occur on mistypes (unless, of course, you have the typo declared, which would be a smell in itself (think of variable names being too close))
  - berntb 17y ago
    OK, what if it is a flag variable that is either undefined or an integer? That is, do you need to initialize all variables? Also, how about this? foo = 10 ... if ... ofo = 20 ... formula = bah * ( ... foo ... ) Edit: Please tell me the second case isn't as catastrophic as it looks? That would give at least me no ends of problems -- I thought modern languages left that kind of sh-t in the 1990s? Better have a good culture for testing!
    - tetha 17y ago
      1) If you want to read the variable in some way, you need to initalize it. If you want to do weird things involving setting random attributes on an object and check if they exist.. well, you're on your own. Generally, I'd recommend for the flag variable to have a definite uninitialized value (say, None), as this is far easier to check. 2) The opinion of a lot of people on python is that the lack of such (impossible[1]) compiletime tests requires you to replace them with good unit-tests (which should be written anyway). So yes, it is as bad as it looks, but it is recommended to test such things :) Also, there are tools like pychecker and pyflakes, which do sanity-checks which would capture these errors (even though they might be an insane valid python program[1]). [1] This is impossible, as it is possible to set variables in earlier stack-frames inside a nested call, or I might fiddle around in the locals of an earlier call to get data I want. Certainly, no one would do this (and whoever does such a thing should be stabbed multiple times if this hack persists longer than an hour (hey, I have built such a thing myself to debug a deadlock about resources, it printed the direct caller of the allocation- and deallocation-method, so I could quickly check for unmatched alloc-calls :) )), but it is possible, and thus, the compiler has to assume such things happen.

by diN0bot 17y ago

cracki 17y ago

the type thing is important to the kinds of people who get a woody thinking about the maths that deal not in numbers.

derefr 17y ago

Pretend there was a type "numbers between 1 and 4." Then, when you try to cast a 5 to that type, it would fail. Types are just sets of possible instance values; that most languages limit them to reasoning only about the outermost features of the type (e.g. capacity of 1 vs N, mutability, signedness or realness) makes them orders of magnitude less useful than they could be.

omouse 17y ago
Pretend there was a type "numbers between 1 and 4." Pascal and Ada have this I think. I think Eiffel has contracts to enforce that type of thing instead.

snprbob86 17y ago

I've written a lot of Java, C++, and C#. I currently write a lot of MSBuild (not by choice) and Python. Static vs dynamic typing is neither a mutually exclusive choice, nor a choice which can occur in a vacuum. Use the right tool for the job, or else one of these things will happen: Java/Swing: You will be woefully unequipped for the natural cascading property nature of GUI applications; forcing you to jump through giant hoops to get anything to not look awful. C++/COM: You'll cast IUnknown to ISomethingElse so many times that it will lose meaning. MSBuild: You will make a typo in a parameter name, but won't find out until two hours into your build when you get an error that could have been caught by a compiler. -- Static typing works for problems that demand rigor, but may be hard to unit test. That includes most larger projects worked on by companies of overworked and slightly disinterested developers. Dynamic typing works when you can iterate as fast as you can refresh the browser, or when your application is small enough that it is reasonable to full text search the entire thing anytime you refactor anything. You can build dynamic type systems on top of static ones, but it is ugly. Don't be WPF's DependencyObject system cringe. It is safe, however, to layer dynamic code above static code. Feel free to use a dynamic language for scripting a statically build application. You can build static type systems on top of dynamic ones, but they will leak. It is also awkward to layer static code above dynamic code. Odds are your code will be dynamic, but more verbose because of the type system getting in your way.

berntb 17y ago

>>a few times i will have a bug because i mispell a variable name Huh, that spelling problem would give me errors every page. Python have no warnings for uniquely created/used variables? There is no possibility to demand some declaration of existing variables? It is quite easy to parse Python(?), so the IDEs should catch this, at least?

tetha 17y ago
Python requires you to initialize a variable before reading it, so: foo = object ofo.__call__() will cause a (runtime) error. Thus, if you use your declared variables, errors will occur on mistypes (unless, of course, you have the typo declared, which would be a smell in itself (think of variable names being too close))
- berntb 17y ago
  OK, what if it is a flag variable that is either undefined or an integer? That is, do you need to initialize all variables? Also, how about this? foo = 10 ... if ... ofo = 20 ... formula = bah * ( ... foo ... ) Edit: Please tell me the second case isn't as catastrophic as it looks? That would give at least me no ends of problems -- I thought modern languages left that kind of sh-t in the 1990s? Better have a good culture for testing!
  - tetha 17y ago
    1) If you want to read the variable in some way, you need to initalize it. If you want to do weird things involving setting random attributes on an object and check if they exist.. well, you're on your own. Generally, I'd recommend for the flag variable to have a definite uninitialized value (say, None), as this is far easier to check. 2) The opinion of a lot of people on python is that the lack of such (impossible[1]) compiletime tests requires you to replace them with good unit-tests (which should be written anyway). So yes, it is as bad as it looks, but it is recommended to test such things :) Also, there are tools like pychecker and pyflakes, which do sanity-checks which would capture these errors (even though they might be an insane valid python program[1]). [1] This is impossible, as it is possible to set variables in earlier stack-frames inside a nested call, or I might fiddle around in the locals of an earlier call to get data I want. Certainly, no one would do this (and whoever does such a thing should be stabbed multiple times if this hack persists longer than an hour (hey, I have built such a thing myself to debug a deadlock about resources, it printed the direct caller of the allocation- and deallocation-method, so I could quickly check for unmatched alloc-calls :) )), but it is possible, and thus, the compiler has to assume such things happen.