11 ms·

People who use dynamically-typed languages are finally realizing that having to simulate a type-checker mentally is a bad idea. Also, many statically-typed lan

• rational_indian 6y ago
  Better late than never.
• kashif 6y ago
  Java is not a good type system at all - Haskell is.
  • nesarkvechnep 6y ago
    That's what the OC said.
    • kashif 6y ago
      Ah my bad. I misread that.
  • SAI_Peregrinus 6y ago
    They listed those three as examples of languages that don't take good advantage of having static typing.
• BiteCode_dev 6y ago
  It's a trade off. You don't want to write all your types for quick scripts, data analysis and small web sites. As a trainer, experience teaches me that it's also much easier for beginners. Now, types are nice to have for bigger code bases, but that doesn't mean there is no place for a language with optional typing.
  • smlckz 6y ago
    There is Hindley-Milner type inference. Don't need to type types in most cases. See, for example, OCaml.
    • wool_gather 6y ago
      That comes with its own tradeoffs: increased compile time and more effort needed to create error messages that are helpful to the user.
      • jgwil2 6y ago
        > more effort needed to create error messages that are helpful to the user. Well, sure, but that's a tradeoff for the developers of the language to consider. As a user, there are already plenty of statically typed languages to choose from with many person-hours put into just that.
      • erik_seaberg 6y ago
        I want to offload as much work as we possibly can to the compiler. My brain will always be millions of times slower.
      • GeorgeWBasic 6y ago
        Ocaml is probably the fastest compiling language I've ever used.
    • rscho 6y ago
      Type inference does not mean untyped. Arguably, getting a type error when you didn't write a single type hint makes things even more confusing if you are not an experienced programmer.
  • dan_quixote 6y ago
    Is it really that burdensome for novice programmers? Maybe it's just been too long for me to remember the pains...but I'd expect most novices to heavily use primitive types which shouldn't be that hard to grok.
• deleted 6y ago
  [deleted]
• rscho 6y ago
  Contra: (some) people doing exploratory programming in the small e.g. scientists don't want to have to deal with the type checker. Type systems like Haskell add a lot of value, but you have to really know the language to make good use of it. I mean, just IO handling requires planning ahead. Small dynamic languages allow one to keep simple things simple. There's value in that too.
  • bluejekyll 6y ago
    Everything comes with trade offs. But I’d argue that one of the primary reasons folks avoid types is that it requires additional learning. I’m speculating here, but as a software engineer who’s dealt with many different languages, I (personally) find types to increase my productivity, because it reduces errors at runtime. This is a huge benefit, and because I’ve spent a lot of time learning the target language’s type system, it doesn’t come at the cost of productivity, and like I said, I find it to improve my downstream productivity. I’ve read that scientists have had significant mistakes in their findings in papers due to bugs, which I know is anecdotal, but it seems like adopting typed languages would reduce those errors and increase confidence in studies. I wonder if they were able to recognize the downstream benefits of types, if they would shrug them off as irrelevant to their work.
    • rscho 6y ago
      It's true that many papers have mistakes, but the reasons for that go further than types, the main one being the prevalence of uneducated spreadsheet warriors. I definitely agree that if you're making a big custom model you should use a typed language. But indeed, that requires a lot of learning, so the investment has to be worth it. The problem is often that scientists don't program all day, so remembering language intricacies is hard. Dynamic languages that can have their whole syntax written on a postcard make things much easier from that pov.
      • jolux 6y ago
        Haskell syntax would probably fit on a postcard too. I think type systems are orthogonal to syntactic complexity.
• slifin 6y ago
  As a Clojurian I just run static analysis It can be nice to use an optional type/spec system to help with that but not required
• jgwil2 6y ago
  What is so bad about Java/C++?
  • valenterry 6y ago
    They can't even describe simple problems without using escape hatches (ignoring C++'s crazy templates). Example: Everyone in your system has a role. There are 3 kind of roles: User, Moderator, Admin They have different attributes. All of them have a name, but only moderators and admins have dedicates areas of responsibility. And only moderators have a subset of at least one allowed permission (e.g. "edit posts" and/or "delete posts"). You can't really denote this in a way that the Java compiler understands it at the use site. E.g. an action is executed and you want to see if it is allowed. So you want to check the kind of role and if the attributes/permissions match the action or not. The compiler doesn't support this well at ala.
    • jgwil2 6y ago
      So the problem is that the type system does not give you the type of the caller of a method? Does e.g. Haskell support this? (As an aside, I think one solution in Java would be to use the command pattern and pass an object (ModeratorCommand, etc.) to whatever code is processing your actions, so it can type check the command.)
      • valenterry 6y ago
        It's more that you simply can't define your datastructure correctly. > Does e.g. Haskell support this? Sure, and it is not certainly not the only language. E.g.: data Role = User String | Moderator String [Area] NonEmpty Permission | Admin String [Area] I'm not even saying that this is the best way of modeling it - but with Java you unfortunately can't really define it. > (As an aside, I think one solution in Java would be to use the command pattern and pass an object (ModeratorCommand, etc.) to whatever code is processing your actions, so it can type check the command.) The problem stays the same though: how do you know what kind of command it is that you just received? You cannot safely "match" on the command in the same way you can in other languages, because the compiler doesn't know that there are only exactly 3 types of commands.
