11 ms·

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 controver

• 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.
  • junon 3y ago
    Python and PHP both have type hints that are natively ignored by the language if present, but can be checked if you have enough of them, if that's what you mean.
    • randomdata 3y ago
      No, I mean it lacks strong typing. C and C++ also lack strong typing even with static typing being a core feature and checked at compile time.
      • junon 3y ago
        There's no agreed upon definition of "strong" vs "weak" so you'll have to elaborate a bit.
        • randomdata 3y ago
          The only other use I'm familiar with where strong types are used to describe the equivalent of static types, but we've made clear distinction between the two here. What other definition is there? Usually: A strong type system does not allow types to change after being established. A weak type system allows types to change. This is also described in the original article.
          • 1-more 3y ago
            How is that different from static typing?
          • zabzonk 3y ago
            >A strong type system does not allow types to change so... like in c++?
            • neverartful 3y ago
              No. C++ does allow types to change. That's exactly what casts are for.
• user3939382 3y ago
  There's a specific scenario where I have more sympathy for weak typing, which is: I'm writing a small, focused utility by myself whose scope can never expand and whose code will never be collaborated on. I do have these, little shell scripts. I write them, they work, I move on and use it for 10 years. No types in there, fine whatever. As soon as there's any complexity at all or another person involved that exception stops.
  • racked 3y ago
    Indeed this. There are benefits. Less code, faster to write.
  • AnimalMuppet 3y ago
    You are the other person. Come back in six months needing to make a change, and it's almost like you're new to the code. Now, in general, I agree with you. If it's a one-off (or if it's really never going to need maintenance), and if it's small enough that you don't need types while writing it, then sure, do whatever is easiest at the time. But "never going to need maintenance" often turns out to be a lie, and when that time comes, you may be happy for some types as signposts to give a hint of what you were thinking all those months or years ago.
    • BobbyJo 3y ago
      This is the trojan horse dynamic types use to get into your castle :P
  • SAI_Peregrinus 3y ago
    I want a shell scripting language that allows a max line length of (for example) 128 characters and a max script length of (for example) 128 lines, with no `source` equivalent. If the script expands to not be a "small, focused" single-file script it should just fail to run at all. Just enough for small utilities, but unusable for giant monstrosities.
    • KMag 3y ago
• packetlost 3y ago
  I'm also a pretty die-hard type-system user, but I've been programming a lot of Lisp and FORTH lately. FORTH is just bad at safety period. Lisp, on the other hand, I can see why there really isn't a need for types. The macro system means you can create arbitrary "compile-time" safety checks which is, IMO, more powerful than just a type system. That being said, I would still love a strongly, statically typed Lisp, or at least one with a strong macro type system (before y'all mention it, I'm not a fan of typed Racket).
  • Zambyte 3y ago
    > Lisp, on the other hand, I can see why there really isn't a need for types. What Lisp are you using that doesn't have types?
    • packetlost 3y ago
      Well, every programming language must necessarily have types to some degree, but they aren't necessarily static or strong type systems. Most Lisps do not have a static type system and even fewer have a "strong" type system.
      • Zambyte 3y ago
        > Well, every programming language must necessarily have types to some degree The vast majority yes, that's why I was a bit confused :D There some languages that have no types. The only thing I can think of though is a POSIX shell minus arrays. (Edit: Assembly and Forth are two better examples) > Most Lisps do not have a static type system True > and even fewer have a "strong" type system. Common Lisp, Emacs Lisp, Scheme, Hylang, Clojure, and Racket all feature strong typing. I'm curious where you have found this trove of weakly typed Lisp dialects
        • packetlost 3y ago
          Lisps are not statically typed typically and "strongly" typed is poorly defined. I would not consider most Lisp's type systems to be strong or particularly expressive, but they don't need to be because it would hurt the main benefit to the language: meta-programming. I don't think a "strong" vs "weak" type system argument is particularly valuable here, yes most prevent you from inadvertently changing how a particular series of bytes is interpreted, but their aggregates do not have any type identity besides their own typically. This means you cannot typically express and enforce an aggregate's covariance or contravariance properties. There may be ways to do so, but most do not provide utilities for it.
