7 ms·

> Straight-up incorrect. Language designers think long and hard about how typings work in their languages. Rob Pike, Ken Thompson, and Russ Cox deliberated gene

> Straight-up incorrect. Language designers think long and hard about how typings work in their languages. Rob Pike, Ken Thompson, and Russ Cox deliberated generics for like a decade[1] before finally allowing them in Go. I think that kind of proves their point. Parametric polymorphism is one of the most well-understood, least contentious extensions to the lambda calculus. It's formalized by System F and has been implemented in programming languages 40 years ago with great type inference for an important subset (Hindley-Milner). Yet generics was highly controversial in the Go community. And now since none of the standard library was designed with generics in mind, it's full of unsafe patterns that involve essentially dynamic typing (e.g., the `Value` method of `Context`). Despite Rob Pike et al. designing one of the most popular languages today (Go), I consider them more experts in systems rather than programming languages. > I'm not sure exactly what you mean by "proper" -- but "rigid" type systems are extremely cumbersome to use practically. (Typed) λ-calculus is an academic example; Haskell is a real-world example. I find Haskell a joy to use, and I cringe at having to use languages like Java and Go, which are a minefield of error-prone programming patterns (like using products instead of sums to represent "result or error"). Generally speaking, my Haskell code is shorter, less buggy, and more reusable than my Go code, so I'm not sure what you mean by "cumbersome".

dvt 5y ago
> I find Haskell a joy to use, and I cringe at having to use languages like Java and Go, which are a minefield of error-prone programming patterns (like using products instead of sums to represent "result or error"). Generally speaking, my Haskell code is shorter, less buggy, and more reusable than my Go code, so I'm not sure what you mean by "cumbersome". I just want you to realize that you are in the extreme minority here, but just from a common-sense POV, if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. I just want to build something quickly without much hoopla (hence the massive popularity of very weakly-typed languages like JS and Python). FWIW, I think that generics are a mistake in Go, but I was just trying to counter the point that language designers don't think long and hard about type-theoretic features. I think the main issue with generics, wasn't so much an inept "we don't know how to do this," but rather "is this worth the code complexity?" and "is this worth the added compile times?" -- both of which were main selling points of Go.
- youerbt 5y ago
  > > just from a common-sense POV, if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. Then don't. It's not like Haskell forces you to, that's a myth about Haskell. You can get away with strings and integers everywhere if you so fancy. There is just no common-sense in thinking that computer assisted programming is slower than unassisted.
- ebingdom 5y ago
  > I just want you to realize that you are in the extreme minority here I'm in the minority because I've spent an unusual amount of time investing in my understanding of programming languages and their features, not because I have some fringe unjustified opinion. > if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. With this comment you've lost your credibility in my mind. No one actually goes through this train of thought. I don't wonder about recursive enumerability whenever I start a project. I just use tools that help me build high quality software, such as principled static type systems.
  - dvt 5y ago
    > I'm in the minority because I've spent an unusual amount of time investing in my understanding of programming languages and their features, not because I have some fringe unjustified opinion. I was just making a statement of fact. You're probably a very good programmer (as most type nerds, to coin a new term, tend to be), but still in the minority. Most programmers are not very good, and even good ones sometimes want to build things fast. (Where type ambiguity or even incorectness is accepted as a viable trade-off.) This is why I stopped prototyping in Java, for example. JS just let me "do stuff" without thinking about it too hard. Lower code quality? Of course; but it let me try out more ideas in the same amount of time. Should you use JavaScript to write the operating system of a pacemaker? Probably not.
    - novok 5y ago
      IMO there is also 'culture' to various programming languages in their styles, standard libraries and so on. I think Java as language is actually fine, it's all the crap that surrounds it that makes it more unproductive or not. I find my self even once I get past 2000 lines that using something like python is less productive than a statically typed language.