• raverbashing 6y ago
  The annoying part about (traditional) type checking is having to do it all the time But the optional Python annotations? I was skeptical, but I began to see the value in it, especially in interfaces/APIs for external consumption, or more complicated areas. But yeah don't ask me to type hint a "private" function that's only a couple of lines long and used in specific cases
• oivey 6y ago
  I’ve found that enforcing types users (including myself) can use with my code is a bad idea. Informal specifications are simpler and enable massive code reuse. Inheritance in OOP was meant to SRN able code reuse in static languages, but has largely failed. In OOP, library interoperability can only be achieved if all developers know a common set of subtypes that satisfy all cases, which can never be true. The granularity of trait systems is better, but still suffers from the same issue.
  • notretarded 6y ago
    >enforcing types users (including myself) can use with my code is a bad idea Adaptor pattern.
• konjin 6y ago
  >People who use dynamically-typed languages are finally realizing that having to simulate a type-checker mentally is a bad idea. I'd say that the pool of python developers has been swamped by a tsunami of former java/c# developers who don't understand the first thing about what made python good and are demanding they get everything they were used to in their old languages in python. It's a rather sad state of affairs, but it's been great for cashing out on a language I learned in my off time at highschool in the 00s, especially since I have my name as a contributor before I turned 18.
  • oblio 6y ago
    Or you could look at it as Python growing up and being used for long lived projects with tens and hundreds of developers of varying skill levels, where you need to do things such as... safely refactor large amounts of code quickly.
    • konjin 6y ago
      Yes, I already said a tsunami of developers who do not know how to use python.
      • oblio 6y ago
        As opposed to the many Python gurus writing short scripts? :-)
        • konjin 6y ago
          Yes. Python is glue. If you build a stick bridge with just glue you sound like the type of person who ate most of it.
    • pansa2 6y ago
      Maybe it’s “growing up”, but I agree that Python has definitely changed its focus. It has pivoted towards the handful of companies with “projects with tens and hundreds of developers“ at the expense of the millions(?) of people using it for much smaller projects. As part of the latter group, I don’t consider this change in focus to be a good thing.
• socialdemocrat 6y ago
  Utilizing a type checker when you want is very different from being forced to use it. Statically typed languages create a lot of complexity from being entirely dependent on types being correct in a static sense rather than at runtime. With type checkers for dynamic languages, a lot of the arguments in favor of static languages disappear.
  • pansa2 6y ago
    > Statically typed languages create a lot of complexity from being entirely dependent on types being correct in a static sense rather than at runtime. Python’s type annotations aren’t checked at runtime, though - they’re also entirely static. So you either have to: - Write code that’s as pedantically correct as in a traditional statically-typed language (e.g. by using `mypy —-strict`), in which case you’d be better off using a language that supports AOT-compilation, or - Be prepared for cases where the runtime type doesn’t match the annotation. This is unacceptable - I hate the idea of code that tells lies.
    • gypsyharlot 6y ago
      You're entirely forgetting the benefits. 1) Scientists, hobbyists etc. can be super productive with Python while disregarding types. 2) Software developers can write serious applications with type checking. Statically typed languages exclude group that benefit from 1).
      • pansa2 6y ago
        A language that tries to satisfy both of these groups won’t be ideal for either of them. Python should aim to be perfect for group 1. There are many other languages that will always be a better choice for group 2.
        • gypsyharlot 6y ago
          I disagree. You can spend 90% of your time doing e.g. data science, and then one day you need to integrate with a DB or make a cross-platform desktop GUI application, as an example. Should you learn C++ (it takes a decade to become a very mediocre C++-developer), or Java to write a desktop GUI application? No, there isn't "always" a better choice for group 2. - Most software isn't CPU bound, so that defies "always" in your argument - You need libraries get things done What language would you always pick for group 2? Or would you pick a different one for each task, spending an order of magnitude more time learning them?
• flohofwoe 6y ago
  I'm a fan of static typing (but not necessarily overly strong typing) myself, but one big reason why I use Python next to statically typed languages is to write quick and dirty cross-platform-scripts where the sloppy duck typing comes in handy. Want to throw vastly different things into a single array (sometimes not even knowing what type those things are)? No problem, it just works. This type of quick'n'dirty throw-away coding would be a lot less convenient if Python would force a strong static type system on me. If Python is used for "real projects" with more than a few thousand lines of code, worked on by a team, static typing totally makes sense. But there are a lot of everyday tasks where this just gets in the way.
• d0mine 6y ago
  > People who use dynamically-typed languages are finally realizing that having to simulate a type-checker mentally is a bad idea. It cuts both ways. Some days type advocates recognize why their type language is not their host language i.e., there is a such a thing as too much types. If you believe types can express anything, and more over they are the best at expressing it then why do you need the host language, why not to program using just types. There is no silver bullet. Types won't make your code bug free. What programming language do you know that uses types to express most tests?