4 ms·

> 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 lang

> 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.
- romanoderoma 6y ago
  I am a counterpoint myself, I don't consider myself a particularly experienced programmer, but I rarely encounter type errors, most of them are semantic or logic errors. I'm faster at finding and solving the issues with languages I know best (not surprisingly) regardless of their static or dynamic nature. Experience, in my case, is knowing where to look, being able to quickly parse an error message, from the compiler, the linter or the runtime, but most of all knowing the code base at heart. When I confront a code base that is new for me, I feel lost, whatever paradigm has been used. I simply don't know where to put my hands before I spent time reading and analyzing it. The time required to understand it depends exclusively on the complexity of the project. There hasn't been a single time where types have helped me (more than being able to grep the function signature) or their absence slowed me down.
  - nwienert 6y ago
    JavaScript and TypeScript are great because you can compare them directly and they are essentially the same language, one with types. And as someone who has written JS for over a decade, TS is hands down better, it’s not been close how much nicer it is to work in the latter. The bigger the project is the more it helps.
    - romanoderoma 6y ago
      > TS is hands down better Don't want to sound harsh, but it doesn't take much to be better than JS
      - nwienert 6y ago
        You don't sound harsh, just uninformed and unable to make a counterargument.
pyrale 6y ago
> 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. I have had the opportunity to teach java programmers the basics of Haskell, and indeed, it was not great. Trying to tell java programmers to write haskell-flavored java is not a great idea. On the other hand, I have also had the opportunity to work with C#, JS, C programmers that were taught to work in a haskell codebase, and the result was much better. I guess using a language explicitly made for this helps a lot.
- romanoderoma 6y ago
  My experience is similar Not because of their Java background, but because the complexity of developing in Java is hidden behind tooling not available in other languages, that make it manageable It is almost unimaginable for Java programmers to use vim or a non Windows setup (thanks to Java IDE like Eclipse, Nerbeans or Intellij that's less of a problem nowadays)
devmunchies 6y ago
> I'm simply pointing out that most statically typed languages, the most used ones especially, don't particularly benefit from static typing That's an opinion presented as fact. You are outright discounting the opposing view. That's why you're being downvoted, not because anyone is being emotional. Some benefits: - performance. compiler can make huge optimizations if it knows the types. - refactoring. changing functions might change data expected in another function. you could remedy this with unit tests, or just use static typing. - onboarding. new developers on a project, regardless of experience, don't "layout the types in their head", static typing helps.
- romanoderoma 6y ago
  > That's an opinion presented as fact. You are outright discounting the opposing view. That's why you're being downvoted, not because anyone is being emotional. I don't care about the downvotes, I know people are irrational, especially when they feel that their beliefs are being questioned. But static types are non essentials for a successful career as programmer, especially in languages like Erlang (or Elixir) where I can take data from a socket and write something like def f(<<type::big-integer-2, value::big-integer-6, rest::binary>>) do ... f(rest) end def f(_), do: #no valid match, log the error and be done with it, while in many statically typed languages this involves bitwise operators, lots of boilerplate, and mental hoops to adapt to an API 50 years old. Anyway I was answering to "Is possible to do" isn't the same as "helps you to so"" I know for a fact that static typed languages don't help that much. The most advanced ones are in fact not widely used (I am a big fun of Idris, I love Gleam, I love Helm, now try to convince the company you work for to use it or try to hire programmers for it) We all know that static typed languages are harder to learn and master, especially for those that do not have a formal computer science background. Is it really important to know the difference between int8, int16, int32, int64, float and double? Erlang has int (arbitrary length, like in real life) and floats. It is definitely easier. We've all seen companies like Github, Twitter, Airbnb, born because Ruby on Rails exists. Facebook was written in PHP. The benefits you list are all real, but they do not create better code out of thin air. For example > performance. compiler can make huge optimizations if it knows the types Rust creates incredibly fast code, it has an incredibly slow compiler. > refactoring. changing functions might change data expected in another function. you could remedy this with unit tests, or just use static typing. Did you have this problem recently? Static code analyzers exist for many languages. Talking about Erlang (Elixir in the specific case) mix xref solves most of my "contract with the caller" problem void* f(void *) { ... } can you tell what's the right argument for this function and what type is returned? Am I the only one that routinely find this kind of signatures? public void trace(String format, Object arg) {} public void trace(String format, Object arg1, Object arg2) {} public void trace(String format, Object... arguments) {} Of course the answer is "this is the programmers fault", but if it's wrong, why is it allowed? What's the path of least resistance for statically typed languages? > onboarding. new developers on a project, regardless of experience, don't "layout the types in their head", static typing helps. In my experience the opposite is true. Types are harder to understand and to correctly plan ahead for. It takes a good programmer to write code that anybody with a basic knowledge of the language can read and understand, it takes a great programmer to use types correctly in a way that others will comprehend without prior knowledge of the domain.

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.

romanoderoma 6y ago
I am a counterpoint myself, I don't consider myself a particularly experienced programmer, but I rarely encounter type errors, most of them are semantic or logic errors. I'm faster at finding and solving the issues with languages I know best (not surprisingly) regardless of their static or dynamic nature. Experience, in my case, is knowing where to look, being able to quickly parse an error message, from the compiler, the linter or the runtime, but most of all knowing the code base at heart. When I confront a code base that is new for me, I feel lost, whatever paradigm has been used. I simply don't know where to put my hands before I spent time reading and analyzing it. The time required to understand it depends exclusively on the complexity of the project. There hasn't been a single time where types have helped me (more than being able to grep the function signature) or their absence slowed me down.
- nwienert 6y ago
  JavaScript and TypeScript are great because you can compare them directly and they are essentially the same language, one with types. And as someone who has written JS for over a decade, TS is hands down better, it’s not been close how much nicer it is to work in the latter. The bigger the project is the more it helps.
  - romanoderoma 6y ago
    > TS is hands down better Don't want to sound harsh, but it doesn't take much to be better than JS
    - nwienert 6y ago
      You don't sound harsh, just uninformed and unable to make a counterargument.

pyrale 6y ago

> 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. I have had the opportunity to teach java programmers the basics of Haskell, and indeed, it was not great. Trying to tell java programmers to write haskell-flavored java is not a great idea. On the other hand, I have also had the opportunity to work with C#, JS, C programmers that were taught to work in a haskell codebase, and the result was much better. I guess using a language explicitly made for this helps a lot.

romanoderoma 6y ago
My experience is similar Not because of their Java background, but because the complexity of developing in Java is hidden behind tooling not available in other languages, that make it manageable It is almost unimaginable for Java programmers to use vim or a non Windows setup (thanks to Java IDE like Eclipse, Nerbeans or Intellij that's less of a problem nowadays)

devmunchies 6y ago

> I'm simply pointing out that most statically typed languages, the most used ones especially, don't particularly benefit from static typing That's an opinion presented as fact. You are outright discounting the opposing view. That's why you're being downvoted, not because anyone is being emotional. Some benefits: - performance. compiler can make huge optimizations if it knows the types. - refactoring. changing functions might change data expected in another function. you could remedy this with unit tests, or just use static typing. - onboarding. new developers on a project, regardless of experience, don't "layout the types in their head", static typing helps.

romanoderoma 6y ago
> That's an opinion presented as fact. You are outright discounting the opposing view. That's why you're being downvoted, not because anyone is being emotional. I don't care about the downvotes, I know people are irrational, especially when they feel that their beliefs are being questioned. But static types are non essentials for a successful career as programmer, especially in languages like Erlang (or Elixir) where I can take data from a socket and write something like def f(<<type::big-integer-2, value::big-integer-6, rest::binary>>) do ... f(rest) end def f(_), do: #no valid match, log the error and be done with it, while in many statically typed languages this involves bitwise operators, lots of boilerplate, and mental hoops to adapt to an API 50 years old. Anyway I was answering to "Is possible to do" isn't the same as "helps you to so"" I know for a fact that static typed languages don't help that much. The most advanced ones are in fact not widely used (I am a big fun of Idris, I love Gleam, I love Helm, now try to convince the company you work for to use it or try to hire programmers for it) We all know that static typed languages are harder to learn and master, especially for those that do not have a formal computer science background. Is it really important to know the difference between int8, int16, int32, int64, float and double? Erlang has int (arbitrary length, like in real life) and floats. It is definitely easier. We've all seen companies like Github, Twitter, Airbnb, born because Ruby on Rails exists. Facebook was written in PHP. The benefits you list are all real, but they do not create better code out of thin air. For example > performance. compiler can make huge optimizations if it knows the types Rust creates incredibly fast code, it has an incredibly slow compiler. > refactoring. changing functions might change data expected in another function. you could remedy this with unit tests, or just use static typing. Did you have this problem recently? Static code analyzers exist for many languages. Talking about Erlang (Elixir in the specific case) mix xref solves most of my "contract with the caller" problem void* f(void *) { ... } can you tell what's the right argument for this function and what type is returned? Am I the only one that routinely find this kind of signatures? public void trace(String format, Object arg) {} public void trace(String format, Object arg1, Object arg2) {} public void trace(String format, Object... arguments) {} Of course the answer is "this is the programmers fault", but if it's wrong, why is it allowed? What's the path of least resistance for statically typed languages? > onboarding. new developers on a project, regardless of experience, don't "layout the types in their head", static typing helps. In my experience the opposite is true. Types are harder to understand and to correctly plan ahead for. It takes a good programmer to write code that anybody with a basic knowledge of the language can read and understand, it takes a great programmer to use types correctly in a way that others will comprehend without prior knowledge of the domain.