5 ms·
I'm a big fan of strong static type systems. I believe type-safety increases code quality significantly. I used to think several years ago, that the main benef
by winter_blue 9y ago
I'm a big fan of strong static type systems. I believe type-safety increases code quality significantly.
I used to think several years ago, that the main benefit of strong static typing was code safety / eliminating a whole class of bugs. But I've changed my opinion. I now think the biggest benefit is that it makes the code a lot easier for other people to read and understand.
I mean I have multiple personal projects where I've used Python (which is a dynamically typed language), but these are small one-off projects. But I think when working in a team, especially a large team, having types becomes a huge thing. Having types for objects is especially useful. Having types forces you to think more clearly about the structure of your data.
It's really sad when I see `foo(bar)`, and I have no idea what the type of `bar` is, and if it's an object, I have no idea what fields `bar` has. I have to simply guess the structure of the various implicit types by looking at the code (sigh). It makes the code difficult to read, and rather unpleasant to work on. Not to mention, all the multitude of bugs that come from duck/dynamic typing.
I don't think good statically typed languages are hard to use at all. Type inference has spread everywhere that the old argument of having to repeat your types doesn't hold anymore. TypeScript, Flow (JavaScrpt), Haskell, languages from the ML family are really good at type inference. Even the `auto` type inference in C++17 was better than I'd expected.
- icebraining 9y agoTechnically Python is now an optionally-typed language, as of version 3.5. It won't actually check the types out-of-the-box, but it has support for annotating variables and functions with their types. A separate project (mypy) can then read and check those types, and it does some inference too. You can see typed examples here: http://mypy-lang.org/examples.html http://mypy-lang.org/examples.html
- weberc2 9y agoIt's still a work in progress though. Buggy, unintuitive, and incomplete (e.g., no recursive types).
- camus2 9y ago> Technically Python is now an optionally-typed language, as of version 3.5 Well no, since the compiler isn't checking types and you need a third party tool for that. So it's not optional typing. PHP does have run-time optional typing and was successful at retrofitting a static type system in a completely dynamic language. Mypy is just a static analysis tool.
- icebraining 9y agoFine, but it's just an import away: https://github.com/kislyuk/ensure https://github.com/kislyuk/ensure (written by HN user ak217)
- whyever 9y agoIt does not help you as much if the standard library and the whole ecosystem don't have type annotations.
- DavsX 9y agothis is exactly my biggest pain-point of dynamic typing (which I do at work): you can't know how a datastructure looks like. Just knowing the fields that are present is something I would like to have.
- vincnetas 9y agoCount me in. And not only when working in teams. Sometimes that other person is you, after half year or more, and you need to figure out what the hell i was thinking when i was writing this code.
- u801e 9y ago> It's really sad when I see `foo(bar)`, and I have no idea what the type of `bar` is, and if it's an object, I have no idea what fields `bar` has With a statically typed language, you still have to look through the code to find the definition of an object. I believe that can be avoided by having easy to access to documentation which would also apply to dynamically typed languages like Python.
- Ensorceled 9y agoNot if you use Hungarian notation! Shudder.
- weberc2 9y agoRight, but modern text editors and IDEs automate the lookup, and failing that, you have the type right there so you can quickly and easily figure out which file contains its definition. I use Python every day, and the sad (but improving!) state of typing is one of my biggest grievances. Documentation doesn't close the gap because it is often incorrect or outdated; I've added more than a couple production bugs because I trusted the documentation. A type checker is necessary to keep the type annotations in line with the source code.
- dragonwriter 9y ago> With a statically typed language, you still have to look through the code to find the definition of an object Static typing (or, more to the point, compile time structure that doesn't require running the code to get right, but the two are closely linked) makes tooling to avoid manual lookups easier to implement and more reliable.
- dahauns 9y ago>I believe that can be avoided by having easy to access to documentation which would also apply to dynamically typed languages like Python. staring at five year old project, started as a one-off quick'n'dirty prototype, having gone through many hands doing one-off quick'n'dirty additions since then What documentation? But seriously - I don't have to "look through the code". It's a few keystrokes at most and it's always there and correct.
- 9y ago
- peatmoss 9y agoI thought the most recent Clojure Conj keynote by Rich Hickey (caveat: that guy could sell me the Brooklyn Bridge) did a good job selling dynamically typed languages. As he makes a pretty good case for, there’s a lot to like about dynamically typed languages. But, everywhere I look in Clojure, I feel like the language is more principled than Python. There’s also Spec, which allows developers to exercise even more rigor without jumping to static types. Going even further, Racket lets you move to a type system as you want to, but not before. I’d like to imagine that there’ll be more of these middle ground approaches over time, without having to commit to either the freewheeling status quo of Python or the rigidity of Haskell. EDIT: I should note that even Python is moving that way as there are now optional type annotations.
- dahauns 9y ago>Type inference has spread everywhere that the old argument of having to repeat your types doesn't hold anymore. Indeed. I find one of the most elegant recent examples is this snippet in Kotlin (yes, this is fully and statically typed): https://kotlinlang.org/docs/reference/type-safe-builders.html https://kotlinlang.org/docs/reference/type-safe-builders.htm... import com.example.html.* fun result(args: Array<String>) = html { head { title {+"XML encoding with Kotlin"} } body { h1 {+"XML encoding with Kotlin"} p {+"this format can be used as an alternative markup to XML"} // an element with attributes and text content a(href = "http://kotlinlang.org") {+"Kotlin"} // mixed content p { +"This is some" b {+"mixed"} +"text. For more see the" a(href = "http://kotlinlang.org") {+"Kotlin"} +"project" } p {+"some text"} // content generated by p { for (arg in args) +arg } } }
- pmoriarty 9y ago"I used to think several years ago, that the main benefit of strong static typing was code safety / eliminating a whole class of bugs. But I've changed my opinion. I now think the biggest benefit is that it makes the code a lot easier for other people to read and understand." Obfuscated spaghetti code and write-only programs can be written in any language. I've seen plenty of convoluted OCaml programs, with tons of one-letter variable names and no comments. And don't get me started on Haskell's propensity for using dozens of non-alphabetic operators that make it read more like line noise than Perl, not to mention its famous easy to understand monads or easy to reason about lazyness, on top of the community propensity for one-letter variable names, same as with OCaml. Static typing does not save badly written programs in either of these languages. Besides, you can add type annotations to your Python programs, and even have them checked by mypy. Those programs might even wind up being easier to read than programs written in a statically-typed language where the programmer relied on type inference. But they won't necessarily be any more readable, as readability has less to do with types than it does with the programmer and the reader.
- not_kurt_godel 9y agoYou're missing the point. Static typing guarantees that you can find out certain very convenient facts about code that you don't fully understand. Which means that if someone writes spaghetti code, you at least have tools that can help you understand it better.