obviouslynotme 5y ago
This is because type checking is the least impactful part of generics. As you said, that is a solved problem. The reason Go took so long thinking about generics has to do with their code generation. There are steep tradeoffs in compilation vs run time as well as compiler complexity and language complexity in general. Go's purpose was to be very fast to compile and run, born in a company where compile times for several projects run for hours even with massive parallelization. There is very good reason that Go's initial compromise was to use built-ins for a small number of highly useful generics like arrays and maps.
bitmapper 5y ago
Parametric polymorphism is even older than that! It's almost 60 years old, having originated in CPL.
kaba0 5y ago
Java uses sum types for “result or error”. Exceptions just make it a language-level construct, with automatic addition of very useful stacktraces, auto-unwrap in the “result” case, etc.

dvt 5y ago

> I find Haskell a joy to use, and I cringe at having to use languages like Java and Go, which are a minefield of error-prone programming patterns (like using products instead of sums to represent "result or error"). Generally speaking, my Haskell code is shorter, less buggy, and more reusable than my Go code, so I'm not sure what you mean by "cumbersome". I just want you to realize that you are in the extreme minority here, but just from a common-sense POV, if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. I just want to build something quickly without much hoopla (hence the massive popularity of very weakly-typed languages like JS and Python). FWIW, I think that generics are a mistake in Go, but I was just trying to counter the point that language designers don't think long and hard about type-theoretic features. I think the main issue with generics, wasn't so much an inept "we don't know how to do this," but rather "is this worth the code complexity?" and "is this worth the added compile times?" -- both of which were main selling points of Go.

youerbt 5y ago
> > just from a common-sense POV, if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. Then don't. It's not like Haskell forces you to, that's a myth about Haskell. You can get away with strings and integers everywhere if you so fancy. There is just no common-sense in thinking that computer assisted programming is slower than unassisted.
ebingdom 5y ago
> I just want you to realize that you are in the extreme minority here I'm in the minority because I've spent an unusual amount of time investing in my understanding of programming languages and their features, not because I have some fringe unjustified opinion. > if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. With this comment you've lost your credibility in my mind. No one actually goes through this train of thought. I don't wonder about recursive enumerability whenever I start a project. I just use tools that help me build high quality software, such as principled static type systems.
- dvt 5y ago
  > I'm in the minority because I've spent an unusual amount of time investing in my understanding of programming languages and their features, not because I have some fringe unjustified opinion. I was just making a statement of fact. You're probably a very good programmer (as most type nerds, to coin a new term, tend to be), but still in the minority. Most programmers are not very good, and even good ones sometimes want to build things fast. (Where type ambiguity or even incorectness is accepted as a viable trade-off.) This is why I stopped prototyping in Java, for example. JS just let me "do stuff" without thinking about it too hard. Lower code quality? Of course; but it let me try out more ideas in the same amount of time. Should you use JavaScript to write the operating system of a pacemaker? Probably not.
  - novok 5y ago
    IMO there is also 'culture' to various programming languages in their styles, standard libraries and so on. I think Java as language is actually fine, it's all the crap that surrounds it that makes it more unproductive or not. I find my self even once I get past 2000 lines that using something like python is less productive than a statically typed language.

obviouslynotme 5y ago

This is because type checking is the least impactful part of generics. As you said, that is a solved problem. The reason Go took so long thinking about generics has to do with their code generation. There are steep tradeoffs in compilation vs run time as well as compiler complexity and language complexity in general. Go's purpose was to be very fast to compile and run, born in a company where compile times for several projects run for hours even with massive parallelization. There is very good reason that Go's initial compromise was to use built-ins for a small number of highly useful generics like arrays and maps.

bitmapper 5y ago

Parametric polymorphism is even older than that! It's almost 60 years old, having originated in CPL.

kaba0 5y ago

Java uses sum types for “result or error”. Exceptions just make it a language-level construct, with automatic addition of very useful stacktraces, auto-unwrap in the “result” case, etc.