• PrimeMcFly 3y ago
  In my experience whenever you put effort into making a post like this, outlining the common arguments you hear and your attempt at refuting them, people don't really pay attention and will just repeat the arguments you already addressed, ignoring your refutations.
• stratigos 3y ago
  Youre missing the perspective of a business owner and operator that has to hire many people with diverse patterns of thoughts and beliefs who will most likely work for their organization for less than 24 months.
  • AlanYx 3y ago
    If you have a considerable amount of staff turnover, strong typing is a godsend for a large codebase. Having an order of magnitude more unit tests is another option, but that undermines the alleged "less code" benefit of weak typing.
• 1-more 3y ago
  What does "strong" mean as regards typing. I've heard a few different definitions so I'm curious what yours is in the context of this article.
  • bigstrat2003 3y ago
    As far as I'm aware, the generally accepted definition of strong typing is: some object in memory has a type, and the compiler (or interpreter) will not let you treat it as another type without some kind of explicit instruction to do so. This is in contrast to weak typing, where the compiler/interpreter will happily try to treat a Bar object as a Foo object if you do some Foo operation on it.
    • gpderetta 3y ago
      That's the definition of type-safety (or memory safety that is pretty much equivalent). "strong typing" has no generally accepted definition.
      • bigstrat2003 3y ago
        Memory safety is definitely not equivalent. Memory safety is more like not going past the end of an array, not doing use after free, etc. I agree that what I said is pretty much also the definition of type safety. But in my experience it is also the generally accepted definition of strong typing.
    • 1-more 3y ago
      That seems to be a subset of static typing. Is there an example of this that does not involve non-static typing?
      • bigstrat2003 3y ago
        I think you mean "involves non-static typing"? If so, Python. You can't (for example) do something like '1 + "2"', because those types aren't compatible. It's dynamically, but strongly, typed.
• ndr 3y ago
  Consider reading/watching Rich Hickey's talk Effective Programs [0][1] and Maybe Not [2][3] In [0] in particular there're slides 22/23, here is part of the transcript but makes more sense with the slides on: > And you can call them problems, and I'm going to call them the problems of programming. And I've ordered them here [...] I've ordered them here in terms of severity. And severity manifests itself in a couple of ways. Most important, cost. What's the cost of getting this wrong? At the very top you have the domain complexity, about which you could do nothing. This is just the world. It's as complex as it is. > > But the very next level is the where we start programming, right? We look at the world and say, "I've got an idea about how this is and how it's supposed to be and how, you know, my program can be effective about addressing it". And the problem is, if you don't have a good idea about how the world is, or you can't map that well to a solution, everything downstream from that is going to fail. There's no surviving this misconception problem. And the cost of dealing with misconceptions is incredibly high. > >So this is 10x, a full order of magnitude reduction in (?) severity before we get to the set of problems I think are more in the domain of what programming languages can help with, right? And because you can read these they'll all going to come up in a second as I go through each one on some slide so I'm not going to read them all out right now. But importantly there's another break where we get to trivialisms of problems in programming. Like typos and just being inconsistent, like, you thought you're going to have a list of strings and you put a number in there. That happens, you know, people make those kinds of mistakes, they're pretty inexpensive. [0] Video: https://www.youtube.com/watch?v=2V1FtfBDsLU https://www.youtube.com/watch?v=2V1FtfBDsLU [1] Slides and transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/EffectivePrograms.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... [2] Video https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=YR5WdGrpoug [3] Slides and transcript https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/MaybeNot.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
• sumtechguy 3y ago
  Weak typing has its uses in one use case. Transition between systems. Even then you usually want to know what the type is (unless you really do not care about validation errors). The reality is I never get to choose. I prefer strong typing. But the projects I am on that ship sailed long ago 2 developers back who used this project as a resume builder.