6 ms·

> 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

> 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.
- yawaramin 6y ago
  > in many statically typed languages this involves bitwise operators, lots of boilerplate, and mental hoops to adapt to an API 50 years old. Bitstring in OCaml: https://bitstring.software/ https://bitstring.software/ Just as simple as in Erlang. > I know for a fact that static typed languages don't help that much. How do you know this? > We all know that static typed languages are harder to learn and master Again–how do you know this? > Erlang has int (arbitrary length, like in real life) and floats. It is definitely easier. OCaml has int and float, simple. > We've all seen companies like Github, Twitter, Airbnb, born because Ruby on Rails exists. These companies are now using Haskell, Scala, TypeScript. > Facebook was written in PHP. Fb created Hack, a statically-typed language that compiles to PHP. It has at least two other static-typing language compilers. > Rust creates incredibly fast code, it has an incredibly slow compiler. Is this proving something? > Did you have this problem recently? Yes–I and many others have this problem constantly, because we are mostly paid to work on existing codebases, not throwaway scripts. > Of course the answer is "this is the programmers fault", but if it's wrong, why is it allowed? Why is it allowed in dynamically-typed languages? Because it's useful. Same reason. > Types are harder to understand and to correctly plan ahead for. Types are not unchangeable; the whole point is that you can safely change code that has a typing discipline. > it takes a great programmer to use types correctly in a way that others will comprehend without prior knowledge of the domain. Then it must take an incredible programmer to maintain a dynamically-typed codebase.
  - romanoderoma 6y ago
    > Bitstring in OCaml: https://bitstring.software/ https://bitstring.software/ Nobody has ever criticized Ocaml here You are proving my point: pattern matching can bring you far without the need for types >> I know for a fact that static typed languages don't help that much. > How do you know this? Why, in you opinion, hardcore statically typed languages have all, over time, imlpemente some form of type inference? Even C++ has type inference now. There must be a reason why... but I don' t know what it is. Let's review a bit of history together, shall we? From day one, C++ had magic. Dark witchcraft: destructors. Suddenly the compiler was doing things on its own. It also had type inference very early on, __but the developers of the mid-80s were not quite ready for that__ and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. People nowadays wants safety of statically typed languages, but don' t want to type them. Back then if you were using languages without explicit types, you weren't a "real programmer". That's the only reason we have more C++ than Ocaml. I remember how it was. > These companies are now using Haskell, Scala, TypeScript. They are also using Lisp, Smalltalk, Perl, Erlang, Rust, Ruby (Github is still mainly a Ruby app). And Python, don' t forget the ton of Python they use. So what? > Yes–I and many others have this problem constantly, because we are mostly paid to work on existing codebases, not throwaway scripts. Well, if you are disciplined when writing types, why aren't you when refactoring? I work on codebases that are already 6 or 7 years old and have been re-written from scratch in new languages. It's just a mental model, none is inherently superior. It's the same thing you said about casting everything to Object, why do we need to change every function when refactoring? It's more useful if you don' t have to, unless it' s strictly necessary (i.e. the type behaviour has changed). > Fb created Hack, a statically-typed language that compiles to PHP. It has at least two other static-typing language compilers. because they are FB are you FB? I wish I had their problems Are you really saying that what FB does applies to the general population? Besides, when FB created hack PHP was 10 times slower than today. >> Rust creates incredibly fast code, it has an incredibly slow compiler. > Is this proving something? That there are always trade offs, for example? > Types are not unchangeable; the whole point is that you can safely change code that has a typing discipline. nobody will ever admit how much work it takes to having typing discipline. because it's part of the deal, it's hard, but rewarding, it immediately bring you on top of the food chain. you know the secret of steel. on the other side, nobody wants to use discipline when using not statically typed languages. and just scoff on the language when they forget to change a few function signatures (THOU SHALT NOT FIX CODE BY HAND). > Then it must take an incredible programmer to maintain a dynamically-typed codebase. It requires the same discipline that won't let you forget you had an appointment with the dentist. Everyone can have it. It's not an art for initiated, it's simply being routinely organized.

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.

