18 ms·

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 abo

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.
    - pfdietz 3y ago
      Dynamic typing doesn't exclude the compiler from being able to detect some things that would cause errors at run time. It just means that these turn into compile time warnings, not compile errors. In Common Lisp, it's common practice to not accept code unless all such warnings are gone.
      - chongli 3y ago
        That is static typing. You can add static types to a dynamic language, but then you introduce a compilation step. This is not an argument in favour of dynamic typing. If your language requires a compilation step anyway, then what you have is a static language with only one type: the ‘any’ type. Every argument I’ve seen in favour of dynamic typing is some variation of “I like it this way.” They’re not technical arguments because dynamic typing is a strict subset of a statically typed language, equivalent to passing a flag to turn the type checker off. Sure, not every compiler offers such a flag, but that is an argument against one particular static language (or group of languages), not an argument against static types itself.
    - marcosdumay 3y ago
      > There is only the runtime to print a stack trace Types are not exclusively for verification, and even if you decide it is, you can do a lot more with a type error than exiting the program. That stance most people keep repeating is actually ridiculous. The most common usage of static type systems is to verify badly-written ad-hock dynamic ones that handle user errors.
    - kerkeslager 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. This is just incorrect. Plenty, if not most, dynamically-typed languages are compiled. Indeed even the idea that there's a clean dichotomy between compiled and interpreted is an outdated idea: I'm not aware of any production-quality language implementations which run tree-walk interpreters entirely without compilation. Modern "interpreters" typically compile to bytecode but in some cases even can compile to native code, they simply do so in a just-in-time manner. These compilation steps are quite capable of applying type systems. For example, if you run a Python script, you can see the results of compilation cached in .pyc files (these will be either in the same directory as the source files, or in your __pycache__ folder, depending on your configuration). > 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. Is it? I would argue that the point of types is to report errors at the place where they occur, rather than doing the wrong thing silently and reporting an error elsewhere, or simply behaving incorrectly. If a tree falls in a forest and nobody hears it fall, does it really fall at all? If a bug happens on a code path, and nobody exercises that code path, is there really a bug?
- 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.

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.
  - pfdietz 3y ago
    Dynamic typing doesn't exclude the compiler from being able to detect some things that would cause errors at run time. It just means that these turn into compile time warnings, not compile errors. In Common Lisp, it's common practice to not accept code unless all such warnings are gone.
    - chongli 3y ago
      That is static typing. You can add static types to a dynamic language, but then you introduce a compilation step. This is not an argument in favour of dynamic typing. If your language requires a compilation step anyway, then what you have is a static language with only one type: the ‘any’ type. Every argument I’ve seen in favour of dynamic typing is some variation of “I like it this way.” They’re not technical arguments because dynamic typing is a strict subset of a statically typed language, equivalent to passing a flag to turn the type checker off. Sure, not every compiler offers such a flag, but that is an argument against one particular static language (or group of languages), not an argument against static types itself.
  - marcosdumay 3y ago
    > There is only the runtime to print a stack trace Types are not exclusively for verification, and even if you decide it is, you can do a lot more with a type error than exiting the program. That stance most people keep repeating is actually ridiculous. The most common usage of static type systems is to verify badly-written ad-hock dynamic ones that handle user errors.
  - kerkeslager 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. This is just incorrect. Plenty, if not most, dynamically-typed languages are compiled. Indeed even the idea that there's a clean dichotomy between compiled and interpreted is an outdated idea: I'm not aware of any production-quality language implementations which run tree-walk interpreters entirely without compilation. Modern "interpreters" typically compile to bytecode but in some cases even can compile to native code, they simply do so in a just-in-time manner. These compilation steps are quite capable of applying type systems. For example, if you run a Python script, you can see the results of compilation cached in .pyc files (these will be either in the same directory as the source files, or in your __pycache__ folder, depending on your configuration). > 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. Is it? I would argue that the point of types is to report errors at the place where they occur, rather than doing the wrong thing silently and reporting an error elsewhere, or simply behaving incorrectly. If a tree falls in a forest and nobody hears it fall, does it really fall at all? If a bug happens on a code path, and nobody exercises that code path, is there really a bug?
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.