5 ms·
That's in general a problem with dynamic languages with weak type systems. How "Your code runs without crashing" is really really != "your code works". How do p
by andrepd 5y ago
That's in general a problem with dynamic languages with weak type systems. How "Your code runs without crashing" is really really != "your code works". How do people even manage production python! A bug could be lurking anywhere, undetected until it's actually run. Whereas in a compiled language with a strong type system, "your code compiles" is much closer to "your code is correct".
- deleted 5y ago[deleted]
- digisign 5y agoThere are a number of mitigations, so those kind of bugs are quite rare. In our large code base, about 98% of bugs we find are of the "we need to handle another case" variety. Pyflakes quickly finds typos which eliminates most of the rest.
- wk_end 5y agoThis is the difference between people who embrace static typing and everyone else. A static type lover hears that 98% of your bugs are of the "we need to handle another case" variety and says, "well, that means you could have gotten rid of 98% of your bugs with better typing".
- digisign 5y agoNo, what I mean is that an additional key comes in (with the json or similar hash) and we now need to do some thing with it, or something different than we thought we were supposed to with it. Typing is not going to fix it because the full cases were unknown at development time.
- BiteCode_dev 5y agoI don't think a type system can help you with decoding a file with the wrong charset.
- pvorb 5y agoThe compiler can raise a warning about bad characters. It can't detect all problems, but it certainly can help with some. It's not the type system, but many dynamic languages are interpreted instead of compiled.
- dotancohen 5y agoThose bad characters are fed into the program long long after the compiler has done its job.
- pvorb 5y agoNot necessarily? I'm talking about constant string literals in source code which can be validated at compile time.
- morelisp 5y agoA type system can refuse to turn a `bytes` into a `utf8str` until it's been appropriately parsed. (It doesn't even need to be a very good or strongly-enforced type system - Go makes it dangerously easy to convert between `[]byte` and `string` by other-type-system standards, and yet everything works pretty well. It's enough to hitch your thinking and make you realize you need another step.)
- BiteCode_dev 5y agoHow does the type system knows the bytes are utf8 and not CP850?
- morelisp 5y agoThe same way you can parse a string into an integer and it knows you got an either[integer, err].
- deleted 5y ago[deleted]
- mekster 5y ago> "your code compiles" is much closer to "your code is correct". That is so far from the truth.
- ben-schaaf 5y agoHow is it anything but the truth? The express purpose of static analysis, like a type system, is to catch bugs before running your code. That pretty clearly means that code that successfully compiles is closer to being correct than code that doesn't.
- mekster 5y agoI mean, correct as in logically correct and that's just a different matter than being grammatically correct.
- morelisp 5y agoThe parser assures your code is grammatically correct; the type system assures your code is semantically consistent, which is usually a much stronger guarantee, and by most practical measures will be closer - often much closer, and for total functions on total types, sometimes all the way - to "logically correct".
- cafard 5y agoBut this is not a matter of UTF-8 in the code, rather a matter of UTF-8 in the input or output. How does compiling a program ensure that it is robust on a range of inputs?
- morelisp 5y ago> How does compiling a program ensure that it is robust on a range of inputs? This is quite literally the job of a type system: to impose a semantic interpretation on sequences of "raw bits" and let you specify legal (and only legal) operations in terms of the semantic interpretation rather than the bits.