yawaramin 6y ago
> in many statically typed languages this involves bitwise operators, lots of boilerplate, and mental hoops to adapt to an API 50 years old. Bitstring in OCaml: https://bitstring.software/ https://bitstring.software/ Just as simple as in Erlang. > I know for a fact that static typed languages don't help that much. How do you know this? > We all know that static typed languages are harder to learn and master Again–how do you know this? > Erlang has int (arbitrary length, like in real life) and floats. It is definitely easier. OCaml has int and float, simple. > We've all seen companies like Github, Twitter, Airbnb, born because Ruby on Rails exists. These companies are now using Haskell, Scala, TypeScript. > Facebook was written in PHP. Fb created Hack, a statically-typed language that compiles to PHP. It has at least two other static-typing language compilers. > Rust creates incredibly fast code, it has an incredibly slow compiler. Is this proving something? > Did you have this problem recently? Yes–I and many others have this problem constantly, because we are mostly paid to work on existing codebases, not throwaway scripts. > Of course the answer is "this is the programmers fault", but if it's wrong, why is it allowed? Why is it allowed in dynamically-typed languages? Because it's useful. Same reason. > Types are harder to understand and to correctly plan ahead for. Types are not unchangeable; the whole point is that you can safely change code that has a typing discipline. > it takes a great programmer to use types correctly in a way that others will comprehend without prior knowledge of the domain. Then it must take an incredible programmer to maintain a dynamically-typed codebase.
- romanoderoma 6y ago
  > Bitstring in OCaml: https://bitstring.software/ https://bitstring.software/ Nobody has ever criticized Ocaml here You are proving my point: pattern matching can bring you far without the need for types >> I know for a fact that static typed languages don't help that much. > How do you know this? Why, in you opinion, hardcore statically typed languages have all, over time, imlpemente some form of type inference? Even C++ has type inference now. There must be a reason why... but I don' t know what it is. Let's review a bit of history together, shall we? From day one, C++ had magic. Dark witchcraft: destructors. Suddenly the compiler was doing things on its own. It also had type inference very early on, __but the developers of the mid-80s were not quite ready for that__ and Bjarne Stroustrup was pressured into removing auto, until it was added back to C++11. People nowadays wants safety of statically typed languages, but don' t want to type them. Back then if you were using languages without explicit types, you weren't a "real programmer". That's the only reason we have more C++ than Ocaml. I remember how it was. > These companies are now using Haskell, Scala, TypeScript. They are also using Lisp, Smalltalk, Perl, Erlang, Rust, Ruby (Github is still mainly a Ruby app). And Python, don' t forget the ton of Python they use. So what? > Yes–I and many others have this problem constantly, because we are mostly paid to work on existing codebases, not throwaway scripts. Well, if you are disciplined when writing types, why aren't you when refactoring? I work on codebases that are already 6 or 7 years old and have been re-written from scratch in new languages. It's just a mental model, none is inherently superior. It's the same thing you said about casting everything to Object, why do we need to change every function when refactoring? It's more useful if you don' t have to, unless it' s strictly necessary (i.e. the type behaviour has changed). > Fb created Hack, a statically-typed language that compiles to PHP. It has at least two other static-typing language compilers. because they are FB are you FB? I wish I had their problems Are you really saying that what FB does applies to the general population? Besides, when FB created hack PHP was 10 times slower than today. >> Rust creates incredibly fast code, it has an incredibly slow compiler. > Is this proving something? That there are always trade offs, for example? > Types are not unchangeable; the whole point is that you can safely change code that has a typing discipline. nobody will ever admit how much work it takes to having typing discipline. because it's part of the deal, it's hard, but rewarding, it immediately bring you on top of the food chain. you know the secret of steel. on the other side, nobody wants to use discipline when using not statically typed languages. and just scoff on the language when they forget to change a few function signatures (THOU SHALT NOT FIX CODE BY HAND). > Then it must take an incredible programmer to maintain a dynamically-typed codebase. It requires the same discipline that won't let you forget you had an appointment with the dentist. Everyone can have it. It's not an art for initiated, it's simply being routinely organized.