7 ms·

> "Is possible to do" isn't the same as "helps you to so" The things that help you usually also limit you See: training wheels or armbands I've seen much cod

> "Is possible to do" isn't the same as "helps you to so" The things that help you usually also limit you See: training wheels or armbands I've seen much code written in static typed languages (mostly JVM languages) that supposedly help the programmer to write better code or code with less errors just by playing tennis with the compiler Thruth is that most of the code I've seen written "with type aids" is terrible from any other point of view The types are correctly passed to each function, but what purpose those types serve it's a mistery When you only have numbers, binaries, lists and tuples,you are forced to think about data structures in a simpler and more elegant way IDE generated "type safe" code too often is simply "a class for everything" and bad abstractions Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each?

m45t3r 6y ago
> Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each? This is the fault of the language or programmer itself instead of its type system. I am programming in Dart and sometimes I feel that I am writing some code just to workaround some limitations in the language (the language itself is nice 90% of time, just to make it clear). Now, I also program in Python using mypy, and I never needed to write "10 getters and setters" to make the compiler happy. Sometimes I do need to write additional code to make mypy happy, but generally it is in overly clever code that mypy doesn't understand. So generally fixing the issues makes the code better.
- romanoderoma 6y ago
  > This is the fault of the language or programmer itself instead of its type system. Not that I disagree, but I argue that bad programmers are the result of bad languages enabling them and bad use of types by the programmers is the result of a bad implementation of types in the language. Most of the statically typed languages around are used to enforce conventions inside large teams of coders, they are not used to "model the problem elegantly". If type driven development really produced bug free code while requiring the same cognitive load as hammering tens of lines of code one after the other, we will all be using something like Idris.
  - m45t3r 6y ago
    > Most of the statically typed languages around are used to enforce conventions inside large teams of coders This is not the fault of the type system though. It is the fault of things like enforcing access via private/protected/public keywords. While most people confuse this with a static type system, this is not part of the type system. > [..] they are not used to "model the problem elegantly". I concur, but let me make my point more clearly: this is either the fault of the language for not allowing the programmer to express itself clearly, or it is the fault of the programmer by using patterns from a less expressive programming language in a more expressive programming language. This is not the fault of the type system, that doesn't (by itself) require the user to create a Class with getters and setters for every attribute, for example. If the language you're using makes you do those kinda of things, it is the problem with the language itself, the type system is just the point of the iceberg (that is making the problem worse). > If type driven development really produced bug free code while requiring the same cognitive load as hammering tens of lines of code one after the other, we will all be using something like Idris. It doesn't produce bug free code (because there is still logic bugs), but it helps to reduce the number of bugs. But only in expressive type systems that are also sound. The Java type system for example doesn't help much (however I think they implemented nullables at some point, so the situation should be better).
thethimble 6y ago
> IDE generated "type safe" code too often is simply "a class for everything" and bad abstractions > Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each? Java is an extremely poor example of a helpful type system. Consider OCaml, Haskell, Elm, and others which avoid much of the verbosity you describe. Static typing is really helpful when doing refactoring. The fact that a statically typed program compiles gives you important assurances - especially post-refactor. It's not a silver bullet but it's also certainly not "playing tennis with the compiler" as you describe.
- romanoderoma 6y ago
  > Java is an extremely poor example of a helpful type system My point exactly! Most of them are. Java is not special in this regard. C? bad COBOL? bad C++? bad Pascal? bad Rust? better, but somewhat confusing Go? not particularly good, but at least it's very simple C#? same defects Java has etc. etc. Statically typed languages IMO are like turbo charged engines, if you are an expert driver you could go way faster, granted the road is in good shape, but if you are not, you'll crash, possibly in a horrible way. > The fact that a statically typed program compiles gives you important assurances - especially post-refactor. The only assurance in most of the statically typed languages is that code compiles, not that it works.
  - smabie 6y ago
    How about OCaml, Haskell, Scala, or F#? All have pretty decent type systems, with Scala and Haskell even supporting higher kinded types. I'm at the point where I refuse to write production code in a language that doesn't have an expressive type system. Dynamically typed languages are even worse.
    - romanoderoma 6y ago
      The worst code I've ever seen in my life are Spark scripts written in Scala. Scala is so complicated that people use only a fraction of its features, usually the simpler ones. It takes a real commitment to become a prolific Scala programmer. > Dynamically typed languages are even worse. I don't comment on personal taste, everybody has their own.
