7 ms·

"Every computer language is an imperfect way of describing a potential solution to a poorly understood problem" -- Me I find it interesting when people wax po

by kator 12y ago

"Every computer language is an imperfect way of describing a potential solution to a poorly understood problem" -- Me I find it interesting when people wax poetic about how one language is better than another and how if we just did x, y or z then we'd have this perfect solution. That said I appreciate the author's write-up of some challenges with Go. In the end the reality of any "product" is building what the user's need not what they ask for. That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go. Worse yet it may calcify the Go development team in a way that will keep them from addressing the basic issues that generics might help solve. Either way Go is just another computer language and I'm happy to use it often to solve problems I'm working on. That said I use a lot of computer languages every week when I'm working on stuff, none of them are perfect and my solutions to the underlying problems are fragile and constantly evolving as the problems unfold. This is the nature of our business, to constantly do battle with poorly understood problems using imperfect tools in a world where we are fooled into thinking everything is black and white because at the core of our technology everything is a 0 or a 1. "One Computer Language to bring them all and in the darkness bind them".. LOL

nine_k 12y ago
> my solutions to the underlying problems are fragile ... This is the nature of our business I think this is a mistake. A lot of business is run this way, though.
dons 12y ago
Languages may not be perfect, but language features can be compared, and some features are strictly more powerful than others. There is scope for legitimate criticism of language design based on the expressive power^1 of their features. In this case, generics would make Go strictly more expressive, as, without it you must write O(n) more code or perform a global refactoring to simulate it. 1. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...
- skybrian 12y ago
  You can compare language features this way, but it won't tell you which language is a better fit for a particular problem. JSON is strictly less powerful than JavaScript and it's easy to come up with examples of data that can be better compressed in JavaScript. But for what we use JSON for, not being Turing complete is a feature. When programming in an intentionally restricted language, the question is whether the limitation in power is put to good use in some other way.
- skybrian 12y ago
  You can compare language features this way, but it won't tell you which language is a better fit for a particular problem. JSON is strictly less powerful than JavaScript and it's easy to come up with examples of data that can be better compressed in JavaScript. But for what we use JSON for, not being Turing complete is a feature. When programming in an intentionally restricted language, the question is whether the limitation in power is put to good use in some other way.
aikah 12y ago
> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive. Or why expose this interface {} feature and allow people to use it in a statically typed language? People who chose Go obviously want type checking (along with CSP that makes go so awesome), or they would be using something else.
- mrweasel 12y ago
  Are generics really that important? Java didn't have generics for 9 or 10 years, C# only got them in version 2. C still doesn't have generics and I never heard anyone complain. As a former C# developer I would agree that life got easier with the introduction of generics, but you can develop the exact same software with and without generics.
  - kasey_junk 12y ago
    You can say the same thing about every language feature there is. Of course it is possible to develop software without some particular feature, it's whether the benefits of the feature out way it's costs. With generics, most of the world has decided to land on the side of wanting them. Even golang has them, just not for users.
  - TazeTSchnitzel 12y ago
    Java would be a lot nicer to work with had it had generics from the beginning.
    - protomyth 12y ago
      That's one of the big problems with adding major features later, the standard libraries don't get rewritten to fully use the new feature.
      - 12y ago
spion 12y ago
> This is the nature of our business, to constantly do battle with poorly understood problems using imperfect tools in a world where we are fooled into thinking everything is black and white because at the core of our technology everything is a 0 or a 1. Isn't that extremely sad though? We finally have a perfectly precise tool, yet we keep building gooey piles of uncertainty on top of it. Sure we're just imperfect humans, but that is what compilers and tooling are for - to point out our mistakes and help us get it right I'm hoping that in the next 5-20 years Rust and Haskell (and later Idris) will change everything.
- blowski 12y ago
  > I'm hoping that in the next 5-20 years Rust and Haskell (and later Idris) will change everything. Unfortunately, they won't. These problems are not a 'bug' of current languages, but the inherent nature of the problem. At some point, the perfectly precise world of computers has to meet the messy world of user requirements. As a programmer, my job is to translate one into the other, within the constraints applied by whoever is paying the bill.
  - spion 12y ago
    Well right now the messy world of user requirements meets the even messier world of legacy languages and poorly behaving libraries. I'm not under any illusions that the first part would change; my hope only pertains to the second part. For example, the behaviour of null/nil references in most typed languages mentioned in the article has nothing to do the inherent nature of messy user requirements. Same goes for the lack of sum types: infact they're perfect for modelling messy requirements, much better than simulating them with structs and forgetting a check somewhere (I'm just parroting the article here) These issues aren't caused by messy requirements but by messy leftovers from legacy languages. Thats fine too, nobody expects us to get it right the first time: but that was 40 years ago and repeating the same mistakes in languages made in 2009 feels really sad.
    - blowski 12y ago
      I half agree. While new programming languages will make solving today's problems easier, there will be new problems that they won't solve, and so in 20 years people will be moaning about the problems the contemporary languages don't solve. For example, one of the biggest problems with building websites ten years ago was that you had to slice everything into tiny images because of table-based layouts. Now we've got CSS3 with SASS and Compass and that's no longer a problem. But whereas then, 90% of users were using IE6 on a 15 or 17 inch monitor, now my users are on a multitude of browsers and screen sizes.
vardump 12y ago
The big thing people miss is that while lack of generics might cost them effort worth X, other Go features benefits them Y. The value of Y is pretty large in case of Go, when it comes to concurrency and language level simplicity. It's hard to go wrong in Go. Whoever designed Go seems to have some experience debugging and maintaining large concurrent systems. When you design a language, you have to be so careful of things you add. Because otherwise you get C++ (or one of those cute let's-add-all-the-features-we-can-think-of scripting languages). In good and in bad. You can't remove features afterwards, so better not add a feature you can't get right from the beginning.
- threeseed 12y ago
  Nobody is saying Go should rush to implement generics or any other feature. The issue is more the dismissive attitude towards them.
  - davecheney 12y ago
    Citation needed please. Ian Lance Taylor, a core member of the Go team has revised and replied to many of the generics debates on go-nuts.

