TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why I Prefer Dynamic Typing Over Static Typing (2017)

29 pointsby porjoover 6 years ago

27 comments

OskarSover 6 years ago
&gt; For the programming that I do, I am often creating new architectures. Therefore I need dynamic typing.<p>He seems to consider static typing equivalent to &quot;locking down&quot; an architecture, that when you use static typing you&#x27;re locked in to a certain way of doing it, and you&#x27;re stuck with it. In my experience of working with large codebases with both dynamically and statically typed languages, the opposite is true.<p>Static typing frees you up to make changes to interfaces in a way that dynamic typing does not. For instance, if i want to add or remove a parameter to a function in a statically typed language, it&#x27;s trivial. I just do it, and the compiler goes &quot;ok, this function is called from these 4 places, so just fix those&quot; and you now are assured that everything will work.<p>That doesn&#x27;t work in dynamically typed languages. There&#x27;s no reliable way to change an interface and be confident that you haven&#x27;t broken anything (+&#x2F;- extremely good linters, but those aren&#x27;t perfect in the way a compiler is). This leads to a &quot;never change this function, you can break all sorts of things&quot; attitude that simply doesn&#x27;t exist with static typing, where the compiler can just tell you what you need to fix.<p>There are perfectly valid arguments in favor of dynamic typing (it&#x27;s arguably easier, often faster to work with etc.) but this particular one is extremely silly. The exact opposite is true.
评论 #19199869 未加载
评论 #19199947 未加载
评论 #19199993 未加载
icholyover 6 years ago
&gt; Static typing does not live up to its promises. If it did live up to its promises, we would all use it, and the fact that we don’t all use it suggests how often it fails.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Argumentum_ad_populum" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Argumentum_ad_populum</a>
评论 #19198240 未加载
评论 #19199757 未加载
评论 #19199899 未加载
taudeover 6 years ago
Written on chalk board:<p>I will not participate in Hacker News Static vs Dynamic typing debates.<p>I will not participate in Hacker News Static vs Dynamic typing debates.<p>I will not participate in Hacker News Static vs Dynamic typing debates.<p>I will not participate in Hacker News Static vs Dynamic typing debates.<p>I will not participate in Hacker News Static vs Dynamic typing debates.<p>Stay strong, Me
评论 #19200000 未加载
评论 #19199889 未加载
评论 #19199847 未加载
评论 #19199991 未加载
评论 #19201689 未加载
评论 #19200544 未加载
dleslieover 6 years ago
&gt; In a dynamic language I could simply work with a deeply nested data structure of maps and lists, and I’d handle the casting at the very end of the process. In a dynamic language, I could treat everything as a string till the very end, and then cast to integers or dates or floats or strings as needed. In a dynamic language, I could write the code faster, with less errors, and with less code.<p>Nothing described is impossible, or even hard, for a statically typed language to do.<p>Perhaps I misunderstand them, but author seems to be under the impression that static typing doesn&#x27;t allow for type conversions.<p>&gt; In static-type languages such as Java, I’m forced to go with either #1 or #2, and they are both bad options.<p>That&#x27;s simply not true.
bunderbunderover 6 years ago
I have experienced the same pain as the author many times, and, though I mostly work with Java by day these days, when possible I would much more happily reach for Python when I&#x27;m needing to hack on a REST API.<p>But I don&#x27;t think this particular issue has much, if anything, to do with dynamic vs. static typing. It&#x27;s mostly about how clean and elegant Python&#x27;s way of handling JSON is compared to the black hole of viral enterprise-y overdesign that is Jackson, Java&#x27;s <i>de facto</i> standard library for dealing with JSON.<p>With Python, JSON is deserialized to, in essence, a dictionary that maps keys to values, where the values are either strings, arrays of values, or dictionaries.<p>With Jackson, it&#x27;s exactly as awful as TFA describes.<p>But I can easily imagine a Java library where JSON deserializes to some &quot;JSONEntity&quot; type that can act as either a string, a list of entities, or a string-&gt;entity map. And then I could interact with that in the same loose, don&#x27;t-force-me-to-worry-about-details-I-don&#x27;t-currently-care-about way that I do in Python. Perhaps one even already exists. It doesn&#x27;t seem a far-fetched dream - I&#x27;ve used similar libraries for other static languages.<p>TBH, I haven&#x27;t looked, because, even if I found one, I&#x27;d still be compelled to use Jackson, anyway. Because Jackson has been around forever, and Jackson is now so deeply entrenched that nobody working in the Javaverse can even fathom life without it. Suggesting such a thing would be heretical.
评论 #19200255 未加载
phaedrusover 6 years ago
I saw a talk by an npm developer who dismissed type checking as &quot;just another kind of unit test&quot; for your code (and advocated instead dynamic typing and manual unit tests). It bothered me enough to think about what was wrong with what he said long after the talk. I realized the difference is type checking takes the place of infinite numbers of unit tests: unit tests only assert an &quot;exists&quot;; type checking proves &quot;forall&quot;.<p>The linked article, however, is a whole other level of incorrect thinking and drivel.
mattnewportover 6 years ago
&quot;Static typing tends to be used in areas where legal regulations create needs that outweigh programmer productivity.&quot;<p>This is rather a broad generalization that doesn&#x27;t seem accurate to me. It&#x27;s at least misleadingly phrased if it&#x27;s not intended to imply that this is the main reason or primary domain where static typing is used. Performance is a major reason static typing is preferred in many domains like games development for example where legal regulations are largely irrelevant.
评论 #19199811 未加载
SkyPuncherover 6 years ago
Static typing is fantastic in a closed system. It&#x27;s predictable and reliable.<p>My problem is nearly every type system breaks down when you try communicate with something outside of the closed system (e.g. API calls, 3rd party integration, etc).<p>An API returns an unexpected data type, Missing a field that&#x27;s supposed to be required, Starts returning a number as a string because they changed their ID system, etc.<p>It always seems to end up in types where every field is optional - defeating the purpose of having types in the first place.
评论 #19199810 未加载
评论 #19200069 未加载
评论 #19199756 未加载
评论 #19199761 未加载
评论 #19199754 未加载
评论 #19199787 未加载
评论 #19200102 未加载
noelwelshover 6 years ago
It&#x27;s a fallacy to think that all statically typed languages are the same, and all libraries in the statically typed languages are the same. It seems the author is making these fallacies. My experience programming C, Java, and Haskell---all statically typed languages---is vastly different.
neetodavidover 6 years ago
I parse a lot of JSON in surprising and inconsistent formats and what works best for me is to immediately sanitize the object (option 1 that they describe) so that the rest of the code that operates on it can stay consistent<p>I&#x27;m interested in what an implementation of option 3 would look like. Is it just some regex to find the relevant characters in the string?
评论 #19199808 未加载
评论 #19199665 未加载
rgoulterover 6 years ago
I&#x27;d paraphrase as &quot;for the case of consuming an external API, using generic maps and arrays is more useful than strictly &#x27;decoding&#x27; the data to a type earlier than necessary&quot;. That kindof makes sense.<p>It seems a bit flame-y to see this as &quot;dynamic typing is better than static typing&quot;, though. -- It&#x27;s more of a suggestion that a technique like &quot;cast to a type&quot; where you don&#x27;t need all the info in the type risks breaking when it doesn&#x27;t need to. It&#x27;s better to make fewer assumptions when relying on things you don&#x27;t control.<p>If the external API changes, code breaks whether you were &quot;dynamic&quot; or &quot;static&quot;. &quot;Just change the code&quot; is as applicable to code in either case.<p>That said, it&#x27;s kinda weird that an API can be both unreliable enough as to not conform to a schema, but still reliable enough to trust the data you want to get out of it.
Shacklzover 6 years ago
&gt; I have dealt with terrible APIs that were outside of my control. When I worked at Timeout.com, we had to pull in data from Ticketmaster and also Booking.com. These APIs were inconsistent, and they would change over time. They also left out fields, so all fields had to be treated as an optional, which it made it difficult to enforce a meaningful contract.<p>Wait what? Why would you ever work directly with the data that you grab in some foreign API? You map the data that you actually need into some datastructure of your own making, that you have control over, and that hardly ever changes - unless you want it to. So when the API changes (or even worse, you have to exchange it for whatever reason - it&#x27;s foreign after all and not under your control), all you have to do is change the mapping process, and voilà, you&#x27;re back in your own safely typed world.
tabtabover 6 years ago
One thing that annoys me about static typing is that most of the CRUD programming I do merely martials data back and forth between the screens and database. Only a fraction is processed, or should be processed by the application.<p>Things like null-ability, base-type, and max length should be supplied by the database and therefore not echoed in source code per the Don&#x27;t-Repeat-Yourself principle (DRY), unless a custom deviation is necessary.<p>If the screen validation needs to know such info, it can get a majority of it from the database dynamically. But, our stacks don&#x27;t typically do this for unknown reasons, and thus we reinvent the field attribute wheel in app code.<p>I posted a question similar to this on HN recently: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19146439" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19146439</a>
CharlesColemanover 6 years ago
All of your data structures have types, whether you declare them or not. Your code expects things to be a certain way, and if it&#x27;s not, things break. Static typing just means that you annotate you code with your expectations so you can get some automated error and consistency checking.<p>Automation is good, right?<p>With dynamic typing, you need to <i>manually</i> write more unit tests to get the same level of confidence. That&#x27;s just not worth it for anything important.
评论 #19200018 未加载
评论 #19208951 未加载
rhinoceraptorover 6 years ago
It&#x27;s pretty obvious what you do if a field in a JSON object is optional, you use an optional type. Any good statically typed language has that.
评论 #19200025 未加载
franzwongover 6 years ago
If real world API is as chaotic as he mentioned, how can he even know the data is trustable?<p>From his Java&#x27;s example, I can&#x27;t see how he can fix with dynamic language. He still needs to validate the API response and throw exception even he uses dynamic language. Unless he uses something like functional &quot;Maybe&quot;, so he can safely process the response.
评论 #19199979 未加载
eckzaover 6 years ago
Dynamic typing is great for partially implementing solutions to problems that you don&#x27;t fully understand.<p>This isn&#x27;t always a bad thing, because sometimes &quot;any implementation of a product&quot; is vastly superior to that product not existing, and works well enough, often enough, that any edge cases can be ignored safely.
manishsharanover 6 years ago
Dynamic language proponents make the case about programmer productivity being better with dynamic languages. That may be the case but I have found that integrating systems where one system is coded in a dynamically typed language and others are written in statically typed languages is a nightmare.
tabtabover 6 years ago
One thing that annoys me about static typing is that most of the CRUD programming I do merely martials data back and forth between the screen and database. Only a fraction is processed, or should be processed by the application.<p>Things like null-ability, base-type, and max length should be supplied by the database and therefore not echoed in source code per the Don&#x27;t-Repeat-Yourself principle (DIY). If the screen validation needs to know such info, it can get it from the database dynamically. But, our stacks don&#x27;t typically do this for unknown reasons, and thus we reinvent the field attribute wheel in app code.<p>(I posted a question similar to this on HN recently: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19146439" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19146439</a> )
评论 #19200795 未加载
glorioustaoover 6 years ago
There is a good talk I just watched a few days ago on this topic: Static Versus Dynamic Typing [1][2], which listed the pros and cons of different typing systems, using racket and ocaml as examples:<p>[1] <a href="https:&#x2F;&#x2F;courses.cs.washington.edu&#x2F;courses&#x2F;cse341&#x2F;18wi&#x2F;videos&#x2F;unit6&#x2F;captioned&#x2F;120-static-vs-dynamic-one.m4v" rel="nofollow">https:&#x2F;&#x2F;courses.cs.washington.edu&#x2F;courses&#x2F;cse341&#x2F;18wi&#x2F;videos...</a><p>[2] <a href="https:&#x2F;&#x2F;courses.cs.washington.edu&#x2F;courses&#x2F;cse341&#x2F;18wi&#x2F;videos&#x2F;unit6&#x2F;captioned&#x2F;121-static-vs-dynamic-two.m4v" rel="nofollow">https:&#x2F;&#x2F;courses.cs.washington.edu&#x2F;courses&#x2F;cse341&#x2F;18wi&#x2F;videos...</a>
maxxxxxover 6 years ago
The best I can make of these discussions is that there is no oneand true answer. Some people prefer dynamic typing and some prefer static typing. I myself prefer static especially while I am developing something new because I feel I can be more aggressive in making changes because the compiler tells me immediately what broke. But other smart people feel the other way.<p>So I guess both sides are right but it’s good to think about what suits you best and then embrace that.
intrasightover 6 years ago
I type with two fingers. Would that be dynamic typing? :)
评论 #19199990 未加载
coldteaover 6 years ago
&gt;<i>Why I prefer dynamic-typing over static-typing: the speed of adapting to change</i><p>Funny, that&#x27;s the same reason I prefer static typing.<p>&gt;<i>In How ignorant am I, and how do I formally specify that in my code? I said that I liked to add run-time contracts to a function as I better understand it. When I first write a function, I may not know for sure how I will use it.</i><p>Which is irrelevant. You still know that the &quot;customer_name&quot; argument to it will be a string and the &quot;age&quot; will be an integer, no?<p>&gt;<i>For the programming that I do, I am often creating new architectures. Therefore I need dynamic typing.</i><p>Non seguitur.<p>&gt;<i>Consider dealing with JSON in Java. Every element, however deeply nested, needs to be cast, and miscasting leads to errors.</i><p>Another bad argument. First, if you don&#x27;t cast, and expect an integer like 55 but get a string like John, your program has an error. The difference is that in a dynamic language your program will continue to run doing stupid things instead of crashing in the miscast.<p>&gt;<i>Given JSON whose structure changes (because you draw from an API which leaves out fields if they don’t have data for that field) your only option is to cast to Object, and then you have to guess your way forward, figuring out what the Object might be.</i><p>You can trivially have a JSON parser that returns a list of map of the 6-7 valid JSON types (maps (&quot;objects&quot;), floats&#x2F;&quot;integers&quot;, strings, booleans, null, arrays).<p>You don&#x27;t need to deserialize to specific object structure&#x2F;schema as is the default mode in some parsers, if that&#x27;s what you want to avoid.<p>If you dislike the verbosity of getting nested elements in Java, that&#x27;s a Java thing, not a static typing thing. Heck, it&#x27;s very easy in Haskell (what with lenses and stuff).<p>With a language that supports Optionals and try or has a map index operator and list&#x2F;map literals, it&#x27;s more like JS or Python than Java.<p>If you just want to extract a deeply nested element, and not care what it is, but still use it, I&#x27;m not sure how that works.<p>Do you expect the object at e.g. resp[&quot;x&quot;][&quot;y&quot;][&quot;z&quot;] to change types randomnly?<p>&gt;<i>Static typing does not live up to its promises. If it did live up to its promises, we would all use it, and the fact that we don’t all use it suggests how often it fails.</i><p>&quot;Proper weight does not live up to its promises. If it did live up to its promises, we would all be on it it, and the fact that many are obese suggests how often it fails&quot;<p>How about some uses of dynamic typing are for specific, constrained, use cases (e.g. glueing, quick scripts) and it increasingly breaks down with larger codebases and multi-developer projects?<p>Larger codebases and multi-developer projects either don&#x27;t use dynamic typing (most huge projects the world relies on, from compilers to browsers, and from OSes, to all kinds of embedded hardware, games, desktop apps, etc, are done in one of C&#x2F;C++&#x2F;Java), and others (e.g. large websites) are moving towards some kind of types (e.g. Typescript and Flow).
评论 #19199815 未加载
dtechover 6 years ago
&gt; The widespread use of PHP, Ruby, Python and Javascript suggest that dynamic typing is useful. [...] If static typing lead to greater programmer productivity (via a reduction in bugs) then corporate America would only use statically-typed languages. But it doesn’t.<p>Yes, that is why Java and C++ are such tiny unknown little used languages
评论 #19199982 未加载
mmartinsonover 6 years ago
Maybe this should be called &quot;Why I Prefer Dynamic Typing Over Java&quot;
makkesk8over 6 years ago
I love both for different reasons and pick my flavor according to the size and complexity of the project.<p>Seems fair enough?
fromthestartover 6 years ago
I have three personal reasons to prefer static compiled over dynamic interpreted<p>1. Refactoring. In, say, c++, you change a signature, or a member name, and your IDE provides you with a neat, comprehensive list of errors to fix, if you&#x27;re even performing the change manually. Contrast that with python, for instance, and I have to rely on what appear to be heuristics if I use an IDE to propagate a change, or otherwise repeatedly hit run to change everything that I&#x27;ve broken, and pray I didn&#x27;t miss any code paths that&#x27;ll bite me later. Maybe I&#x27;m just not writing pythonic code, but I find it rather difficult to maintain large codebases in python for this reason.<p>2. Focus. I realized that having a constant stream from a trusted linter makes it really easy to stay on task. I can throw out a bunch of scaffolding and then fill in the blanks based on the constant stream of errors, pre compilation. Sure, in pycharm I can run code analysis to get a list of probable errors, but given the nature of dynamic languages, there&#x27;ll be plenty that&#x27;s missed and plenty that isn&#x27;t necessarily right, and not having a project wide linter in real time isn&#x27;t the same.<p>3. Understanding APIs and library internals. There is a TON of use information that comes for free with explicit static typing, especially for scientific&#x2F;numerical code. In python I frequently find myself having to look up simple function use because arguments, names, and returns can be ambiguous. In a typed language, I know exactly what goes in, what goes out, and how to structure my data appropriately. The difference in coding speed is huge, and I don&#x27;t have to run the code nearly as often to make sure I&#x27;m doing things right.<p>Why anyone would choose python for large projects eludes me!
评论 #19200684 未加载