rkangel 6y ago
I think you're conflating "statically typed languages" with "object oriented languages" (they do go together a lot). Static typing with functional programming languages works really well because the types are so simple. If you look at OCaml, or Haskell, or F# you simple types, but with a lot of benefit of type checking.
- romanoderoma 6y ago
  > I think you're conflating "statically typed languages" with "object oriented languages" No, I'm not. I'm simply pointing out that most statically typed languages, the most used ones especially, don't particularly benefit from static typing. > Static typing with functional programming languages works really well because IMO it is because they are mostly used by more experienced programmers, that can already layout the types in their head. Try to teach the average Java programmer (I'm not saying I'm a better programmer, Iḿ just intending it as "they are trying to get through the day with the tool they already know") how to effectively use types "like in Haskell" and they will be confused at best. > OCaml, or Haskell, or F# I do look at them but together they make probably less than 5% of Java programmers, even less if we measure lines of code EDIT: My position is based on the time spent reading studies about the subject. Let's not be emotional and downvote what we don't like to hear and be more rational and look at the facts. If you like statically typed language because they make you feel safer, use them. Is it an universal property of statically typed languages? Id it a measurable phenomenon? Are statically typed languages inherently safer for everybody? The problem, at the time of writing, is undecidable. here's a review on the literature on the matter https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/ > Other than cherry picking studies to confirm a long-held position, the most common response I've heard to these sorts of studies is that the effect isn't quantifiable by a controlled experiment
  - aidenn0 6y ago
    > IMO it is because they are mostly used by more experienced programmers, that can already layout the types in their head. > Try to teach the average Java programmer (I'm not saying I'm a better programmer, Iḿ just intending it as "they are trying to get through the day with the tool they already know") how to effectively use types "like in Haskell" and they will be confused at best. Counterpoint: I don't use any ML/Haskell languages regularly, but I do use a couple of projects written in them[1]; my preferred language is Common Lisp, the It dynamic language. When I needed a feature, it was dead simple to do so. 1: matterhorn, the Mattetmost client and bower, the E-mail client, which are written respectively in Haskell and Mercury.
masukomi 6y ago
> The things that help you usually also limit you and yet, none of us seem to be programming in binary.... huh. Maybe there's some value in those "training wheels".

m45t3r 6y ago

> Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each? This is the fault of the language or programmer itself instead of its type system. I am programming in Dart and sometimes I feel that I am writing some code just to workaround some limitations in the language (the language itself is nice 90% of time, just to make it clear). Now, I also program in Python using mypy, and I never needed to write "10 getters and setters" to make the compiler happy. Sometimes I do need to write additional code to make mypy happy, but generally it is in overly clever code that mypy doesn't understand. So generally fixing the issues makes the code better.

romanoderoma 6y ago
> This is the fault of the language or programmer itself instead of its type system. Not that I disagree, but I argue that bad programmers are the result of bad languages enabling them and bad use of types by the programmers is the result of a bad implementation of types in the language. Most of the statically typed languages around are used to enforce conventions inside large teams of coders, they are not used to "model the problem elegantly". If type driven development really produced bug free code while requiring the same cognitive load as hammering tens of lines of code one after the other, we will all be using something like Idris.
- m45t3r 6y ago
  > Most of the statically typed languages around are used to enforce conventions inside large teams of coders This is not the fault of the type system though. It is the fault of things like enforcing access via private/protected/public keywords. While most people confuse this with a static type system, this is not part of the type system. > [..] they are not used to "model the problem elegantly". I concur, but let me make my point more clearly: this is either the fault of the language for not allowing the programmer to express itself clearly, or it is the fault of the programmer by using patterns from a less expressive programming language in a more expressive programming language. This is not the fault of the type system, that doesn't (by itself) require the user to create a Class with getters and setters for every attribute, for example. If the language you're using makes you do those kinda of things, it is the problem with the language itself, the type system is just the point of the iceberg (that is making the problem worse). > If type driven development really produced bug free code while requiring the same cognitive load as hammering tens of lines of code one after the other, we will all be using something like Idris. It doesn't produce bug free code (because there is still logic bugs), but it helps to reduce the number of bugs. But only in expressive type systems that are also sound. The Java type system for example doesn't help much (however I think they implemented nullables at some point, so the situation should be better).