by kator 12y ago

nine_k 12y ago

> my solutions to the underlying problems are fragile ... This is the nature of our business I think this is a mistake. A lot of business is run this way, though.

dons 12y ago

Languages may not be perfect, but language features can be compared, and some features are strictly more powerful than others. There is scope for legitimate criticism of language design based on the expressive power^1 of their features. In this case, generics would make Go strictly more expressive, as, without it you must write O(n) more code or perform a global refactoring to simulate it. 1. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4656 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...

skybrian 12y ago
You can compare language features this way, but it won't tell you which language is a better fit for a particular problem. JSON is strictly less powerful than JavaScript and it's easy to come up with examples of data that can be better compressed in JavaScript. But for what we use JSON for, not being Turing complete is a feature. When programming in an intentionally restricted language, the question is whether the limitation in power is put to good use in some other way.
skybrian 12y ago
You can compare language features this way, but it won't tell you which language is a better fit for a particular problem. JSON is strictly less powerful than JavaScript and it's easy to come up with examples of data that can be better compressed in JavaScript. But for what we use JSON for, not being Turing complete is a feature. When programming in an intentionally restricted language, the question is whether the limitation in power is put to good use in some other way.

aikah 12y ago

> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive. Or why expose this interface {} feature and allow people to use it in a statically typed language? People who chose Go obviously want type checking (along with CSP that makes go so awesome), or they would be using something else.

mrweasel 12y ago
Are generics really that important? Java didn't have generics for 9 or 10 years, C# only got them in version 2. C still doesn't have generics and I never heard anyone complain. As a former C# developer I would agree that life got easier with the introduction of generics, but you can develop the exact same software with and without generics.
- kasey_junk 12y ago
  You can say the same thing about every language feature there is. Of course it is possible to develop software without some particular feature, it's whether the benefits of the feature out way it's costs. With generics, most of the world has decided to land on the side of wanting them. Even golang has them, just not for users.
- TazeTSchnitzel 12y ago
  Java would be a lot nicer to work with had it had generics from the beginning.
  - protomyth 12y ago
    That's one of the big problems with adding major features later, the standard libraries don't get rewritten to fully use the new feature.
    - 12y ago

spion 12y ago

> This is the nature of our business, to constantly do battle with poorly understood problems using imperfect tools in a world where we are fooled into thinking everything is black and white because at the core of our technology everything is a 0 or a 1. Isn't that extremely sad though? We finally have a perfectly precise tool, yet we keep building gooey piles of uncertainty on top of it. Sure we're just imperfect humans, but that is what compilers and tooling are for - to point out our mistakes and help us get it right I'm hoping that in the next 5-20 years Rust and Haskell (and later Idris) will change everything.

blowski 12y ago
> I'm hoping that in the next 5-20 years Rust and Haskell (and later Idris) will change everything. Unfortunately, they won't. These problems are not a 'bug' of current languages, but the inherent nature of the problem. At some point, the perfectly precise world of computers has to meet the messy world of user requirements. As a programmer, my job is to translate one into the other, within the constraints applied by whoever is paying the bill.
- spion 12y ago
  Well right now the messy world of user requirements meets the even messier world of legacy languages and poorly behaving libraries. I'm not under any illusions that the first part would change; my hope only pertains to the second part. For example, the behaviour of null/nil references in most typed languages mentioned in the article has nothing to do the inherent nature of messy user requirements. Same goes for the lack of sum types: infact they're perfect for modelling messy requirements, much better than simulating them with structs and forgetting a check somewhere (I'm just parroting the article here) These issues aren't caused by messy requirements but by messy leftovers from legacy languages. Thats fine too, nobody expects us to get it right the first time: but that was 40 years ago and repeating the same mistakes in languages made in 2009 feels really sad.
  - blowski 12y ago
    I half agree. While new programming languages will make solving today's problems easier, there will be new problems that they won't solve, and so in 20 years people will be moaning about the problems the contemporary languages don't solve. For example, one of the biggest problems with building websites ten years ago was that you had to slice everything into tiny images because of table-based layouts. Now we've got CSS3 with SASS and Compass and that's no longer a problem. But whereas then, 90% of users were using IE6 on a 15 or 17 inch monitor, now my users are on a multitude of browsers and screen sizes.

vardump 12y ago

The big thing people miss is that while lack of generics might cost them effort worth X, other Go features benefits them Y. The value of Y is pretty large in case of Go, when it comes to concurrency and language level simplicity. It's hard to go wrong in Go. Whoever designed Go seems to have some experience debugging and maintaining large concurrent systems. When you design a language, you have to be so careful of things you add. Because otherwise you get C++ (or one of those cute let's-add-all-the-features-we-can-think-of scripting languages). In good and in bad. You can't remove features afterwards, so better not add a feature you can't get right from the beginning.

threeseed 12y ago
Nobody is saying Go should rush to implement generics or any other feature. The issue is more the dismissive attitude towards them.
- davecheney 12y ago
  Citation needed please. Ian Lance Taylor, a core member of the Go team has revised and replied to many of the generics debates on go-nuts.