3 ms·

>every language is unique >every language is equivalently powerful >therefore, we should neither look to one language to improve another We seem to have made

by setr 10y ago

>every language is unique >every language is equivalently powerful >therefore, we should neither look to one language to improve another We seem to have made a mistake somewhere.

AnimalMuppet 10y ago
We didn't do any such thing. You seem to think that I did, based on putting words in my mouth that I never said, nor intended. Your response is therefore a strawman. Let's try again, shall we? Some languages are trying to serve different niches than other languages. Trying to copy features from one language to another can be useful. But if you're copying from a language that's used for a different niche, you can ruin the destination language's suitability for its own niche. What's Go's niche? The original intent was that it be useful for multi-million-line code bases that lived for multiple decades. Cost of compile time becomes a very big deal in that environment. (The original motivator was a 45-minute C++ compile. Multiply that times multiple developers, times multiple compiles per day, times 20 years, and it adds up to real money.) What's Rust's niche? It's lower-level (C++-ish) code with compiler-enforced safety. What's Haskell's niche? People are probably going to yell at me for this, but I think it's improved ability to reason about the algorithm. It is unclear to me that an idea that's useful in one of these niches should automatically be assumed to be useful in another. Sure, if you're used to one niche, and you try to cross over to another, you miss things, but that doesn't mean that having it would be a net win in the other niche.
- couchand 10y ago
  I have a hard time imagining Go really reaching the niche you've described such that it has a chance at satisfying it. Million line codebases don't appear out of nowhere: the language has to be useful and natural enough that developers want to continue working on a project in it until it reaches that size. That being said, plenty about Go seems to make it easier to get there: the lack of reasonable tools for abstraction certainly makes copy-paste programming much more likely, along with the ensuing explosion in LOC.
- setr 10y ago
  >It is unclear to me that an idea that's useful in one of these niches should automatically be assumed to be useful in another. Yes, but you originally asked us to do the opposite: to not modify a language based on the benefits shown in a different language; That an idea useful in one niche should automatically not be assumed to be useful in another. Which of course is just as baseless as automatically assuming it will be (useful|viable|worth the effort). Haskell is particularly irratating to see used for that opinion as well, given that is notable for being a research language; a language who at least partially exists to seek out, identify and implement ideas that can be transplanted into other languages, though of course it would naturally take a different shape once integrated.
  - AnimalMuppet 10y ago
    > Yes, but you originally asked us to do the opposite: to not modify a language based on the benefits shown in a different language Not quite. I asked you not to try to turn one language into another (that occupies a different niche). We don't need Go to become Rust, because we already have Rust. If Go becomes a better Go by stealing ideas from Rust, that's good. If Go becomes a worse Go by trying to become more of a Rust, that's a net loss. Haskell... I admit that I was not thinking of it as a research language, where the whole point is to try out ideas. It's become more than that. It's become a "real" (production) language, not just a research language. But I will grant that it (partially) exists to experiment with ideas and export them.
- kiriakasis 10y ago
  Some language opt for independently compilable module though

by setr 10y ago

>every language is unique >every language is equivalently powerful >therefore, we should neither look to one language to improve another We seem to have made a mistake somewhere.

AnimalMuppet 10y ago

We didn't do any such thing. You seem to think that I did, based on putting words in my mouth that I never said, nor intended. Your response is therefore a strawman. Let's try again, shall we? Some languages are trying to serve different niches than other languages. Trying to copy features from one language to another can be useful. But if you're copying from a language that's used for a different niche, you can ruin the destination language's suitability for its own niche. What's Go's niche? The original intent was that it be useful for multi-million-line code bases that lived for multiple decades. Cost of compile time becomes a very big deal in that environment. (The original motivator was a 45-minute C++ compile. Multiply that times multiple developers, times multiple compiles per day, times 20 years, and it adds up to real money.) What's Rust's niche? It's lower-level (C++-ish) code with compiler-enforced safety. What's Haskell's niche? People are probably going to yell at me for this, but I think it's improved ability to reason about the algorithm. It is unclear to me that an idea that's useful in one of these niches should automatically be assumed to be useful in another. Sure, if you're used to one niche, and you try to cross over to another, you miss things, but that doesn't mean that having it would be a net win in the other niche.

couchand 10y ago
I have a hard time imagining Go really reaching the niche you've described such that it has a chance at satisfying it. Million line codebases don't appear out of nowhere: the language has to be useful and natural enough that developers want to continue working on a project in it until it reaches that size. That being said, plenty about Go seems to make it easier to get there: the lack of reasonable tools for abstraction certainly makes copy-paste programming much more likely, along with the ensuing explosion in LOC.
setr 10y ago
>It is unclear to me that an idea that's useful in one of these niches should automatically be assumed to be useful in another. Yes, but you originally asked us to do the opposite: to not modify a language based on the benefits shown in a different language; That an idea useful in one niche should automatically not be assumed to be useful in another. Which of course is just as baseless as automatically assuming it will be (useful|viable|worth the effort). Haskell is particularly irratating to see used for that opinion as well, given that is notable for being a research language; a language who at least partially exists to seek out, identify and implement ideas that can be transplanted into other languages, though of course it would naturally take a different shape once integrated.
- AnimalMuppet 10y ago
  > Yes, but you originally asked us to do the opposite: to not modify a language based on the benefits shown in a different language Not quite. I asked you not to try to turn one language into another (that occupies a different niche). We don't need Go to become Rust, because we already have Rust. If Go becomes a better Go by stealing ideas from Rust, that's good. If Go becomes a worse Go by trying to become more of a Rust, that's a net loss. Haskell... I admit that I was not thinking of it as a research language, where the whole point is to try out ideas. It's become more than that. It's become a "real" (production) language, not just a research language. But I will grant that it (partially) exists to experiment with ideas and export them.
kiriakasis 10y ago
Some language opt for independently compilable module though