thethimble 6y ago

> IDE generated "type safe" code too often is simply "a class for everything" and bad abstractions > Most of the time when I review code my remarks is: it should be a 10 lines function, why did you write 10 classes with 10 getters and setters each? Java is an extremely poor example of a helpful type system. Consider OCaml, Haskell, Elm, and others which avoid much of the verbosity you describe. Static typing is really helpful when doing refactoring. The fact that a statically typed program compiles gives you important assurances - especially post-refactor. It's not a silver bullet but it's also certainly not "playing tennis with the compiler" as you describe.

romanoderoma 6y ago
> Java is an extremely poor example of a helpful type system My point exactly! Most of them are. Java is not special in this regard. C? bad COBOL? bad C++? bad Pascal? bad Rust? better, but somewhat confusing Go? not particularly good, but at least it's very simple C#? same defects Java has etc. etc. Statically typed languages IMO are like turbo charged engines, if you are an expert driver you could go way faster, granted the road is in good shape, but if you are not, you'll crash, possibly in a horrible way. > The fact that a statically typed program compiles gives you important assurances - especially post-refactor. The only assurance in most of the statically typed languages is that code compiles, not that it works.
- smabie 6y ago
  How about OCaml, Haskell, Scala, or F#? All have pretty decent type systems, with Scala and Haskell even supporting higher kinded types. I'm at the point where I refuse to write production code in a language that doesn't have an expressive type system. Dynamically typed languages are even worse.
  - romanoderoma 6y ago
    The worst code I've ever seen in my life are Spark scripts written in Scala. Scala is so complicated that people use only a fraction of its features, usually the simpler ones. It takes a real commitment to become a prolific Scala programmer. > Dynamically typed languages are even worse. I don't comment on personal taste, everybody has their own.

rkangel 6y ago

I think you're conflating "statically typed languages" with "object oriented languages" (they do go together a lot). Static typing with functional programming languages works really well because the types are so simple. If you look at OCaml, or Haskell, or F# you simple types, but with a lot of benefit of type checking.

romanoderoma 6y ago
> I think you're conflating "statically typed languages" with "object oriented languages" No, I'm not. I'm simply pointing out that most statically typed languages, the most used ones especially, don't particularly benefit from static typing. > Static typing with functional programming languages works really well because IMO it is because they are mostly used by more experienced programmers, that can already layout the types in their head. Try to teach the average Java programmer (I'm not saying I'm a better programmer, Iḿ just intending it as "they are trying to get through the day with the tool they already know") how to effectively use types "like in Haskell" and they will be confused at best. > OCaml, or Haskell, or F# I do look at them but together they make probably less than 5% of Java programmers, even less if we measure lines of code EDIT: My position is based on the time spent reading studies about the subject. Let's not be emotional and downvote what we don't like to hear and be more rational and look at the facts. If you like statically typed language because they make you feel safer, use them. Is it an universal property of statically typed languages? Id it a measurable phenomenon? Are statically typed languages inherently safer for everybody? The problem, at the time of writing, is undecidable. here's a review on the literature on the matter https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/ > Other than cherry picking studies to confirm a long-held position, the most common response I've heard to these sorts of studies is that the effect isn't quantifiable by a controlled experiment
- aidenn0 6y ago
  > IMO it is because they are mostly used by more experienced programmers, that can already layout the types in their head. > Try to teach the average Java programmer (I'm not saying I'm a better programmer, Iḿ just intending it as "they are trying to get through the day with the tool they already know") how to effectively use types "like in Haskell" and they will be confused at best. Counterpoint: I don't use any ML/Haskell languages regularly, but I do use a couple of projects written in them[1]; my preferred language is Common Lisp, the It dynamic language. When I needed a feature, it was dead simple to do so. 1: matterhorn, the Mattetmost client and bower, the E-mail client, which are written respectively in Haskell and Mercury.

masukomi 6y ago

> The things that help you usually also limit you and yet, none of us seem to be programming in binary.... huh. Maybe there's some value in those "training wheels".