71 ms·

Strong static typing, a hill I'm willing to die on

• insanitybit 3y ago
  At this point it's beyond a hill I'm willing do die on. I'm not really interested in discussing it. If you don't get it I probably don't want to talk to you about it, I might even think less of you as a software developer. The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high. edit: To clarify, I am on the "types good" side of things
  • wiseowise 3y ago
    The only absolute truth there is. Static typing is nonnegotiable.
    • dartos 3y ago
      There’s strong typing and weak typing. And then, kind of orthogonal to that, there’s also static typing and dynamic typing. I think strong, dynamic typing is just as good as strong static typing (weak typing is objectively bad) As long as the types of your variables don’t change from under you, that’s good, but I’m also okay with the compiler / runtime figuring out what those types are for me.
      • chongli 3y ago
        With "dynamic typing" there is no compiler to figure out the types for you. There is only the runtime to print a stack trace (if you're lucky) and bail out. The whole point of types is to be able to check things without running the program, because exercising every possible code path becomes increasingly untenable at scale. A side (but many would also say critical) benefit of types is that they act as a form of documentation that can never go stale (because they are enforced by the compiler). "Dynamic typing" does not offer this benefit whatsoever.
        • k__ 3y ago
          As far as I know, JS is weakly typed and Python is strongly typed. JS will convert types under your butt if you're not careful, Python won't. Sure, static typing (when done well) is superior to that, but the title talks about strong typing.
        • dartos 3y ago
          Many dynamically typed languages have static analyzers, but retain the flexibility of not needing to prescribe types up front (it’s impossible to know exactly what data structure you need at the start of a project) That’s the crux of why I’m not all in on static typing all the time. (Especially for networked programs that expect a wide range of different kinds of input) Having to prescribe the types I need before I actually need them goes against how I tend to build.
          • sfn42 3y ago
            Sounds like you'd like C#. It does type inference with `var` and similar things, so you don't always have to specify types explicitly, but everything does have a type at compile time.
            • Smaug123 3y ago
              (C#'s type inference is so much worse than F#'s. I find it deeply painful to go back.)
          • loup-vaillant 3y ago
            > Many dynamically typed languages have static analyzers, but retain the flexibility of not needing to prescribe types up front Almost all static type systems have escape hatches that let you go dynamic when you really really need it. Also, I bet that most of your use cases for dynamic typing could be solved with a simple tagged union. Most people bemoaning the lack of flexibility of static typing just don’t know about how tagged unions can easily emulate dynamic typing when we need it, such that we rarely even need to reach for the actual escape hatches. > (it’s impossible to know exactly what data structure you need at the start of a project) Thankfully data structures are even easier to change with static typing: change it, gets a ton of type errors, fix them, done. With dynamic typing you run the risk of missing a call site. > Having to prescribe the types I need before I actually need them goes against how I tend to build. There’s type inference for that. I personally take advantage of it any chance I get.
    • IKantRead 3y ago
      Dynamic vs static typing is a similar level of design decision as interpreted versus compiled. It's ridiculous to try to claim one is universally better than the other as they both have styles of programming and domains they are better suited for. I would never want a statically typed, compiled awk for example. I generally think large, production, multi-developer software should be written in a statically typed, compiled language. Strong vs Weak typing is a closer to a debate about having a name spacing system or not. There is really no great reason to have weak typing or not use a name spacing system.
      • wiseowise 3y ago
        It’s not ridiculous at all. Mainstream dynamically typed languages are moving in statically typed direction. Python (Mypy, Pyright and others), Ruby (Sorbent, Rbs), JavaScript (Typescript, Flow). How many statically typed languages optionally removed types?
        • IKantRead 3y ago
          It's a bit sad to me that people can only imagine writing code for large production systems. Static types are hugely beneficial in this area which is why we see this trend. Personally I think Python moving in the direction of static typing is a mistake, dynamic typing is very useful for domains where python is strongest: modeling, statistics, scientific computing etc. It's also part of the basic design of Python to be a dynamic language. Likewise Ruby, with it's heavy use of metaprogramming, also benefits tremendously from a lack of types. But let me be clear: I do think statically typed languages are a very good idea for large production systems, I just personally do a lot of programming that's not for these systems. > How many statically typed languages optionally removed types? I wouldn't say "removed" types, but I've been in software along enough to remember when dynamic typing was the big hot thing and crusty old Java devs complained that we couldn't possibly live without static type annotations. I distinctly remember when C# introduced `var` (which is of course really type inference, not dynamic typing) to appeal to devs that were growing weary of types. There's a great example in SICP of implementing a full object system in just a few lines of code that would not be possible to implement as elegantly in a statically typed language. Do I want that for a production system? No. But there is, or at least used to be, a world of computation being done for reasons other that quickly getting PRs pushed out to prod.
  • tasn 3y ago
    Author here. I ended the post with: > I can see both side of the arguments on many topics, such as vim vs. emacs, tabs vs. spaces, and even much more controversial ones. Though in this case, the costs are so low compared to the benefits that I just don't understand why anyone would ever choose not to use types. > I'd love to know what I'm missing, but until then: Strong typing is a hill I'm willing to die on. I genuinely want to know what I'm missing. I also outlined in the post all of the arguments I usually see in favor of not having types and why I disagree with them. I'm happy, willing, and excited to hear what I'm missing.
    • a_c 3y ago
      I think you and parent are in agreement
    • insanitybit 3y ago
      Hey, I hear you, and I commend you for your good faith position of "I want to hear both sides". I'm just not there anymore. The arguments put forth ("the cost is worth it, it makes up for itself", etc) are arguments I've had a million times and I just no longer will engage.
      • tasn 3y ago
        Oh, apologies, I misread your comment. I thought you were saying that you won't engage in this discussion because of my strong stance on the topic. I'm a big fan of "Strong beliefs, weakly held".
      • junon 3y ago
        Same here. Been doing this for too long that I refuse to even bother anymore.
    • randomdata 3y ago
      > I just don't understand why anyone would ever choose not to use types. Is there a language out there that gives you that choice? I expect you mean choose not to use strong static typing as per the original piece? Compatibility is a pretty good reason. I'd like to see Javascript die in the fiery pits of hell as much as the next guy, but its positioning means it is almost inevitable that some system will make it the only reasonable choice for you to choose if you want to build for that system. Typescript doesn't help. It adds static typing, but not strong typing.
  • c048 3y ago
    People that still want to try and fight it either: - Use notepad for development (don't laugh, I've actually encountered a dev who's choice IDE was notepad). - Never worked with more than 1 person on a project. - Never worked on anything but tiny projects. - Never re-opened a project after having worked on a different project for several weeks.
    • Qwertious 3y ago
      You should legitimately try a project in notepad. Not Notepad++, specifically Notepad. Probably a very short project, but you should give it a shot. It'll give you a bit of a perspective. And some real appreciation for Notepad++.
      • bluGill 3y ago
        I've been forced to use ed (serial connection to an embedded device that didn't support TERM), what does notepad give?
  • halfmatthalfcat 3y ago
    I've worked with my fair share of vanilla JS devs who refuse to acknowledge the benefit of more statically typed variants of the language. Most of them bemoan the upfront cost of typing everything without realizing the benefits of it. I absolutely think less of them as developers.
    • giraffe_lady 3y ago
      Not liking typescript is not the same thing as denying that types are valuable. TS has a very complex type system in exchange for relatively weak guarantees about correctness. That's a tradeoff you can choose to take or leave depending on the problem at hand, and holding that position is not the same as believing types have no value. Unless you're talking about elm or rescript or something then sure sure. But usually when people say things like this they mean typescript.
      • junon 3y ago
        This is pretty much my take, too. I don't hate the idea of TS, but TS is so painful to work with, and it's owned by a company I really don't like, too.
        • dmix 3y ago
          OP is saying it's provides weak guarantees which is a result of the fact they made it easy to adopt and implement among legacy untyped code. It's the opposite of painful to work with for typing systems, compared to something like Rust which has stronger guaruntees and more predictable patterns but hard requirements the full stack is type. The result in TS is plenty of "any"s everywhere and in legacy code some situations where it's mostly just a thing veneer of type safety. But all of that makes plenty of sense because in the early days it was rare to work on a real life production JS project that was pure TS from day one in addition to having TS only libraries. These days it's everywhere and the work has been done to move away from rampant anys in popular libraries. The tooling is also mature and it's rare to find major JS libraries not already packaged with types or a @types import. Turbo moving away from TS was the rare exception.
  • msla 3y ago
    Similarly, choosing between 'int' and 'long' isn't part of a type system, unless the only semantics your data has is being an integer of a given width. Types are semantic, and telling me "height is 32 bits" tells me jack shit about units of measure or anything else.
  • pfdietz 3y ago
    Strong static typing is useful in the environment where the code is not adequately tested. That's because tests adequate to make the code bulletproof will also detect the problems strong static typing could detect, rendering SST superfluous. So, how often is poorly tested code out there? From the popularity of strong static typing, it must be ubiquitous.
    • ozr 3y ago
      Ubiquitous is a good guess.
    • dolmen 3y ago
      The point of static typing is that the compiler does checks before your program even starts. And that avoids to write lot of coverage tests that are needed (but usually just ignored) with languages that massively use loosely typed data containers (variables).
      • pfdietz 3y ago
        Sure, if you're going to be in an environment where the code is going to be bad because of inadequate testing (and I admit this is quite common, due to the cost of the testing needed), static typing lets it be somewhat less bad. It's just important to understand it's a band-aid, not a panacea.
        • marcosdumay 3y ago
          Testing is a bandaid that only pretends to show that your code is correct. Static verification (what includes static types) is the real deal. That said, WTF is there with people insisting that types must be either static or dynamic, and that dynamic types are useless?
          • pfdietz 3y ago
            Static typing, as done in mainstream languages, doesn't show your program is correct. Is you compiler written in a mainstream language correct just because it compiles? Of course not. Don't point to academic curiosities with dependent types if they aren't actually used. Extensive testing, on the other hand, is used in the "real world" for assurance.
  • bitblender 3y ago
    I don't consider it productive to be personal about technical topics. It's best to divorce yourself and the other party from the issue to limit as much bias as possible. You don't need to worry about the good-faithness of an objective, egalitarian discussion. It's never truly objective, but you can at least catch yourself saying things like "I might think less of you as a developer" and recognize that's a preconceived notion. In some cases, it may be turn out to be accurate, but it's definitely not always. Dynamically typed languages have had an important role historically in software. We should not categorically denounce people who prefer it as lesser developers. I also generally prefer static types.
    • insanitybit 3y ago
      I explicitly said "as a developer" because it's not a personal judgment. You can be a good person and also have a terrible take as a software engineer. > We should not categorically denounce people who prefer it as lesser developers I don't think you've justified this point. I'm comfortable with my position on this.
      • eduction 3y ago
        What you say is true, but it’s also true that the person you are replying specifically made their remarks about productivity - you’re both talking about what is best at work. It seems reasonable to argue that statements that you won’t even discuss X any more and would rather judge the person as less competent professionally are unproductive. Not saying I agree, btw. But it does seem like a pretty basic point. One of you is talking about preserving your sanity and the other about output. It’s not necessarily a disagreement even.
        • PH95VuimJjqBqy 3y ago
          > any more and would rather judge the person as less competent professionally That is absolutely NOT what the other poster said. They said they _MAY_ judge them that way.
          • 3y ago
  • bennyelv 3y ago
    Amen! I'm currently responsible for a very large system built in raw javascript where function definitions like this one in the article: function birthdayGreeting1(...params) ...are the religion. It's awful. I hold the people responsible in very little regard.
  • KronisLV 3y ago
    > At this point it's beyond a hill I'm willing do die on. I'm not really interested in discussing it. If you don't get it I probably don't want to talk to you about it, I might even think less of you as a software developer. That's a pretty strong take! I don't think there are many things that I feel similarly about... maybe if someone suggested that they don't need test environments and can just deploy changes to prod without testing or CI/CD and just see what happens, when it'd be my employment on the line, but even that's a pretty contrived and out there example. > The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high. My problem is that not all type systems and the way you use them are equal. When working with back end code, I really like .NET or even Java having a type system there for me. I know that people suggest that they have their own shortcomings (type erasure, NPEs, no multiple inheritance, even smaller things like C# enums not supporting methods) and that there are better options out there, but generally you can turn off the part of your brain that'd worry about the language too much and just deal with the domain problem at hand. Something like JetBrains are also excellent, because with the type system suddenly the tool also can reason about the language constructs you're using and give you all sorts of good suggestions and refactoring options. Whereas with something like TypeScript in combination with React, there are times where you fight the type system instead. That's just the impression that I got working on a few projects for a while, in comparison to React with JS (perhaps the code was also a bit too clever), while with Angular it felt more coherent to me (despite Angular being more complex otherwise and not really my first choice). In the end, I gravitate towards Vue with JS for my personal stuff, but it's not like you can just say no to TypeScript when you need to maintain something long term. I can't actually remember who said that they ditched TypeScript for similar reasons, but the argument was basically that a non-insignificant part of their codebase was there just to satisfy the type system. TypeScript does what it's supposed to... but it feels like it could be easier.
    • insanitybit 3y ago
      > That's a pretty strong take! Not even one of my spicier takes, just one of the few that I simply don't care to engage with further. > My problem is that not all type systems and the way you use them are equal. We agree. Some type systems suck so badly that I can see why people would be tempted to believe that all type systems suck.
  • pharmakom 3y ago
    Also on the “types good” side of the fence. HOWEVER, I also believe that mainstream typed languages cannot represent some situations very well. Often the only attempts to do so are in some weird Haskell extension and it feels rather… inelegant. Bottom line: types are better; but our current type-systems are not the final word on types.
  • omnicognate 3y ago
    > The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high. > edit: To clarify, I am on the "types good" side of things I agree. Python 1 would have been worthless if it didn't have types.
  • fsdjkflsjfsoij 3y ago
    This is basically where I am at. Most libraries and applications are trivially typed even in languages with relatively poor type systems like Go and Java. The necessity, or even benefit, of weak and/or dynamic typing is extremely rare and most languages have workarounds or escape hatches for those exceedingly rare cases. Dynamic typing also makes a ton of optimizations basically impossible and even after monumental efforts languages like Javascript are still quite slow, inconsistent and memory inefficient outside of trivial benchmarks.
    • diggan 3y ago
      > Javascript are still quite slow, inconsistent and memory inefficient outside of trivial benchmarks. I thought this meme was dead already. Of course, you might not be able to squeeze out the same amount of performance compared to a brilliantly written C or Rust program, but for what it is, JavaScript is pretty damn fast already. DOM manipulation on the other hand, is still a very common bottleneck people come across when writing typical JavaScript code.
      • fsdjkflsjfsoij 3y ago
        > but for what it is, JavaScript is pretty damn fast already. It's fast compared to other dynamically typed language implementations but it's still very slow compared to basically all of the popular statically typed languages.
        • wilde 3y ago
          JustJS would like a word https://www.techempower.com/benchmarks/#section=data-r20&test=composite https://www.techempower.com/benchmarks/#section=data-r20&tes...
          • fsdjkflsjfsoij 3y ago
            Trivial benchmarks where all of the significant data structures and networking are done in C++ and the tiny amount of Javascript is just passing some strings around. I guess it's "fast" if you can restrict yourself to little more than hello world where you do nothing more than pass a few strings to functions written in faster languages. Notice that in the Java, C#, Go, Rust, Swift or Ocaml benchmarks almost all of the underlying data structures and much of the networking stack are built in the respective language. This is not possible with Javascript, Python, Ruby etc. because it would be ludicrously slow and extremely memory inefficient.
  • jerf 3y ago
    There's a temporal component to the argument. Strong typing in the 1990s wasn't very good. Dogma at the time resulted in very rigid designs. The verbosity of it all was staggering. Incorrectly-used Hungarian notation ran rampant and made everything hard to read while still not helping anything [1]. The costs were a lot higher than it is today and the benefits a lot less. Nowadays, the static typing is much nicer, with both higher benefits and lower costs, and it makes the costs/benefits analysis much more likely to come out in favor of static types. In the late 1990s when I was cutting my teeth, I did a lot of Python, and I was almost 100% dynamic language until ~2015. In hindsight, I might do the same again even if thrust back in time. There just isn't a great static option back then. (I'm not saying 2015 is the year it became practical, I'm saying that's when I finally moved into static languages. 2010-2015 or so I was in Erlang, doing things that most other languages couldn't do at the time, so that forced me into a dynamic language. C# was looking pretty good in that time frame too, it just wouldn't have run the systems I had on anything like the resources I had at the time. It could probably easily do it in 2023 though.) Now I even prototype in static systems, and it's a better experience than prototyping in Python was. Like, by quite a lot, honestly. In the end, I don't find it that much of an impediment to make sure that if I want to call a method on a thing, that the method actually exists. Dynamic typing will never disappear; there's a certain small size of task for which it'll always be more advantageous than static typing, and while said tasks may be small, there's a lot more of them than there are large tasks, so it's a completely valid and sizable niche. But I do think over the next 10-20 years we're going to see the "scripting" languages return back to "scripting" and away from "systems". I think that in the end, the dynamic scripting languages being used for large tasks will be seen as a reaction to a misdiagnosis of the problems in the 1990s. The code was atrocious in the 1990s not because it was statically typed, and therefore the solution is to go dynamically typed. The code was atrocious in the 1990s because it was poorly statically typed, and the solution was to get better. That said, "getting better" did take a long time, and for many legitimate reasons. (Much ink is spilled on the so-called rapid pace of technological innovation in our industry, but programming languages move on decadal scales. Programming languages still have only barely grappled with a multicore world, and haven't grappled with a heterogenous computing world at all (GPUs on one end, efficiency cores on the other). Things are not always in as much motion as we fancy.) [1]: Particularly, Hungarian notation is supposed to supplement the type, not just reiterate it. If you're in a language where you can't easily declare "a width is an int", then Hungarian notation suggests calling a width variable something like "wdthDialog", so that you stand a chance of noticing that you passed a "hghtDialog" in the wrong place. But the way it was used a lot of the time is you got "u16Width" instead, where u16 meant unsigned 16 bit int... but that's already in the type. Using it that way just adds an extra layer of hierglyphicness to the already ugly code. One of the several innovations that made static typing languages more feasible is that in most languages designed in the last couple of decades, you can declare something like this with something like "type Width int", and then you don't need to label any variables with it at all, the compiler enforces it.
  • throw1234651234 3y ago
    I think this is especially true for line of business applications that have the following qualities: 1. It's simple. Let's not lie, let's not pretend. It's CRUD. You can put in K8S, you can add AI, it can be behind an API Gateway, you can make it all Event Driven, you can use CQRS for every entity because you really, really want to feel clever. But it's still CRUD. 2. Other people are working on it, many other people. 3. People from other companies are interfacing with it. So knowing what to expect trumps everything. Types help with that. They help a lot.
  • stratigos 3y ago
    Unfortunately this attitude is not profitable, and also smacks of someone who works on their own island and costs a business more than they add value given their inability to work as a team. This attitude might find a way to be profitable when held by a university professor, though that does not mean its desirable.
    • insanitybit 3y ago
      This is not a "work" attitude. I would never impose my opinions on a team. I've worked professionally in many languages with a variety of type systems. In virtually all cases I have reviewed very positive feedback throughout my career, in particular in terms of my ability to work well with others, to mentor, etc.
  • WirelessGigabit 3y ago
    I actually like this approach. I believe in mentoring. I believe in building bridges. But if we're on opposite sides of the Grand Canyon, it's not worth my time.
  • mpweiher 3y ago
    Well, getting this personal about a purely emotional preference might make people think less of a person that does that, with significantly better justification. To be clear: people have tried to show the long-claimed safety benefits for a long time, and they just refuse to appear.
  • AlchemistCamp 3y ago
    This is a very arrogant and dismissive attitude to take. Consider that both pg and DHH prefer dynamic typing. Maybe you can think less of them as devs, but what each built is undeniable. What have you built or added to the field that justifies such a lack of tolerance of those who don’t subscribe to your point of view?
    • insanitybit 3y ago
      I reject the idea that pg/DHH should be treated with any authority here, and I reject the idea that I need to prove my authority to you. That said, yes, of course my post is arrogant and dismissive. I am outright saying I won't engage in a conversation. I'm comfortable with that.
      • LaGrange 3y ago
        > I am outright saying I won't engage in a conversation. It's actually arrogant and dismissive because you say that in a way clearly intended to spark a conversation. Also, pretty much all arguments for explicit typing suffer from mechanistic bias (see, https://www.youtube.com/watch?v=NmJsCaQTXiE&t=143s https://www.youtube.com/watch?v=NmJsCaQTXiE&t=143s). I'm comfortable saying I just enjoy tinkering with a formal description of a data structure, because I'm a type enjoyer, not a type fan.
        • insanitybit 3y ago
          > It's actually arrogant and dismissive because you say that in a way clearly intended to spark a conversation. I don't follow at all. Why would it be arrogant or dismissive to say something in an attempt to discuss it? I commented in good faith to an article that has a strong opinion ("willing to die on this hill") with a reflection of my own strong opinion ("unwilling to discuss"). At most you could say it was inflammatory, which wasn't intentional although looking at the insane number of child comments it apparently ways.
  • nkozyra 3y ago
    I'm baffled it's even a debate. Who wouldn't want strong typing? What's the argument?
    • digging 3y ago
      Mostly, it boils down to selfishness and "laziness". (Although I try to be very careful about that term, because I do not believe in it as generally used. I use it here to define: an unwillingness to plan ahead and to have to learn something new. Not applied as a global personality trait but only used in context.)
    • pxmpxm 3y ago
      These days you get loads of people without CS degrees that spend their days as python/js "coders" for things that don't really matter.
  • zare_st 3y ago
    I'm not sure what I'm reading here. Types are integral part of standard programming languages. If you mean "types bad" as in BASIC/Javascript variables, then yes I fully agree. These languages were never meant to be a solution for professional software engineering. Once a language has proper types, it can be "weak typed" by not forcing "strong typing" by being dynamically typed in nature. If the language has normal preprocessor support, the static type system can be added on the project level. And then in essence you get a strong typed environment in a very thin programming language such as C. Let's take a big C or C++ software project, the process behind it. Of course, the project is in those languages because it requires native opaque pointers and hardware access. The project has coding style, it has arbitrary rules. Although there is little to stop anyone from making a mess in C or C++ code there is entire code infrastructure and CI/CD chain around it. Lets say the rule is no void pointers without encompassing struct that's a type that can be checked via macro system. If you wrongly use the type struct, you get stopped by the project build. If you go around the rule, you get stopped by a code analysis after commit (and get in trouble for doing that).
  • edem 3y ago
    Same here. Whenever someone starts babbling about why __language x__ is hard because of types or whatever, I just disengage. I don't care what anyone thinks about types. I use them, and I will keep using them no matter what.
  • yowlingcat 3y ago
    > The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high. I think that says more about the strength of your zeal than of your argument.
  • yetanotherasian 3y ago
    How often do you write bash scripts or do you always write all automation in some other language? Just curious how much your conviction influences your behavior
    • bigstrat2003 3y ago
      Speaking for myself, I never write bash scripts if I can help it (though sometimes I can't help it). That isn't so much because of typing, though... it's because bash is a fucking horrible language that should have died 30 years ago. The fact that there's no such thing as types in bash is just one of many reasons why it sucks to use.
    • insanitybit 3y ago
      I write code without static types all the time. Daily probably. I am "pro types" in a hand wavy way. My conviction is to no longer engaging in the debate.
      • scbrg 3y ago
        I'm glad to see that you've replaced debating type systems with debating debating type systems. I'm sure it's a great productivity improvement ;-P
        • insanitybit 3y ago
          It's not like I've barred myself from engaging in any discussion where the word "type" shows up
  • codegeek 3y ago
    I don't necessarily die on that hill but I definitely want to fight on that hill.
  • nsajko 3y ago
    You're confusing static typing with the existence of a type system. As an example, Julia has a rich type system, but the language is dynamically typed.
  • iopq 3y ago
    There's ONE argument that I'm partial to: if you get the static type system wrong once, there's no going back Take for example, Rust: mut, Send, Copy, Drop, Debug, dyn have all their warts because they are special and you can't fix them because you'll break previous code. In a gradual typing language you could potentially bolt-on your own type system as a package where it just runs the type checker if you want one. It just so happens people who favor these gradual typing systems don't do a good job of creating those typing systems because they are not that into types in the first place. But in theory, this kind of a system would let you not worry about types when prototyping the system, then put some bounds later based on your requirements.
  • patrickthebold 3y ago
    I'm with you, especially in my professional life. That said, I think Clojure is interesting and Rich Hickey has some good talks in support of dynamic typing.
  • TheBlight 3y ago
    Not really interested in discussing it. posted on discussion forum ;)
  • JonChesterfield 3y ago
    It really matters which static type system is in question. SML or Haskell? Yep, like those ones. The languages would not be so useful without their compile time type checking. C? Not worth the trouble. C++? Not worth the tarpit or the trouble. Python? Definitely not keen, that language was much better without the annotations. Typescript people really like but I haven't played with. I'm pleasantly surprised that unsound static + sound dynamic works well. Type annotations are not inherently good. Some type systems add a lot of value, some really don't.
    • oldpersonintx 3y ago
      type ":t" in ghci for many common Haskell types (functions are also types fyi) and tell me if you have the faintest idea what you are reading lots of comments here praising Haskell and Rust frankly seem to be coming from people with a superficial understanding or limited exposure I've had rustc complain about type deductions that were over a line long...that's just one inferred type...you can easily paint yourself into a corner with a type system with no exit other than trying to cajole the right definition out of the compiler and then you copy-paste it and pray
    • xigoi 3y ago
      > C? Not worth the trouble. C++? Not worth the tarpit or the trouble. The OP said strong static type system, so C and C++ are out of the question.
    • chongli 3y ago
      This is not about type annotations, it’s about type systems. You can write Haskell programs without any type annotations. Your program will type check and compile just fine. The value comes from the checks (as well as the inference, documentation, optimization, and everything else a modern type system gives you), which you don’t have to write yourself, you get them for free. People who say they prefer dynamic languages are really just saying ‘no’ to all these free benefits.
      • JonChesterfield 3y ago
        If your language is wholly type inferred, and the type system is expressive enough to deal with whatever one wishes to write, it is indeed "free". If you ignore compile time performance, run time performance, and that you're writing in something between Idris and vapourware. Otherwise the cost is merely being unable to write anything that the type checker does not understand, and however long your compiler takes to do the checks on what it does understand. Also a fair chance the whole program must type check before you can see the results of changing a subset. In the worst case you get to hunt down all the unused variables before it'll run the test suite. I prefer dynamic languages. That makes me a heathen on these boards, to be ignored or chastised for my stupidity. Regardless, those benefits do not come for free.
  • oldpersonintx 3y ago
    languages do not exist in isolation if I store sql with a column definition that stipulates that the value must be an int between 1 and 3...what difference does it make if I accidentally create a corresponding variable with the value "fred"? it will never be persisted furthermore, you can run in to even more confusion with a language type that is not properly aligned with the database type...which one wins? the db obviously, since language values not aligned with database definitions will never be persisted
  • sbjs 3y ago
    Yeah I've been in that camp since like 2016. TypeScript is basically an essential for me now, and I don't debate it with anyone. If they don't get it, it just gives me a baseline understanding of how little experience they have in real world software development.
    • Rapzid 3y ago
      That's a good year; TS had just added async/await.
  • oweiler 3y ago
    God, what has become of healthy discussions? People getting more and more toxic these days...
    • insanitybit 3y ago
      I'm all for healthy discussions, but I think it's fair to say "I've had this discussion enough times, unless you're really bringing something new to the table, I'm opting out".
    • digging 3y ago
      Is it really a healthy discussion? At least with respect to JS vs TS (which is the most common argument as it's a choice every front end team has to make), it's blogs saying "fuck types, I like JS only." I'm not going to step in and tell another team what to use but whining about the difficulty of static typing is just not a productive conversation. I've been converted by the top level comment; I'm not longer interested in entertaining the discussion.
  • bcrosby95 3y ago
    I don't use dynamically typed languages because they're dynamically typed. I use them for other reasons and they happen to be dynamically typed. I'm not going to argue that these features are only possible because of dynamic typing, but regardless, statically typed languages tend not to have them. Elixir may get "some form" of typing, but it likely won't be traditional static typing.
    • syndicatedjelly 3y ago
      What are those features?
      • bcrosby95 3y ago
        STM, REPL, and data driven nature of Clojure. I know most people don't use STM in Clojure, but I find it to be a killer feature for some projects. Combined with pervasive immutability and it enables concurrent designs that are very difficult to pull off in other languages. For Elixir, the concurrency model and supervisor trees. It's a perfect fit for some problems, and in general as a small company, the projects we use Elixir on greatly simplifies our production environment which is always a win. Most of my focus when designing a project is to enable people with less experience than me to contribute in a bug-free fashion in the face of concurrency and parallelism. Sometimes that involves picking a funny language, sometimes it doesn't.
  • optymizer 3y ago
    I find it interesting that people in this thread seem to have absolute certainty that "types good" is true, while to me those two words together are largely non-sensical, just like "bytes good" wouldn't make much sense to debate.
    • prewett 3y ago
      After you repeatedly waste a bunch of time debugging things that static typing would have caught on the first compile, and you start developing a "types good" attitude. If you just do simple React development, you might not ever run into the problem. But once your programs get to a couple thousand lines, you start occasionally forgetting what your function takes and passing in the wrong things, which then get passed around for a while and throw an exception long after the problem happened. This results in very unfun print-debugging, particularly in a recursive descent parser or an algorithm that processes a lot of data.
      • leptons 3y ago
        >But once your programs get to a couple thousand lines, you start occasionally forgetting what your function takes and passing in the wrong things, which then get passed around for a while and throw an exception long after the problem happened. I've been writing code for 40 years, I can't estimate how many loc I've written, but likely over a million. One of my personal projects is currently over 65k loc vanilla js, and I never once had a problem with not knowing what type a function took. If you're so bad at naming things and knowing what a function does, I guess maybe types can help you. But not everyone needs it.
        • optymizer 3y ago
          I'll take the time to reply to both of you, because you seem to have opposing views. I think such a debate is largely unproductive. Like anything else, types have value (ha) and successfully capitalizing on that value depends on the context of the project, which includes things like developer experience, tooling, project complexity, requirements, deadlines etc. The only productive outcome of these debates is that each developer gets to slowly and frustratingly build a list of pros and cons as they go through the arguments presented by either side debating this topic. In addition, developers who completely disregard either the cons or the pros are necessarily making subjective decisions with incomplete data, and the project gets to pay the price. Just because the developer is personally OK with all of their projects paying that price, doesn't mean it's the best decision for a project. My experience has been that when starting out, projects get the most value out of not having types, and as they grow in scope and size, and the cons of not having types start creeping up, that's the point when gradually transitioning the code to being strongly typed allows the project to maintain its velocity _and_ quality.
  • flohofwoe 3y ago
    So... about the strong part in 'strong static typing': Many years ago I thought that it's a good idea for a game math library to have separate strong types for 'point' (a location in 3D space) and 'vector' (a direction and magnitude in 3D space), and allow/disallow certain operations (e.g. 'point + vector => point' 'vector + vector => vector', 'point - point => vector', while 'point + point' is illegal). Sounds absolutely great in theory, but in practice it was a royal PITA to work with, but it took me much too long to realize this (how can it be such a hassle when in theory it's such a good idea!) I soon went back to a general 4D vector class (where a 'point' is defined by .w = 1.0, and a 'vector' by .w = 0.0), and some debug-mode runtime validation (which catches things like trying to add a point to a point). Of course strong typing also often makes perfect sense, for instance in a 3D rendering API it should be a compilation error to provide a texture-handle where a buffer-handle is expected, but after this experience with points vs vectors (which should've been a classic showcase for strong typing) I would never again "die on that hill" :) TL;DR: static typing: yes! strong typing: it depends.
    • Someone 3y ago
      > For things like kilometers versus hours I'm still undecided. Those help you more if you do a lot of math involving both them, but that’s also when it becomes a nightmare in most programming languages because of an explosion in the number of types. Let’s say your code computes 3km × 4hours If so, you need a “km hour” type. In many languages, you also have to write code to make that happen, and to make it have the same type as 4hours × 3km Even if you don’t ever store values with those types in variables, you also may need types for per km, per hour, km² and hour² for expressing the types of intermediate values (for example, in a physics computation, you may encounter √(3km²/4hour² to compute a velocity in km/hour) And that’s ignoring that you may - encounter minutes, meters, yards, etc. - want to use algorithms that compute exp(3km) or log(4hours). What types do these have? Here, you probably want to forget about string typing values.
      • flohofwoe 3y ago
        Apologies, I edited my post while you wrote your reply and removed the kilometers vs hours thing. But your reply makes perfect sense, and I think this "type explosion" is my main gripe with too extremist strong typing.
  • waffletower 3y ago
    In my country, the United States, we have broad protections for religious beliefs.
  • scarythrowaway 3y ago
    I mean, that's one reason I like dynamic typing, I get to avoid a bunch of psycho cargo culters for free. cries at the thought of insanitybit not respecting me
  • thefaux 3y ago
    > If you don't get it I probably don't want to talk to you about it, I might even think less of you as a software developer. The feeling is mutual.
  • fargle 3y ago
    and yet... here you are discussing it. ;) discussions are a two-way street. if you aren't getting it, then how do you expect someone else to "get" your position? "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts" -- Bertrand Russell [edit: To clarify, i am on the "i like strong static typing most of the time but also understand their pros/cons wrt. dynamic languages" side of things]
  • lasermike026 3y ago
    Understand that there is no hope. You will die on that hill. Get over it.
  • deleted 3y ago
    [deleted]
  • leptons 3y ago
    Trigger warning: I love to write assembly language. I probably love assembly language more than C#, or C++, or any of the strongly typed languages I use. Assembly language has no types. It doesn't pretend types even exist. Are you going to look down on me because I like to write assembly language?
    • insanitybit 3y ago
      > Are you going to look down on me because I like to write assembly language? Nope.
  • deleted 3y ago
    [deleted]
  • ActorNightly 3y ago
    Here is a fun fact that you don't realize. Say you can do the project in 2 ways. First way is to use a strongly typed language, think about the data, and design your code in the appropriate way. You code it up, go through the loop of compiling and fixing errors, and get your code to run. The second way is to write your code in Python, without worrying about strong types. You complete the code quite a bit faster, but since you also want your code to be correct, you spend time writing an end to end test suit for your code. The second approach is not only faster (since you are writing tests in both cases), its overall better. Spending time writing tests allows you to essentially validate things that modern mainstream strongly typed languages can't catch at compile time (for example, what happens when the input is unicode strings?). It also forces you to think about end to end behavior and making sure that is correct, rather than just the behavior within your code. Strong typing is a simply hand-holding tool for programmers. If you cannot write correct code without it, you are on a fast track to being replaced by AI eventually. The future of programming is not going to be designing data structures and types, its going to be using English to generate large chunks of code in most likely Python, and then tweak fine details in those.
    • jghn 3y ago
      Using your example - have a type that that enforces Unicode strings (or vice versa)
    • gdcbe 3y ago
      Call me sceptical, but I don’t buy it. What makes you certain that’s the (one) future… Also programming is a super broad field, and more then a field is almost more like a medium then a field. I honestly don’t know if we’ll still program by hand or not, but I do look skeptical at people who are very certain we won’t. Don’t think that’s the first time in history people make that prediction…
      • ActorNightly 3y ago
        Compilation at its core is a translation problem. Right now, it would be fairly trivial to train an LLM to essentially be a compiler. And, you can already prompt LLMs on generating code for a wide array of things. As far as adoption, there is a reason why dynamic type languages that feature a lot more natural syntax (Node, Python) are used WAY more than others.
  • brightball 3y ago
    I'm firmly in camp "it depends" but it was nice almost talking to you. :-)
  • auggierose 3y ago
    I don't know, that is so last millennium. If you prove your software correct, you won't need a static type system, it just gets in your way. And that's a hill I am willing to die on.
  • RHSeeger 3y ago
    Sometimes the question isn't "are types good", it's "are the costs associated with static types worth it for this particular use case". And the answer is almost always yes; but the "almost" there is important.
  • manicennui 3y ago
    This is the sort of position that is baffling to me. Software engineers claim to be very logical, but this boils down to a preference being stated as some kind of objective truth. Show the evidence (not anecdotes) that static typing gives benefits that are worth the cost. My anecdotal evidence is that I rarely come across problems in production code that would be solved by static typing and people make the same sorts of logic mistakes in languages like Java and Typescript.
    • manicennui 3y ago
      Arguably, nullability and mutability are issues that cause far, far more issues than dynamic typing.
      • tubthumper8 3y ago
        Null reference errors are examples of errors that can be caught before runtime by a static type system. The fact that static type systems like Java don't catch this is evidence that static vs. dynamic is not a binary - some static type systems are better than others.
  • asdajksah2123 3y ago
    I think the conversation becomes a lot easier once you recognize that there is no such thing as untyped data. There's only explicit typing and implicit typing. So the only real argument you're having with someone is when writing a piece of code, do they want the caller of the code or the input of the code's data type to be known or they want the data type to be a mystery to be figured out, occasionally in production when shit hits the fan.
  • deleted 3y ago
    [deleted]
  • throw10920 3y ago
    > I reject the idea that pg/DHH should be treated with any authority here, and I reject the idea that I need to prove my authority to you. > That said, yes, of course my post is arrogant and dismissive. I am outright saying I won't engage in a conversation. I'm comfortable with that. This is an extremely toxic attitude. I wouldn't be interested in working with you in any professional capacity, on an open-source project, or having you as a friend, and as a matter of fact if someone expressed this attitude at work I would complain to HR.
• deleted 3y ago
  [deleted]
• vouwfietsman 3y ago
  Couldn't agree more. I suspect in the future software professionals will be apalled by the abuse of freedom that we currently have in languages. The more freedom we take away, the higher quality software we produce. Looking at you, Rust.
  • goalieca 3y ago
    This is an old thought but one which favours declarative languages over procedural ones.
    • vouwfietsman 3y ago
      No it's not, I had it just now.
  • deleted 3y ago
    [deleted]
  • wait_a_minute 3y ago
    > The more freedom we take away, the higher quality software we produce. How are you measuring this?
    • vouwfietsman 3y ago
      Every fortnight during a full moon. All kidding aside, obviously I don't. That shouldn't detract from my statement at all though, nobody measures anything about software. We're all in the dark. Thats actually reinforcing my beliefs: we are in the dark because software is unmeasurable because of the freedoms taken by programmers that fail to abstract or fail to be formalized. Formalizing software, and then starting to measure changes rigourously, is the first step we have to take towards becoming a mature industry. Formalization is the oposite of freedom. People think software is like art, where freedom of expression broadens horizons. This is no longer true, most software is not art, most software is buttons that make money when clicked.
      • 3y ago
• bspammer 3y ago
  Asking someone to maintain an untyped codebase is like asking them to play a game without telling them any of the rules.
  • riskable 3y ago
    Your statement reminds me of the spoon scene in The Matrix: Instead of trying to bend the code to fit within the confines of its types simply try to realize the truth... Static types are just more code. They're extra conditions that we apply to things like function signatures and variable definitions instead of adding conditional checks where it matters. "Aha!" you say, "but by enforcing conditional checks at variable definition and inside function signatures we don't have to check them ourselves in our code and the compiler itself can check them to ensure correctness and optimize performance!" ...and I'd agree with that sentiment but I'd also add that by having to reason about your types constantly you're adding a non-trivial amount of mental overhead when structuring your code. For some people that's how they reason about their code anyway but for others, having to consider whether or not a number is a `u8`, `u32`, or `usize` adds a lot of complexity to the code that could very well be entirely unnecessary depending on the use case. Consider, for example a program that's meant to be executed on the command line that takes two numbers and adds them together. No matter what language you use you have to convert the raw string input into a numerical type before performing the addition. In Python you have a simple function, `int()` that will happily turn any string consisting of numbers into a proper integer that can be used for math operations. If it gets something that isn't a number it'll throw an exception which is trivially easy to detect and wrap in a `try`/`except` block with a user-friendly error message. If we wanted to support floating point numbers we could just use `float()` and the code would otherwise be exactly the same. In strongly-and-statically-typed languages this same process involves considerably more overhead. Before we can select a function to convert a string into a number we must first pick a numerical type and before we can do that we must think real hard about how big of a number we're going to support in this application. Our function signature(s) could also get complicated because, "wait: what type of string are we going to get from the command line?" Something as simple as adding two numbers becomes complicated really quickly! Comparing the two ways of handling things (strongly, statically typed VS strongly, dynamically typed), Python ends up the clear winner a lot of the time because you got the job done without having to think as much, with less code that's super easy to reason about even though it didn't use static typing. The other problem is that when you write such trivial programs in strongly, statically-typed languages like C, C++, Rust, etc it requires a lot more mental overhead to look at the code to figure out what's going on/how it works (though with Rust, less so because there's not 1001 awful ways to do things haha).
• kakadu 3y ago
  The embracing of Typescript and type hints pretty much solidifies the case against dynamic typing for complicated projects. We have projects in java7 still which span thousands of LoC and juniors can just jump in using their IDE and make some sort of contribution. With python this takes much longer.
  • dartos 3y ago
    Is typescript strong typing though? I’ve been through several typescript projects where ‘as unknown as any’ makes me wish we didn’t even have typescript in the first place. If you can’t trust the type system it’s worse than not having one :/
    • agos 3y ago
      if you abuse the type system enough, most languages will have weaker typing. "the language" is not enough per se, you have to use the tools it gives you to gain some advantage: those projects were clearly actively avoiding strong typing, for whatever reason
      • dartos 3y ago
        In js land some packages don’t have strong types or, worse, wrong handmade types. ‘as unknown as any’ is kind of needed in those cases.
    • jrajav 3y ago
      I, too, find tools hard to use after I intentionally break them. It's unfortunate that Typescript even provides this casting hack, though it's necessary for gradual, optional typing. The very first thing I would do on such a project is spend the time to fix those broken types, because it will pay back in full in productivity after a short time.
    • Tade0 3y ago
      > Is typescript strong typing though? The term "strong typing" doesn't have a clear definition to begin with. Other terms which it often substitutes do, e.g. static typing, sound type system, decidable type system etc.
• rdtsc 3y ago
  That’s why we like Python and Elixir but not Javascript which is weakly typed. :-) Since the author is willing to die for it, they might want to know that they probably meant “dynamically typed”. Some dynamically typed languages are strong typed, too!
  • tasn 3y ago
    Author here. Please read the post, I actually said "Strong static typing" in the post itself (starting from the first paragraph), it just didn't look good in the title. :)
    • rdtsc 3y ago
      That’s an important distinction. Why not just use “Static Typing”. Yeah, the word “strong” sounds strong and cool, but since it’s something you’re betting your life on, it doesn’t hurt to be a bit more precise.
      • xmcqdpt2 3y ago
        C is weakly but statically typed. You can just void * all the things.
    • dartos 3y ago
      Yeah, but your first point is specifically a weakness of weak types, not dynamic types. I don’t really see any arguments against dynamic typing in there. Most strong, dynamically typed languages also have good developer tooling (elixir and dialyzer for example) and have built in ways of describing data structures.
      • tasn 3y ago
        There's a section about catching everything at compile time rather than runtime which is very much about. I think there's a lot of value at knowing when things go bad at compile time, rather than runtime.
    • js2 3y ago
• leroman 3y ago
  As an extension to this, strong typing is a gateway drug to generics. Strong typing really shines when you have generics, saving bugs at one level above basic types..
  • hospitalJail 3y ago
    You got me to look up 'generics'. I like the idea, feels very pythonic ironically. And I suppose if you don't want the generic, I imagine there is probably some subclass of that which is more restrictive. Anyway, as a developer I love when people do this. As a developer this sounds like a nightmare to maintain. My coworkers have told me to limit the numbers of 'what ifs' and just roll with it.
    • leroman 3y ago
      You can think of generics a meta-language that restricts and documents some behavior one level above the concrete types that you might need.. Lots of benefits, code re-use, documentation as code, less bugs.. Granted it's not always easy and straight forward but that what senior developers in the team are for..
      • alickz 3y ago
        Swift makes good use of generics in my experience https://docs.swift.org/swift-book/documentation/the-swift-programming-language/generics/ https://docs.swift.org/swift-book/documentation/the-swift-pr...
        • leroman 3y ago
          I haven't got a chance to use Swift but it looks nice!
    • marcosdumay 3y ago
      > feels very pythonic ironically. Look at duck typing.
• craigmoliver 3y ago
  I don't care how many times I see this argument; strong typing is correct. We need to keep beating this drum because every year there are more and more new developers that know nothing. We need to make good one that aren't ignorant of history and what works...because the more things change the more they stay the same.
• irrational 3y ago
  I wonder if most opposition (or even ambivalence) towards strong typing comes from never having used it. If your entire career has been JavaScript, Python, shell scripts, etc.; then you have zero experience with it.
  • randomdata 3y ago
    Python is strongly typed. If your entire career has been Python, you will have a lot of experience with it. Static typing, maybe not so much.
    • tonyedgecombe 3y ago
      I wonder if most opposition (or even ambivalence) towards strict typing comes from never having used it. If your entire career has been JavaScript, Python, shell scripts, etc.; then you have zero experience with it. @irrational Sorry for the plagiarism.
  • siva7 3y ago
    You probably mean static type checking. I've used strong typing in the first half of my career and have no hard feelings about it. So no, the opposition isn't about no experience with one or the other.
  • ilaksh 3y ago
    I taught myself Turbo Pascal in middle school (34 years ago) and C/C++ in high school. (Both typed). Over the years, I have done programming with C, C++, Java, C#, PHP, Python, OCaml, Lua, Nim, Golang, Rust, Objective-C, Flash, Bash, D, Scala, TypeScript, assembly, PL/SQL, F#, and a few that I am forgetting. Compile time type checking can definitely make things easier. But for dynamic languages that I have been programming in for many years to have types shoehorned into them as an afterthought feels like a kludge. And it's a tradeoff. I got used to developing in Node or Python with vim without auto completion (although I had those things as a kid in IDEs for other languages and they can be great). And without compile time type checks. You can pass JSON around and literally never do a database migration. This stuff will lead to more runtime errors initially, but also means more streamlined code. And you have to do thorough testing regardless. TypeScript might be a choice for a large project with several developers. But I would also argue that an even better choice would be just to use a different language that has the typing system you want built in rather than awkwardly bolted on. What I see in most TypeScript projects is a half-assed attempt that still results in run time type errors, but with the added "benefit" of an awkward bolted on typing system and the need for more tools as well as losing any dynamic benefit. They drop the idea of using JSON and make everything related to the database compile time checked if possible. I'm not saying that those checks can't be useful but if are going that route it would make more sense to just drop the dynamic language. Having all of the dynamism can be a convenience and save you time and effort in other ways. But not if you treat it as a poor man's static language and shoehorn in types in a half assed way using a traditional database. Part of this is that people think software engineering is about your choice of stack or adding processes to development. What matters most is probably the feedback loop between the users and the developers. Starting with the requirements engineering. Second to that would be details of the software design and organization. Leveraging existing code effectively can be key. Using descriptive but relatively concise identifiers, short functions, good code organization. But diving into and evaluating all of that stuff in detail takes effort and a lot of skill and so many make snap judgements based on surface level processes or tool selection.
• hospitalJail 3y ago
  I think I agree. Probably the biggest issue with python. Seemingly random changes between float64 and object happen when doing unit testing(pandas). Can't remember the exact situation because I switched to While permanently, but there was some For loop problem. If the data came in as length 1, the for loop would read the individual chars of the string. If it came in as >1 it would iterate through the list. 15 years ago when I started python, maybe it made sense. Probably ~5-6 'oof that was a bug I wasted time' in 3 years professional use. Today, I find myself forcing types to solve a bug, or at a minimum checking the types as the program progresses.
  • nathan_compton 3y ago
    Pandas is a particularly absurd library.
    • falcor84 3y ago
      Pandas's flexibility is amazing for exploration and prototyping. I'm actually a huge fan of the gradual typing approach, whereby you can start just messing around with stuff in a notebook, and then add the types and the rest of the structure once you are ready to solidify your design.
      • dist-epoch 3y ago
        > Pandas's flexibility What you call flexibility I call non-readability: df.ix[0] df.loc["x"] df.loc["x", :] df.iloc[0] df.x df.x[0] df["x"] df[["x"]] df[df["x"]] df["x", 0] df["x"][0] df[:, 0] # and probably a few more I forgot If you stop working with it for 2 months you forget what each one is doing and when you are supposed to use it.
        • falcor84 3y ago
          I'm not clear what your argument is. Many of your examples are just syntactical sugar which you can very easily ignore, and even prohibit in your linter. Also, note that pandas's datafrimes shine when you focus on column operations, if you're finding yourself accessing individual elements by index often, that's usually a sign that you should switch to a more appropriate data structure.
• heisgone 3y ago
  Strong typing is what allowed me to be a developer. I was never a great developer but I was good enough to be worth my salary. I was not smart enough to maintain a complete mental model of a a weak-typed software but I was able to do fairly complex stuff with the safety net of strong typing. My software developer would have ended much sooner (or never have been) without strong types. I had not other choice but to live or die on that hill.
• mik1998 3y ago
  Static typing is useful if you are building some program for other people to run that you want to be reasonably robust. However, it does not work well with interactive programming. If I had to declare all the types every time I do something in Mathematica, I'd be severely annoyed for no benefit. Common Lisp seems to be the best of both worlds, with dynamic strong typing in general and advanced compiler type inference that can correctly point out mismatched types in most cases in SBCL, leading to much easier time programming interactively.
  • loup-vaillant 3y ago
    You are complaining about explicit typing. Try ML (OCaml, F#…) or Haskell, they have type inference. No need to declare types most of the time, but they’re there, checked at compile time.
• laserbeam 3y ago
  I work a lot in python. I hate it.
• mtreis86 3y ago
  What do you call the Common Lisp sort of typing where you can drop hints wherever the machine is guessing at the type, and it will yell at you if you do something dumb with those things. But you don't have to drop hints at all and it will still compile. It is strong when you turn it on but dynamic otherwise. Strongly typed with inference, maybe?
  • ctenb 3y ago
    I believe the term is gradual typing?
  • Filligree 3y ago
    Gradual typing?
• KaiserPro 3y ago
  Personally I think Strong Static typing is what's required. But with an option to do dynamic typing to avoid faff in certain parts. Strong typing on its own doesn't really solve the problem that the author is describing. c# pretty much has that nailed. You can do dynamic typing if you want, but you're on your own if it fucks up. Moreover its obvious when you're doing dynamic silliness. Python is strongly typed, the problem is that its also duck typed and everything is dynamic. Sure there is type hinting, but that's mostly optional and pretty much broken as its not really supported at run time. (unless I've missed something) What I'd really like is something like perl's "use strict;" in python. however I don't see that coming anytime soon.
• globular-toast 3y ago
  I wish people wouldn't conflate dynamic typing with weak typing. Python, for example, is dynamically typed, but it's strongly typed too. You don't get bugs like `1 + "2" = "12"` in a strongly typed language like Python. You can still get runtime bugs, of course, but that kind of thing would manifest as a TypeError or something. All of those bugs could be caught with tests. I like dynamically typed languages. They are simply the pragmatic choice for the vast majority of code that will ever be written. But being dynamic doesn't mean you can't do types. Python has optional type hinting and checkers like mypy are very good. Common Lisp has features that enable you to declare types and get near-native speed binaries. These days I do type my Python code for many of the reasons given in the article, but I still enjoy using a dynamically typed language underneath.
  • tonyedgecombe 3y ago
    >You don't get bugs like `1 + "2" = "12"` in a strongly typed language like Python. That's more about type coercion which you can avoid in dynamic languages. See === vs == in JavaScript.
• shafo 3y ago
  https://youtu.be/Xb0UhDeHzBM https://youtu.be/Xb0UhDeHzBM
  • j16sdiz 3y ago
    I think clojure spec is still typed. It is just not the type other languages uses.
    • nightwolf 3y ago
      clojure.spec is explicitly not a type system: https://clojure.org/about/spec#_expressivity_proof https://clojure.org/about/spec#_expressivity_proof
• zabzonk 3y ago
  i agree about strongly typed languages, but rather than: let person1 = new_person(); i prefer the c++ way (which also supports type inference): Person person1;
• bluetomcat 3y ago
  Dynamic typing is polymorphism at the language level. In essence, you expect most operators to behave sensibly with different types. An expression such as "a + b" resembles a polymorphic function such as "add(a, b)". You would expect it to work fine most of the time, regardless of the types. And the types in a dynamically-typed language usually aren't so many – you possibly have booleans, numbers, strings, lists, maps, sets and objects.
  • Chabsff 3y ago
    The moniker you are looking for is "duck-typing". Polymorphism is tightly tied to the notion of explicit interfaces.
    • jwilliamson 3y ago
      He's describing row polymorphism. Only some forms of polymorphism require explicit interfaces.
• alexvitkov 3y ago
  You're not "moving faster" if a typo is a runtime error and you're not "more productive" if you can't change a function signature without having to grep your codebase to find all callsites and pray you fixed them all. Types are good, but as with anything else people take it too far. Making it your life goal to encode all business logic in the type system results in an even more incomprehensible mess than not having types at all. If the type name can't fit on one line in the error message, you've gone too far.
  • ranting-moth 3y ago
    I've seen some insane Typescript type definitions. To be fair, they were defined to work with historic vanilla JS code where so many things could have been stuffed in the poor variable. I'm forever grateful for Typescript, but I wouldn't be surprised to see some of that code in a future research paper titled "The era when types went too far".
    • alexvitkov 3y ago
      I'm mostly fine with bad TS definitions since the types are cosmetic and you can always 'as unknown as whatever' your way out of an insane type definition. If someone nests 5 generics in Rust/C++ you'll have a much worse time.
      • sonusario 3y ago
        Do you still find this true when taking type aliases into account?
        • alexvitkov 3y ago
          If you're using type aliases or type inference you don't have to type out the long type, but when you get the error that you need `Foo<Bar<Baz<...<&Whatever>>>` but you have `Foo<Bar<Baz<...<&&Whatever>>`, you'll still have to spend 20 minutes dealing with it. I think TS is a special case, since you can "just say no", but in languages with a statically typed runtime/no runtime I try to minimize the amount of <> in a type, even if they're hidden behind a type alias or inference.
• Chabsff 3y ago
  While I agree with most of the post, it's just the tip of the iceberg of the discussion. Stuff like interfaces, traits, generics, concepts, inference, duck-typing, implicit conversions, etc. all fuzzyfy the notion of "Strong Typing" in various ways, some more than others. The real discussion is not about types vs no-types, it's about the role and place for each of these bending of the rule and their associated tradeoff in different contexts. Op even takes inference for granted towards the end of the post, but make no mistake, that's a form of weak(er) typing. For example, writing template code in C++ without frequent use of type inference (aka. auto) can be an absolute nightmare (I suspect that extends to generics programming at large, but C++ is where I have the most experience here), and the legibility gains from making use of it for iterators is broadly acknowledged as being easily worth the obfuscation for scope-limited variables. But there's also a strong case being made to avoid its use entirely in most other contexts.
  • kagakuninja 3y ago
    C++ templates are a nightmare, because it is also a compile-time macro system. The cryptic, giant error messages from forgetting a > were legendary. Maybe this has improved, I haven't used C++ in a long time. Java by contrast has a greatly simplified generic system; Scala improves on that with robust type inference, making generics pretty trivial to write and use.
    • Chabsff 3y ago
      100% agreed on all points. But even in these languages, writing generics remains greatly facilitated by the use of type inference, which is all I'm saying.
• frou_dh 3y ago
  Trust the science on this. Wait, I've never looked at it. I guess that's why I used the word trust. Surely it confirms my preferences.
• hcks 3y ago
  The static typing hype bubble which started 10 years ago is soon going to burst. As a falloff expect decades of engineers lamenting overly engineered, overly verbose, overly complex TS legacy apps.
  • awestroke 3y ago
    I've never met anybody who prefers JS over TS. If anything, the dynamic typing bubble is bursting right now.
    • yakshaving_jgt 3y ago
      I prefer JS over TS, and I'm predominantly a Haskell developer. But then again, I suppose we haven't met.
    • ilrwbwrkhv 3y ago
      I prefer how much cleaner JS code is compared to TS. Some TS errors are such an eyesore that I'm reminded of the ugliness of Microsoft.
    • meiraleal 3y ago
      > I've never met anybody who prefers JS over TS. It is because the enterprise TS supporters are too loud. There are many here saying they consider people that dislike TS to be idiots and they don't lower themselves to discuss with those who think JS is preferable. They don't wanna argue, we don't wanna argue. Life is great.
    • panzagl 3y ago
      Have you met anybody who prefers JS over Java?
      • iopq 3y ago
        I do, because I don't enjoy having to throw some exception I don't care about just because it's "checked"
  • 3y ago
• doktrin 3y ago
  I don't have much to say about the piece itself other than express broad agreeement on what is a fairly common sensical topic, but just gonna say it's interesting how many commenters here are up pontificating on their soapbox while still clearly confused about the distinction between strong and static typing.
• ceving 3y ago
  Guy L. Steele: "Don't you think it is ironic that type theorists who want to talk about strongly typed languages talk to themselves with an untyped language" https://youtu.be/dCuZkaaou0Q?feature=shared&t=539 https://youtu.be/dCuZkaaou0Q?feature=shared&t=539
  • ozr 3y ago
    There's been innumerable runtime errors, both tiny and world-altering, as a result.
  • mrkeen 3y ago
    No I don't. Now go and rewrite your dynamic language's runtime in a dynamic language.
    • hayley-patton 3y ago
      Gladly! https://github.com/robert-strandh/SICL https://github.com/robert-strandh/SICL (which I wrote a decent chunk of the compiler backend of.)
• loup-vaillant 3y ago
  > There are advantages to not using types, such as a faster development speed In my experience, not even that. Static typing speeds up my day to day programming. You touch this point on later with how IDEs can make your experience nicer with static typing, but I see this even with a REPL: statically detected type errors lead to meaningful error message that are much closer to the actual root cause, and let me fix it quicker than a runtime error would have. It also liberates my brain from having to think so carefully about types. The compiler is disciplined so I don’t have to be. I can move quicker, with the confidence that a huge class of errors will be caught right away. Static type systems are in my experience easier to use, speed up development, and increase reliability. The costs? So far I’ve seen only two: they may be harder to learn, and they’re harder to implement.
  • jodleif 3y ago
    Some would argue that exactly that thinking is what makes the software cleaner and better- rather than mush-mash that passes the compiler. I.e what I’m saying is that it might be good to be thinking about exactly what you’re passing in, out and why.
    • tines 3y ago
      Isn't this the same argument that says that we should all write assembly, because you should have to think harder and really know what you're doing?
      • Aerbil313 3y ago
        The two are not even remotely comparable. Your comment is not thoughtful.
    • AnimalMuppet 3y ago
      Of course it's good to think about what you're passing, and why! Nobody disagrees with that. The issue is, can you think carefully enough, consistently enough, so that you don't need static types? Can your coworkers - all of them? What about future you, and your future coworkers? What about that time that you're in a hurry, or going on vacation the next day, and you're not at the top of your game? If computers have taught us anything, it's that automatic processes are more reliable than manual ones. Personally, I just inherited a code base that is a decade old. I haven't measured, but I'm pretty sure that it's more than 100,000 lines. My current coworkers have two weeks longer on the code base than I do. Static types make this a lot easier. And, if your approach to static typing is "mush-mash that passes the compiler", no, static typing may not save you. But dynamic typing wouldn't, either, with that approach.
• strongly-typed 3y ago
  TIL I am a hill
• okeuro49 3y ago
  I agree, and I think the industry does too. Types are being retrofitted onto languages, like PHP, or added as a superset of the language, like with Typescript.
• andrewclunn 3y ago
  There are so many benefits for a front end application (written in javascript) to just assume it will be the backend that does type validation. A new field column added to a table? Cool, update the api layer, but the javascript just gets "the object" and now you have access to it immediately. No need to duplicate your definitions in both code bases, and it's not like front end security is real anyways. Sounds to me like a lot of "I learned to code in some derivative of C" programmers couldn't possibly consider that different languages could be optimized for different use cases and just want all coding to be "what they're used to." Then they moralize it and use shaming language to push it on everyone else. F typescript. I use different languages for different things, and strong typing makes a ton of sense IN MOST INSTANCES, but certainly not all.
  • BigJono 3y ago
    People are conflating too many ideas. You're right that there's a huge benefit to that, but it's contigent on you as the dev being able to trust the types coming into your system, you need good docs, and attention to detail as you code. All the TS devs just conflate JS with "no types" and picture drooling idiots that make random changes without knowing the type of anything (probably because that's what they do without 50 IDE popups to guide them). You're never going to convince them of the values of dynamic typing because they have a different mental model of it in their head.
• sakex 3y ago
  Not all type systems are born equal, for instance I'm amazed daily at the lack of type safety in Java/Kotlin
• deleted 3y ago
  [deleted]
• Zambyte 3y ago
  I agree with the title, but not with the blog post. Strong typing is great. There is little reason not to use strongly typed systems. The post adds "static" typing in too, modifying the argument. Dynamically typed languages allow you to easily have a very intimate understanding of your program; because you can write the program and modify it while it's running using a REPL. The post seems to conflate dynamically typed with untyped, which is very much not the same thing. The two are actually incompatible ideas. OP: I highly recommend you look into SICP if you want a concrete counter argument to static typing for large systems. A main focus of the course is controlling complexity through abstraction as systems grow to be large, and the course was taught using Scheme, which is a dynamically typed language.
• pron 3y ago
  > Yes, typing can be a pain in languages that don't support inference, e.g Java can be tedious Java has had some type inference for almost 20 years, and local variable type inference (i.e. `var person1 = newPerson();`) for more than five.
  • tasn 3y ago
    I had no idea, thanks for letting me know. I'll update the post now. Java, I'm sorry for swearing at you all these years. :P
    • tstrimple 3y ago
      I've been in the same position. Modern Java is a solid language. Most "enterprise" companies are still using Java 8 or if you're very lucky Java 12, so you really don't have access to all of the modern functionality and because of that I hated on Java for years. Java programming in the wild is a crap shoot at best.
      • Zambyte 3y ago
        > or if you're very lucky Java 12 You mean 11, right? 12 was not an LTS release, and has been out of support for years. The currently supported LTS releases are 8, 11, 17, and the recent 21 release. https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history
        • tstrimple 3y ago
          I'm sure you're right, but I also wouldn't be surprised if it was literally Java 12. I've seen all sorts of insanity in very large organizations.
• AlchemistCamp 3y ago
  I have to wonder if the author has ever used a strong, dynamically typed functional language like Clojure or Elixir or if his dynamically typed language experience is limited to JavaScript, Python and very similar languages. It’s very easy to make up one’s mind about something and then completely stop learning.
  • spprashant 3y ago
    Asking because I am curious to learn, how does a language being functional matter here? As I understand it Python is also strongly typed, while JavaScript is not.
    • AlchemistCamp 3y ago
      In Python, variables are mutable and being a class-based OO language, there’s often a lot of state that isn’t immediately clear when inspecting nearby code. By working with immutable structs and pattern matching, you can get many (but not all) of the same guarantees you would from static types.
  • tomtheelder 3y ago
    I have worked extensively in Elixir and it only made me feel more strongly that static typing is the way to go. The sheer mental overhead caused by the lack of typing in Elixir is the biggest productivity killer for me when working in that language, and refactoring is almost as much of a nightmare as it is in something like JS. For me, strong and dynamic is the worst possible combination. I actually need to be precise with types, but the language gives me no help. I think Elixir has the best combination of runtime and tooling and ecosystem out there, and it’s type system is the only thing that prevents me from using it for nearly everything.
  • ddejohn 3y ago
    Python is strongly typed
• graypegg 3y ago
  I still bemoan the half-assed RBS type system in Ruby 3. I think Ruby actually had a cool chance to explore what inline type hints would look like in a very meta-programming-y environment. While RBS works, it's a hassle to keep updated, and I think adoption is just going to remain low forever sadly. Sorbet [0] is close, just wish the syntax wasn't as verbose as it is. Crystal Language [1] is even closer, I just wish it had better IDE support. [0] https://sorbet.org/ https://sorbet.org/ [1] https://crystal-lang.org/ https://crystal-lang.org/
  • berkes 3y ago
    I'm worried that the reluctance of the Ruby community to adopt some typing, might push it further into obscuration. For me, full time Rubyist for over a decade, it was enough to "jump ship" to Rust and TypeScript. It's one more reason to forego Ruby, I fear.
• ddellacosta 3y ago
  "Strong typing" was a poor choice of terminology here. https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
• stratigos 3y ago
  This article might be right in an academic sense. I suggest the author and those who believe similarly that its a "hill to die on" rethink their approach and spend 5-8 years doing professional consulting (do not confuse consulting with staff augmentation). You will indeed die on the hill as a business cannot expect everyone it hires to believe the same thing, and you cannot expect to force anyone to use strong typing properly. In short, while you may believe this is the right path, most folks dont care, and all that remains is an extremely complex, antipatterned, mysterious ball of mud that no one wants to work with because no one fully bought into the concept for which you were willing to die.
• mpweiher 3y ago
  Well, people have always been fanatical about thing a they are attached to emotionally, rather than rationally. Fact is: the “types lead to fewer bugs” claim is just a feeling, it is “truthy”. https://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html https://blog.metaobject.com/2014/06/the-safyness-of-static-t... And it’s not for lack of trying. You might say the claim has been disproven. That said,I personally like static types, but primarily for the documentation effect that is, maybe not entirely coincidentally, the only positive effect for which there actually is solid empirical evidence.
  • purpleblue 3y ago
    It leads to fewer bugs of a certain type, but there are plenty of bugs being generated in statically typed languages in different ways.
    • mpweiher 3y ago
      The overall bug burden does not change. Why this is we do not know. But we do know that it is true.
  • Chabsff 3y ago
    "Types lead to fewer bugs when making changes to long-lived codebases" is not up for much of a debate in my opinion. Preventing regressions is arguably a lot more important than writing a correct first pass, which is what you are evaluating when looking at non-evolving code. Concretely-speaking, an example of a bug being preventd by a typing system: Removing a field from an object in a large vanilla JavaScript project is inherently a minefield that has caused many bugs in the past, whereas the same alteration in a full Typescript project can be made with confidence.
    • mpweiher 3y ago
      It’s no longer up for debate, true. But not in the way you fervently want to believe. Once again: people have tried to show the truth of this for a long time, and they have consistently failed.
• deleted 3y ago
  [deleted]
• sproketboy 3y ago
  [dead]
• booleandilemma 3y ago
  I don't think the opinion is even controversial at this point. Even the hardcore JS developers I know have come around to using TypeScript. If you can't at least admit to the benefits of static types in 2023 then you probably don't have experience building or maintaining large software systems or working with a team of 15+ people, many of whom you've only met over Slack.
• Tade0 3y ago
  > or even worse not enforced even at runtime (JavaScript, I'm looking at you... 1 + "2" == 12). I'm having trouble taking seriously a post that beats this dead horse. Sure, it's there. It's even documented in the language specification, but now that we have template literals it's rarely used because truly, what is the expectation when using addition on two variables of different types? As for static typing: Grug put it eloquently: https://grugbrain.dev/ https://grugbrain.dev/ > grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug > big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct In my opinion static typing is useful and I wouldn't start a commercial project without it. That being said I think it's productive to practice programming in dynamically typed languages, because: -You avoid the sort of type golf that happens with a sufficiently powerful type system(I regret every use of the `infer` keyword in TypeScript). -The situation forces you to be radically explicit. -You can explore situations that would normally be hard/impossible to type.
• purpleblue 3y ago
  I did C/C++ for the first 15 years of my career. I generally agree that strong typing is better for everyone. But when I started working with python, I understood the beauty in it. At first I couldn't believe you could have a system running reliably that was being hit by millions of people around the world, but then that's when I fully appreciated the power of automated testing. I came from an enterprise shrinkwrap environment with 1.5 hr dev cycles, so you can forgive me for not understanding CD/CI at that point. Yes, you can't detect when changes could cause bugs, but that's where testing comes in. Where I worked, we had to have complete code coverage so that every line of code was tested, and we needed to have a very strong automated testing. Using that method of testing, it made it a lot more predictable. Sure, bugs can leak through, but having worked in C/C++ for so long, I can assure you that static typing only fixes a certain number of bugs, there are plenty more sources of bugs that just types. So for the record, I like static typing and generally agree with using it, but I also see the beauty and simplicity in dynamic typing like Python and it's not complete chaos and there are ways to mitigate it.
• QuadrupleA 3y ago
  As a developer who's written hundreds of thousands of lines of C++, Python, and JS - I don't know! It's not so clear cut. I'm productive in all off them, although Python mostly wins. I wouldn't write a game engine or a video codec with it though. JavaScript is inconsistent and weird, but Netscape's legacy long since stuck us all into it. I can see in a very OOP-heavy style maybe, with huge nested classes, that compile/parse time static typing saves a lot of mistakes - but I've come to see OOP as mostly a disaster, and simple functions and structured data almost always win the simplicity and maintainability battle. And modern language servers / IDEs can catch a lot of typing errors during JS / Python development. I'm persnickety about a lot of programming stuff, but never had a strong opinion about static vs dynamic typing. Both have millions of successful projects under their belt.
  • rdedev 3y ago
    In python I mostly code in functional style. Even then types helps me a lot. I make a lot of typos or get the order of arguments wrong. Typing helps me a lot here especially when I'm doing ML. The last thing I want is my training code to crash after it spent 30nmins processing the data. I find pythons gradual typing a really good middle ground for quick prototyping and the type annotate functions once they are mature enough
    • boxed 3y ago
      > or get the order of arguments wrong There's a simple fix for that, just do keyword argument only everywhere you can. For me the hill I'm willing to die on is that labeled/named/keyword arguments are absolutely necessary and most of the usefulness of types is in fact just a shitty version of labeled arguments (god help you if you have a function where two or more arguments have the same type!)
      • rdedev 3y ago
        The small downside to using kwargs is just the extra letters needed to call the function but I can live with that. As for args with the same type, you can use phantom types I guess but I haven't explored it much in python. I'm pretty interested in the dfdx library in rust which can type enforce matrix or vector operations on it's shape. Stuff like that would really help me
• revskill 3y ago
  THere's a trick i often do on my Typescript projects. To know which other files is using current file, i just add an additional property, then boom, the IDE go red on those files ! Without types, the best you can do is, search, search and search !
  • 1-more 3y ago
    This is a whole vibe when working with an ML language. I usually start at the bottom of the call stack and add the property I need to the signature of that function, then I can just follow "hey, you're calling it wrong—where is argument xyz?" errors up to the top of the stack. Classic bop mode.
• karmakaze 3y ago
  I'm also on the side of static typing being beneficial. I would always however consider the case at hand individually rather than reject it offhand because it lacks it. e.g. a complex distributed working system written with say Elixir or Erlang isn't easily replaced with typescript. Not all systems are better with any static typed language than any without. Once you reach a certain size of developers, add static typing if available, e.g. TypeScript, Sorbet, etc
• at_a_remove 3y ago
  Big yawn. I'm comparatively old and have programmed computers for a long, long time as one of those unfashionable "dark matter developers." What a lot of people see as unassailable truths I see as fads. Just as an example, I've never had to go wild about types. One day I will set aside some time to see if they're worth the overhead, but chances are I will not be a convert. Only this toolchain will be used because it is the only one that makes sense. Everything will be so much easier if it we just did it in the functional style. Large programming projects can't exist without Agile (I've actually heard someone say this). J++! X Will Eat The World. No comments! Verbose comments! If we got the whole team on this one editor, imagine the synergy. Silverlight will take over the interactive web. If types turn into a big deal and remain that way say, fifteen years from now, then it is probably a Good Idea But Not Strictly Necessary. Whatever it is people are so bound up about, it is likely that programming used to happen without it. The only constants we have in programming are variables.
• taeric 3y ago
  Strong static typing, where most of your data is going across the wire as JSON, is a battle that is largely fought in incoherent ways. Yes, you should try and use all tools at your disposal. But you should also find that most "data" is far more squishy than you think it is. People don't fall back to phone numbers being strings because they are lazy, they do it because too many of them made the mistake of thinking they could make them a stronger type at some point. Same for names. Or addresses. Or postal codes. All of these things need to be taken from a user, and the only real way we have to do that is by parsing text. And if you make the mistake of making your system so it doesn't store the preparsed text, you are almost certainly going to regret it at some point. Now, is it best to have a layer that keeps the original user entered text and offers it as a typed set of data to the user in the backend? I certainly think so, but there will be ROI considerations as to how much that matters for your little part. More, if you are doing evaluations of any heavy sort, you probably want a translation layer to a SAT or other numerical model for calculation. And in that world, the numbers are the abstraction. Trying to do it another way will almost certainly lead to pain. And again, you will do well to have translations from problem to formulation, and from solution space to domain. All of these can largely be helped with types, but far too often the "types" that are focused on are not these.
  • tasn 3y ago
    Author here. One thing that we do at Svix that I alluded to in one paragraph but I should probably have elaborated on further: thanks to libraries like Serde and Pydantic, we actually follow deserialization is validation (is that a term?), which means that we validate all of the JSON data before even creating the structures in our code. I guess that's similar to the redis example I gave, but it essentially means that even though we get sent JSON over the wire, we validate it fully and when it gets to our code we know it's a well formatted type. So our code can assume an email type is a valid email, an ID type is a valid ID, etc.
    • taeric 3y ago
      Right, but you should also take pains to keep the original. All too often the deserialization/validation can also alter the data. In many places, this is fine, I think. In many others, it leads to a ton of confusion. Edit: I wrote "but you should", I really should have worded that as "and you should". I am wanting to add to your point, not contradict it.
• nurple 3y ago
  The social pressure to love static typing notwithstanding (think less of me if you will), the reason I got turned off by it eventually are the ivory towers that invariably get built up around them. I've spent a decade each building software in both paradigms and I now prefer not to use type systems. I find dynamic typing similar to how unit testing is a forcing function for writing composable code, it acts as a forcing function to writing simple code; simple to read and simple to comprehend. The argument that it helps inexperienced developers approach the codebase is, IMO, a poor one as it tends to incentivize an iteration loop that lacks understanding and is simply trying to make all the red go away. In fact I find that the type system is often a barrier to truly understanding what's going on as it effectively adds a very domain specific language to every project that has to be learned on top of the language itself. There are methods to solving the problems presented in TFA that are just as robust as using types and which are simple to understand. Can types be used in a simple way? Sure. Are they ever? Not in my experience. I also don't like autocomplete, so take that as you will. I may just be a grizzled greybeard screaming "the code _is_ the documentation", but perhaps that is born from my deep dissatisfaction with the current breed of get-big-paycheck-chatgpt-said-it's-right devs that are currently flooding the industry.
  • deleted 3y ago
    [deleted]
  • busterarm 3y ago
    I was going to write a response pretty much exactly like yours. Also, the domain we're in is engineering. There are no single correct decisions and everything is about trade-offs. And that's good because otherwise our jobs would be the first to be automated out of existence. All of the discussion in this thread about people "thinking less of" other engineers for their opinions/experiences is fucking gross.
    • purplerabbit 3y ago
      Your bio says “most people are stupid” — how’d you arrive at that conclusion without judging people?
• mhandley 3y ago
  I wish the languages I use would not only provide static strong typing, but also proper explicit support for units. Automated dimensional analysis would prevent many of the bugs I've written over the years, and there are so many times I've had to think carefully whether a variable is in seconds, milliseconds or microseconds to the point where I always define my own types of these. Or whether a throughput count is in Mbits/second or Bytes/second.
• dep_b 3y ago
  I like a bit of Python or Elixir from time to time but truth to be said there's never a moment I am happy I didn't have types to worry about.
• vonwoodson 3y ago
  First off, I appreciate the edit. python is strong dynamic typing, for example. Second, it’s a shame that the author doesn’t really speak to Haskell at all. Knowing that a variable is a `u16` is rarely useful alone, relying on the meta of a variable name, for example, to prevent me from adding `user_age` and `number_of_legs`; they both are unsigned 16-bit `int`s, so the compiler is cool with it. A better type system allows types to hold semantic information beyond the bit-width or archaic and usually unhelpful information for the computer and not the developer. Relics of a past where 8k or RAM was all you could use for your program. Ironically, the advanced Haskell type system looks more like dynamic typing specifically because the type inference is so good. You can rely on the compiler (or interpreter) to tell you what the type should be, often times allowing for much more flexible types than you’d think possible. Also, being able to derive classes like Show and Read is amazing. So, +1 for loving types!
  • tubthumper8 3y ago
    I'm sure the author is aware of these - many of the code examples are in Rust which has newtypes and automatic deriving of traits (ex. Display which is the equivalent of Haskell Show)
• jillesvangurp 3y ago
  This debate is a lot older than typescript vs. javascript and dates back to at least the nineties when languages such as python, perl, and others were creeping into production systems. Before that there were already things like tcl/tk and a few other things of course. And of course people were messing around with things like Basic as well. A lot of the arguments against typing are a bit stale. - We have transpilers now. Even most javascript coders use a transpiler or at least a minifier. The overhead of a type checker in such a tool chain is pretty minimal. Especially on a modern laptop. - We have type inference and a few other modern compiler features now. Typing is a lot less verbose in e.g. Kotlin than it is in Java. Java now has a little bit of type inference but it is still pretty verbose in comparison. A lot of the typing is just added by tools as well. - A lot of languages like python, ruby, and others have types now. And spin off languages that have better typing (e.g. Mojo, Crystal) and preserve most of the original languages perceived elegance. Just goes to show that typing can be done without too much compromises.
• kmstout 3y ago
  I want different things at different times. When I'm first exploring a problem space or figuring out an approach or fooling around in a REPL, dynamic typing is great. In those circumstances, the ability to quickly test (and reject!) ideas is critical, and I don't usually find static typing worth the friction. On the flip side, when I'm working on something longer lived or mission critical, it's important to set the maintenance brigade up for success. That means, among other things, useful doc strings; detailed and informative design notes; and type declarations with the right level of specificity. Of course, the coin has a thin edge where the situation is a bit of heads and a bit of tails. Count me a fan of gradual typing.
• ctenb 3y ago
  > There are definitely uses for untyped languages (or language variants), for example they are much nicer when using a REPL, or for throwaway scripts in environments that are already hopelessly untyped (e.g. the shell). I think nushell disproves this example :)
• feoren 3y ago
  We want to identify and fix problems as early as possible; ideally, before we even write them. Problems cost exponentially more to fix the later you catch them, and the damage they can cause only grows with time. Static typing lets you identify problems earlier than dynamic typing, full stop. In fact I'd rather have strong static typing and 0% test coverage than dynamic typing and 100% test coverage -- in the latter case, I'm catching problems much later, and I have the maintenance burden of all those tests, 70% of which are only there to catch what static typing would have already found. The best mix for me is to lean heavily on the type system and only lightly on tests, trying to write code that is simple and "obviously correct". Obviously-correct code has already had its problems ironed out in the first 6 or so bullets below, and there is very little room for further bugs to hide. Of course even "obviously correct code" can actually have bugs or be subtly incorrect -- a better definition is that any surprises in such code would also be surprises to the tests. The tests are nothing more than mirror images of the code, and therefore are not helpful or necessary. Static typing helps me think about the problem clearly, and helps me write "obviously correct" code. Here's my working list, in order of preference of when I'd like to find the problem. Every time you drop down this list, the cost to fix the problem gets multiplied by some small factor ~1.5 to 3. - Initial ideation ["Facebook for dogs? That idea sucks."] - Requirements analysis ["That's not actually how we calculate that metric."] - Conceptual system design ["Wait, these parts don't fit together like that."] - Low-level design ["Crap, a loop won't work here, I need a different flow."] - Brain-to-fingers typing ["Whoops I almost typed 'elesif'"] - Immediately post-typing [Red squiggly line under 'elesif'] - Re-reading ["Wait that should be i-1, not i"] - Compile time ["SYNTAX ERROR: Unknown identifier 'elesif'"] - Unit test time ["Assertion failed: expected 7, got 8"] - Code review time ["You didn't handle the case where N is negative"] - Merge / integration test time ["Oh crap, David's commit broke my commit! How the hell do I merge this?"] - Internal manual testing time ["You need to tighten up the graphics on level 3"] - Production ["The users say the application keeps crashing when they run this report! Fix it!"] - Years later/never ["It turns out that the analysis code we've used for the last 10 years had a major bug in it the whole time and we've been giving wrong numbers to a regulatory agency that has the power to shut down our company."]
  • boxed 3y ago
    > Problems cost exponentially more to fix the later you catch them, and the damage they can cause only grows with time. Citation needed. This is ENORMOUSLY context dependent. Enough to invalidate the entire point. My day job is writing code that runs on a server I control. Mistakes there are super cheap to fix. I get a nice crash in sentry with stack and variables for all frames, I fix it, deploy. Done. If I was shipping code to Mars, well that's the opposite situation. CONTEXT MATTERS
• syndicatedjelly 3y ago
  Does mypy for Python offer a complete solution to introducing static type checking to Python? What is mypy missing that a language with strong static typing has?
• cmrdporcupine 3y ago
  It's interesting we've gotten to this place where the discussion happens like it is on this forum, where acceptance of strong static typing is pretty high. 10 years ago the bias was strongly the other way. And in many shops I've worked in, there was an intense hatred of having to declare types. I like to think it's the development of better/smarter type systems in mainstream programming languages (vs say Java which is what was dominant then), as well as maybe maturing of software engineer practices. But I also fear it's just the trend-pendulum ticking. That and I notice a lot of Python jobs out there, which is an ecosystem I've kept away from for the last 10 years precisely because my professional experiences with large dynamic-typed late-bound Python codebases was terrifying. Beyond NumPy & ML related projects, I fear that this might be indicative that the "types are just getting in my way" crowd is still very influential... Finally I also think it's important to distinguish two concept that get mixed up -- type vs binding: static typing vs dynamic typing and early-binding vs late-binding. It so happens that most languages that emphasize static typing emphasize early-binding, and vice-versa; but it's entirely possible to have very strong types but still introduce sloppy late binding decision behaviour that ends in all sorts of runtime exceptions. Java is/was notorious for this. Reading configuration files to drive application behaviour, or doing things like the Rust Axum framework's "axum::extract::State" stuff, which can blow up at runtime; they're not strictly type issues, but get mixed up in some of the things people are talking about here.
  • syndicatedjelly 3y ago
    What were the arguments back then that supported the opposite bias?
    • cmrdporcupine 3y ago
      "Move-fast & break things." "Test-first-design & aggressive unit testing is the solution." To be charitable, perhaps that the type system was getting in the way, physically of what they wanted to accomplish conceptually. I actually think it has more to do with object-oriented programming as it was propagated through C++ and Java. We were told (and believed) that OO abstractions would solve many software complexity problems. The focus of a lot of programming work was/is on bringing these OO design patterns into play. In large part the OO thing is about a kind of dynamic dispatch. And yet languages like Java imposed a very rigid way of doing OO, and made some of the patterns awkward to express. So if you believe in your heart in the promise of OO, but find that your OO experience is relatively handicapped by your static type system, one then blames the type system. Ruby was maybe the best example of where this line of thought was going/coming-from? I think we are getting past this by getting (somewhat) past OO as a dominant design methodology. But also by adopting languages with richer static type systems.
• Luctct 3y ago
  Is that a promise? Are you people really going to die? How soon? Any chance you die by the end of this week?
  • dang 3y ago
    Hey, could you please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and use HN in the intended spirit? You broke that badly with this post, and we're trying for something else here.
• mcv 3y ago
  I just had a moment today. I'm developing a front-end thing in TypeScript. I'm messing around with dates across different data types (date string, Moment, a Neo4j-compatible date type, and Javascript's own Date type). Real fun, as you may understand. Struggling to convert a specific type straight to a js Date, I decide to just `new Date()` and add all the fields I need. `jsDate.setMonth(convert(otherDate.month))`. Red squiggly line appears underneath. I first realise it's a js Date, so I add a -1: `jsDate.setMonth(convert(otherDate.month)-1)`, and the red squiggly line disappear. I feel a moment of horror. Type coercion. In front of my very eyes! I quickly added proper conversion everywhere. I have no problem with dynamic types, but type coercion is the devil.
• bjourne 3y ago
  The discussion over whether strong typing is better than weak typing is settled [1], but not over whether static typing is better than dynamic typing. Adherents of static typing thinks that the compiler should check "correctness" by verifying type invariants, adherents of dynamic typing think that is a waste of time. I'm firmly in the latter camp. Because the compiler can't check program correctness only type correctness. Type correctnes is necessary for program correctness, but NOT sufficient. Static typing adherents fail to recognize this, thus falsely believing that static typing guarantees them more than what it actually does (blub). Consider the article's birthdayGreeting example. Author is happy that static typing catcges the birthdayGreeting("John", "20") bug because "20" is not a number. But birthdayGreeting(" ", 123) is not caught (" " is not a name) and neither is birthdayGreeting("Anna," -12335). birthdayGreeting("Anna" 4.5), though, is caught, which arguably is wrong since 4.5 is an age. This is actually very important since "type bugs" are trivially easy to catch, while "semantic bugs" can stay undetected for years. An account balance stored as a uint that overflows, a number that must be prime at a certain program location, but isn't, a list that must not be empty, etc. No, not even dependent types can guarantee these invariants. If you don't believe me, read up on some catastrophic bugs. Those that have caused space ships to explode and cars to crash. To the best of my knowledge, not a single one has been caused by bona fide type errors. In the overwhelming majority of cases, the root cause has been a semantic error. [1] - Most people don't understand that typing is measured over at least two axes, strong/weak and static/dynamic, and continue to conflate weak typing with dynamic typing. C is statically typed and weakly typed. Python is strongly typed and dynamically typed. Javascript is weakly typed and dynamically typed.
  • scarmig 3y ago
    In principal, at least, you could encode all those constraints in the birthday example into the type system. In practice, no one does, partially because existing type systems aren't ergonomic enough to express those constraints for developers to want to use them.
  • tasn 3y ago
    > Consider the article's birthdayGreeting example. Author is happy that static typing catcges the birthdayGreeting("John", "20") bug because "20" is not a number. But birthdayGreeting(" ", 123) is not caught (" " is not a name) and neither is birthdayGreeting("Anna," -12335). birthdayGreeting("Anna" 4.5), though, is caught, which arguably is wrong since 4.5 is an age. Author here. I think your examples illustrate my point rather than provide a counter example. I mentioned later in the post that we validate when creating the type (from e.g. user input) so we know that the `Name` type is always valid (and " ") is not a name. So the type ensures that we have a valid name. So this will definitely be caught in our codebase. As for birthdayGreeting("Anna" 4.5) and birthdayGreeting("Anna," -12335), number means a float in JS so it actually would be valid, though admittedly I had full integers in mind when writing this. Another example of where stricter typing than what TS providers (which Rust does!) would have helped better define the invariant. So in short: the problem in the code there was that I was trying to show a simple example, which means I didn't define all the types as strictly as I normally would have, and it surfaced more bugs that would have been caught with types.
• incomingpain 3y ago
  I learnt to code in C. I know strong static typing. I now program exclusively in python. I am never going back. I have tried and do have some of the def hello(world: str) -> str: But to date I have not found a single example where this was useful at all. In fact, I found some odd cases where it's harmful. No typing for me thanks.
• michaelfeathers 3y ago
  I always have trouble with takes like this because they are context-free. There are a wide variety of project types and development scenarios. My nuanced take is that typing is an economic choice. If the cost of failure (MTTR and criticality) are low enough it is fine to use dynamic typing. In fact, keeping the cost of failure low (if you can) gives you much more benefit than typing provides. Erlang, a dynamic language used to create outrageously resilient systems, is a great example of that for the domains where it can be used. I'm not a dynamic typing zealot (I like static typing a lot) but I do think that dynamic typing is unfairly maligned. The cost argument brings the decision down to earth.
• waffletower 3y ago
  I think there is strong religious orthodoxy surrounding static typing in computer science, and this article reflects this religiosity. Strong typing proponents often fail to acknowledge alternative beliefs which assert that strong typing paradigms can be less effective and efficient than dynamic typing for many software development contexts. Rich Hickey, the creator of Clojure, is a fairly prominent counter-voice of this debate and provides some interesting context in this presentation: https://www.youtube.com/watch?v=2V1FtfBDsLU&t=2227s https://www.youtube.com/watch?v=2V1FtfBDsLU&t=2227s
• bluGill 3y ago
  The problem with strong types is how strong is right? If you have a truck with a 1000 liter tank on the back the type for the contents liter, or is it something liters_H2SO4 - if you only need to go to a gauge liter is good enough, but if you are doing anything else you do not want to mix the contents up with liters_H2O. Note that is is very likely you will want to have both in the same program in different areas! Of course we can take the tank out of the truck and replace it with a box of iron - so maybe we need an even more generic type that could be either liters or kg?
• davepeck 3y ago
  Back in the early 2000s, when I was a wee new SDE at Microsoft, there was a shared whiteboard down the hall from my office on which someone had scrawled: "STRONG TYPING IS SO 90s!" That missive stayed on the board for over a year. I still think about it from time to time and remember that the tech world's pendulum is always in motion. Today? I adore TypeScript and I'm pretty excited about the PEP 695 QOL improvements to type annotations in Python 3.12. Where types and tools are concerned, we're in a much better place today than when Nirvana was still the next big thing. But I won't be surprised at all if in another decade I see "STRONG TYPING IS SO 20s" marked on some corporate whiteboard in Redmond. :-)
• t43562 3y ago
  I also don't want to get into a debate about something where there's no chance of changing an opinion. An absolute position is like a religion - it's the desire for everything to be simple, for the removal of doubt and the need to think about each situation on its merits. I remember taking a badly written Python project which was difficult to work on because it took hours to run and could fail at the very end due to a syntax error or other trivial kind of mistake. I needed some way to make it less difficult to change so I could change it to something good. I tried applying type hints because I thought this had minor impact for potentially some gain. In this case it didn't and what helped was to take every tiny bit that was unit-testable and make a test and then to mock the part of the process that took all the time (it was an android build system so I mocked the android build). Every bit of refactoring-for-testability made it easier to do the next bit. So to me I feel that writing tests has more value than any other activity - I'm ready to use types when it makes my IDE work better and when I think it stops me making a mistake I've made before but for my money tests deliver more and I will rather work on them than trying to build an elaborate type system that models the problem well enough to prevent one from doing invalid things under any circumstances. For me, the types/classes I create are there to make my program understandable and manageable as it gets bigger. I find it useful to be able to choose where to put my effort. When I worked on Java long ago I found the type system of the JDK libraries horrendously overdesigned and hard to use - flexibility is sometimes bad if you don't gain from it but are forced to pay the price anyhow.
  • kagakuninja 3y ago
    Python is an example of adding types after the fact. I don't know the specifics of your situation, but gradually typed languages do not offer the same guarantees as languages that have static type checking from the beginning. Replacing types with tests adds giant amounts of boiler-plate code, for little benefit.
    • t43562 3y ago
      My experience is that tests model the expected behaviour and that type systems cannot. Therefore I get lots of value out of tests where types are an impediment. Static typing from the beginning just sets me into a big design up front problem where I try to anticipate the flexibility that I will need and I start building lots of boilerplate abstractions that end up never being used or restricting me later. I find it useful to write imperfect code with only the constraint that it is testable and then revise the structure and any types I need as it becomes evident that they are valuable in the context.
• ranger207 3y ago
  Dynamic typing is fine for exploring. If I'm trying out a new API and don't want to look at the documentation every 30 seconds (or more realistically the documentation is terrible) then writing a simple service in Python is a great way to gain experience. Someone mentioned Julia; I think that most of the stuff you're going to be doing with Julia is exploring so it's fine that it's dynamic. But, for anything actually intended to be used, all the advantages of strong static typing come into play. The problem arises when people start out exploring a problem with a dynamic language, get something working, and then try to expand that dynamic program into something production-ready.
• pphysch 3y ago
  I have come to believe that static typing zealots haven't worked seriously on a large variety of (shipped) software projects. I certainly was one when I was in school. Static typing is a good choice when the system you are implementing is already defined. It's great for implementing a well-defined algorithm or protocol, or a well-studied domain like game engines or financial exchanges or rocket ships. Basically, wherever correctness is necessary and possible. Static typing is a bad choice when the system you are implementing is largely undefined, or actively evolving. That is, "the rest" of the software, where "software correctness" is undefined. Which includes things like a business, a new video game, a website, and scientific research. Because you will waste time building an ontology of types that can't possibly be known at the time, or worse, constrain the natural evolution of the project. CS students often get a warped perspective of software, where everything is well-defined by their professor or some textbook or RFC or some other smart bloke, and they just have to implement it. In reality, the average software project is not this way. The end result is Enterprise Java (formerly C macro hell). You get a bunch of CS grads who think static typing is the only answer working on some fuzzy business logic with Java. The conclusion is an unspeakable monstrosity of bad abstractions (and job security).
• EVa5I7bHFq9mnYK 3y ago
  Hmm, just a few years ago, before typescript, the prevailing wisdom was that types are dead, this is a brave new world out there, just need to create more unit tests.
• DevKoala 3y ago
  The best engineers I’ve met are business objective driven. Strong vs dynamic typing is often a secondary concern. I understand the arguments for each approach, but I’ve never understood those who are dogmatic about their preferences.
• xeckr 3y ago
  I gave TypeScript a shot on more than one occasion, and it always ended in frustration after I inevitably encounter some obscure ts(42069) error that I have to research, then find out that a compiler bug is causing the error, and then get told "it's fine, just add @ts-ignore to the top of the file! See, your code works now!"
• hangonhn 3y ago
  Does anyone here know how Standard ML inferred types? I really loved coding in SML and its strongly type checking system. The amount of bugs I produced was noticeably less. What I'm wondering is why we can't use a similar system as SML to infer the types. Other languages haven't adopted a similar system so there must be some kind of trade off. What was the downside?
  • valcron1000 3y ago
    Look up 'Hindley–Milner type system'. AFAIK, one feature that break this system is subtyping which is very common in many programming languages.
    • nyssos 3y ago
      You can't do full nominal subtyping, so no high church OO, but you can add subtyping for records without too much trouble.
  • mrkeen 3y ago
    > What I'm wondering is why we can't use a similar system as SML to infer the types. We can and do! Use SML! People just don't find out about the good type systems because the market is crowded out by mainstream shit. And people write pieces about how good this shit is: "I was going to add an Int to a String but the compiler stopped me! Less [sic] bugs!". With arguments like that, why would you switch camps? Or sometimes you get fed shit and get told it's inference: "I can replace the first word on the line with 'var'!". So what are the downsides? Inference doesn't play well with inheritance or mutability. If you read Effective Java and see the points about avoiding mutation and inheritance, then these downsides may very well seem like upsides to you. Why did you stop coding in SML?
    • hangonhn 3y ago
      SML has never been used in any of the jobs I've had. I definitely have a very functional programming bend to my preferences. The closest I've come to doing something like SML for work is to use Clojure.
• beders 3y ago
  The author is basically wrong on all the points. I used to think like that for decades, but in recent years changed my mind completely. Types lead to less bugs - nope, maybe marginally, but not significantly (see research on that) Types lead to a better development experience - nope, I have all the definitions and vars in my REPL and so has my IDE. I get completion on all symbols, I can look at call trees, usages, refactor things with confidence, run functions in isolation, replace them, wrap them, all from the REPL and inside my application. We encode everything in the type system - you can't. You need to do runtime validation. And good luck untangling your type definitions when your requirements change. That one is the killer. Static types are premature concretions on the domain data model as you understand them now. They will change and if you are unlucky you will have to support multiple different variations of domain models in the same runtime. Good luck with that. Especially if you use inheritance. Granted, static types give compilers great leverage to optimize code, but, wouldn't you believe: there are dynamically typed languages that have static types as a la card add-on. But for many, many use-cases, especially enterprise development, a dynamically typed, immutability-first, functional language pays off dividends in the long run. The categorical error that is made by many strong typing fans is that they assume you would write the same code - just without types. Well, you don't.
  • jjnoakes 3y ago
    > I have all the definitions and vars in my REPL and so has my IDE. I get completion on all symbols, I can look at call trees, usages, refactor things with confidence, run functions in isolation, replace them, wrap them, all from the REPL and inside my application This is great, but it only works if you are executing the code that you want to inspect/complete/refactor. In my experience, that just doesn't scale well. > You need to do runtime validation. Type systems don't eliminate this, sure, but when used correctly, they _drastically_ reduce it, which is extremely useful. > And good luck untangling your type definitions when your requirements change. That's the best part - the compiler tells me exactly what I have to fix to get things working again. If I do the same thing in a dynamic language, I have to track things down myself, wait for unit tests to fail (hopefully I have 100% coverage...), and pray that there isn't an escape.
  • sanderjd 3y ago
• Veuxdo 3y ago
  Static type checking won the battle, but lost the war to microservices, micro front-ends, micro-repos, and so on.
• victorNicollet 3y ago
  I think there are at least two ways to write safe and robust code, one being to rely on static types to provide automatic guarantees, and another being to structure the program in a way where tests reveal errors immediately. They are mutually incompatible, and so different from one another that few people can be experts at both, but I don't think one is objectively inferior to the other. Both styles require code to be disciplined, and undisciplined code cannot be caught by compilers, linters or automatic tools, it has to be through code review (or experience and sheer willpower). It's easy to think of examples where a lack of static types would allow brittle code to be written, but it's important to question whether that brittle code may be considered unacceptable by someone experienced in working without static types, in the same way that code using a Dictionary<string, object> instead of an actual type would be considered unacceptable by a type-safety practitioner despite being (technically) type-safe.
  • evrimoztamur 3y ago
    Why are they incompatible?
    • victorNicollet 3y ago
      For example, with static typing one would define many different complex types over the program, in order to have the compiler enforce the many different constraints (here the value can be null, but not there ; these two values must be provided together ; and so on). Things like structural typing or algebraic data types even allows the creation of unnamed types on the fly. When sum types are used, conditional operators will be used to deconstruct these in a type-safe way, resulting in many branches. With dynamic typing, one would have only a small number of very different types, because having many types increases the risk of using the wrong one, and having similar types makes it harder to notice that the wrong one is being used. The types must be very simple, because deconstructing complex types requires having branches, and branches should be kept to a minimum because they are hard to cover properly with unit tests.
      • evrimoztamur 3y ago
• KMag 3y ago
  Some early Lisps had both compiled and interpreted mode, where the interpreter used dynamic scoping and the compiler used lexical scoping. (Which, I presume, caused much developer confusion when code worked fine in the interpreter and got very strange behavior once compiled.) Something analogous (but more sane) could be done with type systems. I'm very much a fan of strong static typing, but I understand the appeal of dynamic typing, particularly for small scripts and/or prototypes. Static type checkers (for most languages) are pretty simple theorem provers. For statically typed languages, the compiler (or, I suppose in rare cases, interpreter) rejects any program that it can't prove is free of type errors. An alternative would be to only reject programs that provably contain type errors. The difference in allowed programs covers the cases where the type checker can't prove either way. So, I'd love a language with a type checker that when ahead-of-time compiling code would refuse to emit libraries/binaries when it couldn't statically prove types were used correctly. In interpreted mode, it would only refuse to load code that it could statically prove contained type errors. Maybe when used within an interactive session, it would still allow (but warn) when code provably has type errors. As an added bonus, static type guarantees open up more opportunities for the optimizer. A single language offering some range of static guarantees would reduce the number of cases where dynamically typed code gets re-written into a higher performance statically typed language when re-factored into libraries. If you prefer, go ahead and dynamically type your scripts, etc. However, if/when it comes time to package up parts of your program for wider re-use as libraries, please tighten up the static guarantees of type safety.
  • dannymi 3y ago
    >So, I'd love a language with a type checker that when ahead-of-time compiling code would refuse to emit libraries/binaries when it couldn't statically prove types were used correctly. In interpreted mode, it would only refuse to load code that it could statically prove contained type errors. Maybe when used within an interactive session, it would still allow (but warn) when code provably has type errors. Haskell can do that. https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/defer-type-errors.html https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_gui...
• cma256 3y ago
  Static typing won there's no point arguing over it anymore. The issue is the type systems. Someone writing Haskell will have a very different opinion of types versus someone writing Rust versus someone writing Typescript versus someone writing Bash. That's why you see a negative reaction to static typing. Its the developer experience. Its the error messages. Its the amount of time and mental effort it takes to type something correctly. If you told me I had to choose between dynamic Python or strict Typescript I would choose Python. I love static typing. I hate Typescript. So don't die on a hill! Just make better type systems!
• tabtab 3y ago
  Although a lot depends on personal preference, in general "root" infrastructure is best on strong typing, while "glue-ish" scripts best as dynamic.
• derbOac 3y ago
  Strong static typing is better when used well, but worse when it's used poorly. That last part is the catch, and I've seen plenty of people think they're using it well when they're actually using it very, very, very poorly. Dynamic typing isn't just a convenience sometimes, sometimes it helps compensate for poorly planned type structures. Like a lot of things, there are tradeoffs in terms of what types of errors you want to avoid more.
  • cocoacat 3y ago
    But in my experience I have also experienced the opposite. I have seen people casually reuse variables by reassigning them to a new type or developing a single function that returns different types. With dynamically typed languages it sometimes feels like you can take messy shortcuts because they let you.
• Draiken 3y ago
  The only thing that really frustrates me in this discussion is that it's all about how people "feel" and without empiric evidence. The research out there found no meaningful difference between both styles (unless there's newer research I haven't seen?) and people keep taunting around how their preferred side is undoubtedly the right one. That's just like, your opinion man. Personally I like typed languages but the type systems in languages like TypeScript are simply insufficient. You still end up with runtime bugs because you can't actually use those types at runtime. You can't encode a lot of the runtime logic into the type system so you're still manually checking impossibilities everywhere. I find myself even having to create local variables just to make typescript detect an obvious condition. If a type system could basically remove the need for me to think about runtime bugs, then that's an absolute killer feature that I doubt anyone would argue against. But most languages don't provide that, so you're stuck in this halfway point where you have all this overhead, some benefits, but you still can't 100% trust your types. As for why there are no meaningful differences in bugs, speed, etc my guess is that it all evens out. Without the type system safety net you are much more likely to test your code and as a result less bugs go in. On the other side people rely too much on the type system that's not good enough and then still end up with the same amount of runtime bugs. On one side you write code faster, but you have to test more, so it also evens out with writing more boilerplate, but with less tests. I really wanted some hard research on this, but I know it's a hard one.
  • dgb23 3y ago
    Exactly my thoughts! The article and many commenters here all talk about programmer ergonomics, productivity and "correctness". The current research shows that these things are neither improved nor weakened by static typing. There are (even recent) papers on comparing typed vs dynamic language with no meaningful results. So basically it's entirely subjective. However there _is_ an actual effect of static typing that can be trivially proven: It enables a programmer to write more efficient code. That should be at the forefront of every discussion around typing discipline, because everything else is just _hot air_ at this point. TypeScript (used in the article) is an example that is _not_ actually strongly typed (it's statically typed but weak) and it doesn't even provide performance and memory layout guarantees, because the types are just comments. So you pay all of the cost of static typing without _any_ of the tangible benefits except documentation. To me it is surprising that we as a technical community completely ignore actual evidence and take our cultural and personal preferences as fact.
• thot_experiment 3y ago
  It seems like such a weird thing to have a super strong opinion on. Sure if you only ever do one specific thing maybe there's an argument to be made that one is better than the other. I think there are just some problems that are best solved with statically typed langs, and some are better solved with dynamically typed langs. IIRC research shows it's a wash.
• throwawaaarrgh 3y ago
  Typing is literally an architectural/design decision. There is no such thing as one single type system that works for all use cases. It's like saying there's only one good kind of metal fastener for construction. Sometimes you should use nails, sometimes screws, sometimes bolts. It's not like one of those is always superior to the others. You literally should not use a bolt all the time, nor a screw, nor a nail. There are specific engineering requirements and purposes to them all and you can't just mix and match based on your personal preferences. Well, let me correct myself: you could just use one fastener you prefer, but your building would fall apart six different ways and be a huge pain in the ass to construct. Thankfully we have building codes so people can't just decide to do that.
  • berkes 3y ago
    I doubt anyone is arguing that our bash scripts should be typed, or our quick "remove_currency_from_bank_csv.py" must be statically typed. The article puts a few cases forward. What the article is discussing, however, is the majority of software. Built in varying teams. Over long periods of time. Large software, complex software.
• Animats 3y ago
  There's been considerable convergence on this. Most languages now have some degree of type inference for statements now. Even C++ has "auto". That substantially reduced the amount of type boilerplate in code. Remember having to write out long iterator types in C++ "for" statements? We're past that. As for function declarations and structure fields, that's where you need type information to read the code. Once a program gets beyond a few hundred lines or beyond one developer, some amount of annotation is essential. The main objections come from Python and Javascript users, of course. Python retrofitted a very strange advisory typing system, and Javascript retrofitted TypeScript. Both are bolt-on type systems and are used in mixed typed/untyped environments. That is painful. LISP also got a type system retrofit decades ago, with "flavors" and the Common LISP Object System, and that was ugly, too. The lesson here is that retrofitting a type system creates a mess.
  • mjr00 3y ago
    I actually think Python's type system is pretty good, given the circumstances. It's got some nice features like Optional forcing checks for None values before use, and structural subtyping with typing.Protocol. Could it be better if Python were designed with types from the ground up? Yeah, of course. But given the requirements of integrating with all existing Python code and not breaking any existing code I think it does a decent job. The bigger issue with Python and static typing is the ecosystem and conventions that a lot of developers use, made worse by a lot of these developers really being data scientists who are writing Python. *args/**kwargs are heavily abused by people too lazy to write proper method signatures. It's extremely common in Python to have methods pass around DataFrames or dictionaries as a grab-bag of stuff. Bonus points when methods add and remove columns/fields so you don't know what's in the data bag until you run the code (or read every line). You can do this in almost any language, of course. Nothing stops you from writing a C# program with every type being `dynamic` or have all your Go methods accept `interface{}`. But Python, for a long time, actively encouraged this approach, and sadly there's still many beginner tutorials today that present things like "just write a method that takes *kwargs and you don't have to change the function signature!" as an advanced language feature for smart people instead of an awful footgun.*
  • spankalee 3y ago
• choeger 3y ago
  First of all: I always have and always will be a proponent of statically strongly typed languages (although I would argue that "statically strongly" is redundant here, there are only typed and untyped languages, IMO). But there's one cost that the author seems to miss and that I didn't fully appreciate for some time. That's the cost of composition. If you look at python you can pretty much compose all possible packages on pypi in your project. All their means of abstraction are usually fully compatible (except for concurrency). Composition often only requires a little bit of glue code. In a statically typed language's ecosystem you will probably a handful of fundamentally different means of abstraction like functors vs. classes that simply don't compose well together. Hence the fragmentation increases massively.
• lucasyvas 3y ago
  The dynamic typing crowd is frankly just flat out wrong at this point and someone has to say it - so, thank you Tom. This is especially apparent with advancements of type inference in compiled languages. Beyond initial prototyping (which I doubt will actually ever be thrown away), what logical defence is there for catching obvious bugs in production when they could have been caught at compile time instead? Dynamic typing straight up hides unavoidable realities of programming - you have to know what thing you have to cover all the cases. I don't just mean cases that "make the compiler happy". These cases are most often not mutually exclusive from the business domain - cases related to core business logic are missed, which produce more bugs which makes your software objectively worse for both the end user and whatever business the software is sold by. The complaints I hear are that it's too cumbersome or annoying to satisfy these cases - my retort is to stop complaining because most of us are paid to write working software, not software we can pass off as being complete when it's not. And don't suggest that tests cover this - they absolutely don't, and testing such things is a total waste of time. The train has left the station, best get aboard.
  • PaulHoule 3y ago
    A counter is that nothing has replaced Python for data science. I mean, Julia has talked a good game but gotten very little traction.
    • lucasyvas 3y ago
      I would argue this is a false equivalency. The explanation is that Python is too entrenched to replace, not that it is somehow superior for this use case because it is dynamically typed.
      • PaulHoule 3y ago
        Well... I'd phrase it like "no statically typed language has proven it is superior or even applicable for this use case yet". You can't say Julia hasn't given it a serious try and hasn't gotten first-rate marketing treatment by being name checked in "Ju-Py-Ter" notebooks and other placements. Instead, Julia has serious deficiencies https://news.ycombinator.com/item?id=32806179 https://news.ycombinator.com/item?id=32806179 It's certainly not proven a static language can't cover this use case but in other areas static languages really have proven their merit.
• germandiago 3y ago
  Clojure author Rich Hickey disagrees on this. He argues that not only typing is what you need since many of the errors are not typing errors and not even most are (not sure he said that last thing exactly though, talking from the top of my head). The point being that an alternative that can check that and more is better. Also, he argued that types are key/values no matter the formal type if it is the same thing in two systems. So he created spec. Spec can check more invariants than just typing. Truth to be told, Clojure is functional and one of the goals is to generate test cases from those specs. So it is a bit of a different story probably. At the end we want correct software.
• amelius 3y ago
  How long until Copilot can type-annotate any piece of dynamic code, making the issue mostly irrelevant? Everybody sees the code how they like to view it.
• todd8 3y ago
  I understand that modern type systems can do anything (that can be computed) since they are Turing complete. So are Java generics and C++ templates and Lisp’s macro systems, but I don’t want these things. I’ve written a number of Turing machine programs; yeah it’s impressive that an imaginary machine that is so simple can run any program that runs on any other computer, but it’s no fun writing code for a Turing machine. For the Theory of Computing studying Turing machines is important. If I don’t want Turing complete type systems, what do I want? Well, first off, the bugs I find in my programs that are more troubling don’t seem to be stopped by strong type systems. What I want is to be able to declare assertions in my code. For example, I’d like to tell the compiler that the variable year must always satisfy (2000 < year < 3000) and that in a certain block of code that x and y are always within 0.5 of each other. I want the compiler to ensure that these invariants are satisfied by a combination of compile time and run time checks generated by the compiler. The problem is that we can’t expect programmers to use Turing machine like type declarations, because the programmer must now program the type system without bugs to ensure that the types in the program carry enough information that higher level assertions can be made about the original program’s correctness. TLDR, I want to work with higher level assertions about the code than that provided by complex types.
  • kazinator 3y ago
    Your comment seems as if it might be confusing Turing completeness with the expressiveness of the actual machines described in Turing's work. > A Turing machine is not "so simple that it can run any any program ...". Simplicity has nothing to do with it. Turing showed that some very simple machines can calculate recursive functions. Not every machine that is Turing Complete looks like a tape machine from Turing's papers. > it's no fun writing code for a Turing machine Almost every general-purpose programming language is a Universal Turing Machine; so that's like saying it's not fun to write code, period.
• coldtea 3y ago
  >The question around strong static typing is simple: would you rather work a bit more and get invariants checked at compile-time (or type-checking time for non-compiled languages), or work a bit less and have them be enforced at runtime The latter. Other question?
• yc-kraln 3y ago
  The example from the article without any explicit arguments reminds me very much of objective c's message passing concept, which I actually quite liked and used very much. So, I guess the answer is: there is no objectively correct way to do things, except if the thing you are trying to do is get "engagement" then take an extremely strong stance on something which has no objectively correct answer.
• m0llusk 3y ago
  Seems like a matter of degree. If taken to an extreme then nearly all parameters can be made into unique types. Not just measures, but pixel height measures. Not just pixel height measures, but help panel pixel height measures. Not just help panel pixel height measures, but settings help panel pixel height measures and so on. This may seem like a great way to keep everything well sorted, but ends up being an unhelpful mess that is difficult to maintain. So the question is how exactly in a situation is best to define types, not whether or not to have them or to make them static or whatever else. And why exactly do you need types in the first place? Lots of projects are messy and involve teams and have work handed off to developers on a regular basis. In that kind of context which is quite common types can be a life saver. There are also short term one person projects that have a high expectation of all work being thrown away soon after. Isn't defining a bunch of types likely to be a waste of time if there is only a brief development effort which is clear and not expected to ever be touched by teams? Most one size all solutions like static typing have some contexts in which they are either a complete waste of time or need their breadth to be carefully limited.
• terminatornet 3y ago
  It's a shame so many people have had bad experiences with static typing due to Typescript. In languages like Rust and Elm, static typing truly feels like a super power when I'm coding, particularly when modeling my applications possible states. This talk does a great job at articulating how to use types to disallow invalid/illegal states. https://www.youtube.com/watch?v=IcgmSRJHu_8 https://www.youtube.com/watch?v=IcgmSRJHu_8
• simonblack 3y ago
  Moi aussi. If you have strong static typing you don't need all those dumb functions like string_to_number("1234"), etc. to change the type you're given to the type you find you need right now. When you know that a variable is of a set type, you DO NOT need to keep looking to see what type it happens to be at the current moment, and then juggling it to suit.
• webworker 3y ago
  Frankly I'm surprised that there even seems to be a vogue/fashion on this. I learned programming with types (C++). Was then beaten over the head that types didn't really matter/yolo. And now we're back here again. It could have always been this way. And for some, I'd imagine the type party never took a break.
• kazinator 3y ago
  Because nobody ever put together a hash key using string interpolation, and made a typo, in a strong, static language.
• berniedurfee 3y ago
  As a greybeard, I’m so glad to hear and see type safety becoming okay once again. XP seemed to be the catalyst for the “code fast and bail” mentality that’s persisted for too long. I feel somewhat validated as a long time advocate of type definitions. It always irked me to hear someone say a language with types is too “verbose” and slows them down. Yeah, please do slow down! It really is okay to take a little more time to write better code.
• zubairq 3y ago
  As someone who has programmed in C++, VB, Clojure, Java, Ruby, Erlang, and now Javascript (because of NodeJS and that it is in the browser), I will admit that I usually ending up implementing my own Type system and checks more and more as programs gets larger. Maybe there is some variation of Greenspun's tenth rule like "Any sufficiently complicated dynamically typed program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of INSERT YOUR FAVORITE TYPED LANGUAGE HERE"?
• CraigJPerry 3y ago
  When I sit down to do a side project these days I’ve gotten into the habit of turning on a screen recorder then just forgetting about it and cracking on with the project. Watching these recordings back at 10x speed has been fascinating to see how I work. Most of my findings around wasted time and effort or correctness stem from design (faulty or skipping design analysis altogether and just coding). Every other aspect of coding just pales into insignificance compared to this one thing.
• ReflectedImage 3y ago
  Static typing sounds great to Junior Software Developers, who don't properly understand what the problems the software they write needs to solve. Static typing allows me to check the types are correct! In practice, typing related errors are a very rare bug so it isn't very useful. Static typing allows me to check things at compile type. In practice, this means waiting around for things to compile and lots of dead time. The larger the project get the longer the compiles times. If performance doesn't matter, dynamic typing is pretty much always the way to go. You get the code out faster, so you have time to write more tests and you can throw away the code faster. Cause in the real world, code is a churning thing that evoles with the business requirements. Not some static build once thing that static typing and Junior Software Developers assume.
• Snacklive 3y ago
  Ok so, based on the comments it's basically people who loves Strong Static Types and people who only experience with types is Typescript and they hate it.
• zomglings 3y ago
  My context is the Only True Context. My way is the Only True Way. Zealotry and fucking bullshit.
• danabrams 3y ago
  The author leaves out what to me is the most compelling argument against static types: it is somewhat at odds with interactive development with a running system, as seen in smalltalk and lisp. Now, not a lot of developers are really doing this. But it's still a good reason for those who are.
  • kazinator 3y ago
    The article's author is using Blub static types, in which you're declaring that the variable that captures something from the cache is a Pet handle. Under a properly modern static typing system, you let that be inferred: let var = cache.get("key"); var is of whatever type that the cache object returns. Even clunky old C++ can do this with auto. That author will most likely die in some statically statically typed corner he painted himself into.
• Aerbil313 3y ago
  People are saying strong static typing is not a worthy investment mentioning their experiences with Typescript. That's Typescript. Types are comments. They don't even exist in runtime. Try a real strong static typed language like Rust.
• LLyaudet 3y ago
  Just spotted a typo "mulitple" in case the author lurks in the comments here :). ("You'll pay it mulitple times over when you need to debug why your code doesn't work (either locally, in the test suite, or in production).")