3 ms·
Uh ... no. Type safety is rarely a problem from my personal experience (YMMV) in code dev. The issues I run across have to do with whether or not the code is
by hpcjoe 9y ago
Uh ... no. Type safety is rarely a problem from my personal experience (YMMV) in code dev. The issues I run across have to do with whether or not the code is an accurate reflection of the algorithm in question, or even if the algorithm itself is correct, if core assumptions are correct, dealing with corner cases, etc. Types rarely have anything constructive to add to this mix, regardless of whether or not I am working in a weakly/non-typed language, or strongly typed language.
I personally tend to do something much closer to TDD, and break my code out so I test each part with its own test rig. So I see when I do dumb things that need re-work. Again, typing is pretty much never an issue there.
While this is all anecdotal, I personally have found that enforcing boilerplate type defs actually increases my coding error rate. More LOC gives you more opportunities for errors.
FWIW, Julia (http://julialang.org http://julialang.org) is IMO Python done right, and it is strongly typed. But done in such a way as to not actually get in your way most of the time. Like Python it has a great REPL, fantastic FFI, rapidly growing module list, very active development. Unlike Python, it has no issues with whitespace[1], is compiled (JIT for now, though static is planned from what I understand), is very fast, has multiple dispatch and a strong typing system.
The real point the article was making is, programmer time is the most valuable thing to optimize for. I completely agree with this, even though I disagree that Python is the right tool for (most) every job.
There are better tools IMO, which allow me to be far more productive, and spend as little time as possible on worrying about types ... which are rarely ever a concern for me.
I thought his comment about string processing was interesting, though he completely ignored Perl in the mix. I've found string processing in Perl to be almost trivial. Its harder (far more verbose boilerplate) in Python, and gets worse in other languages. Perl6 lets you embed grammars and write parsers without resorting to external modules (Marpa::* in Perl5). Takes building string processing, parsers, etc. to a whole new level, while making you even more productive.
But, as the author had noted, he is a pythonista. Everyone has their biases (including me). I want to code correctly quickly, and not have things that shouldn't get in my way, get in my way. Including type systems, massive boilerplate/odd syntax rules, etc.
[1] It is 2017 ... structure by indentation is somehow, still a thing. It shouldn't be IMO.
- marcosdumay 9y agoI was about to ask you what kind of statically typed languages you were using that gave you this impression. But... "boilerplate type defs". Yeah, C++ typing system sucks. Just don't think this generalizes to other languages.
- falcolas 9y agoWell, let's see. Go: map[string]int64 Java: HashMap<String, long> Rust: HashMap<&str, i64> I think Haskell is one of the only statically typed languages which doesn't really care about algebraic typing. And yes, if you're talking about static typing, you get the baggage of dealing with algebraic typing to go with it as a rule. You can't arbitrarily separate the two until more languages follow Haskell's route.
- hpcjoe 9y agoIt's not just C++ though. If I have to add logic to my code to handle explicit type changes (casting, et al.) for something that, honestly, is not important to my algorithm, then this increases the likelihood that I will make a type/casting/conversion error. OTOH, a language smart enough to (correctly) infer this (Perl, Julia, etc.) generally won't have a problem with this, and will handle these issues for you. Julia still allows you to be very explicit on type, and force a hard type specialized code. The benefit in this case, with type specialization, is that it can generate far more efficient code for the specific logic. That latter argument is, to me, the only real benefit of typing systems that I've personally encountered. I know people throw studies around claiming "fewer errors with stronger type systems", but ... to be honest ... I have not experienced this. Rather, in stronger typed languages, I spend more time hunting down type impedance issues than logic issues. This seems to not be a positive benefit to me. I may be alone in this regard, or not. I don't know. I do know that, like programming languages, editors, operating systems, this view point (pro/anti strong typing) tends to take on a religious overtone in the sense of people taking a position and digging their heels in over this. Elevating this aspect as an important point in an overall platform decision process (what should we develop in), when, maybe, it shouldn't be. In an odd way, I've seen this in the industry for a while. There were previous incarnations of this. Like Dijkstra's famous "goto" comments[1]. I don't necessarily agree with this, and I argue that people can write bad code in any language. Typing systems ostensibly are there to help us write less bad code (all code is bad and buggy, anyone telling you otherwise is trying to sell you some swampland). But once they get in your way, and you start spending inordinate amounts of time dealing with typing issues, you have to ask whether or not they are helping or inhibiting. Put another way, anything that helps should, actually help, without adding significantly to the burden. Apart from what Julia does, and other dynamic languages do ... that some people write great code in ... I've not seen/used many other systems that strive to get out of your way while working. Typing systems do not automatically make code better. Absence of typing systems do not automatically make code worse. This is a function of the algorithm, the implementation logic, etc. How disciplined are you as the developer in making sure your code is clear, concise, and actually reflective of the problem you are attempting to solve ... things that help with that are welcome. [1] http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf http://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pd...