4 ms·

I don't like this statement at all, sorry. It's a very anti-intellectual statement. Are any concepts that are difficult to grasp inherently worth less? That wou

by krig 15y ago

I don't like this statement at all, sorry. It's a very anti-intellectual statement. Are any concepts that are difficult to grasp inherently worth less? That would make all of logic and math bad. Logic is not inherently easy for humans. We are a very emotional and irrational bunch. I don't agree that technologies are bad just because they are difficult to master. The learning curve is utterly irrelevant to their inherent value. There are lots of things that are both incredibly difficult and amazingly valuable. I also think this statement betrays an incredible short-sightedness. You are looking at the technology you know and think "Wow! This is so simple! Why aren't those things I don't know this simple?" Your technology appears simple to you primarily because it is yours. That's not a relativistic statement to imply that all technology is equally difficult to learn, it's just how our perspective shifts as we internalize new concepts. To me, C++ is a lot simpler than Go. I've tried to grasp how to use things like interfaces and channels in Go, but I haven't quite figured it out yet. C++, on the other hand, has been my primary tool for over two decades. The things that appear unreasonably complex to you make sense to me because I am familiar with the reasons they are there. Does that mean that Go is difficult and C++ is simple? Of course not. To someone who doesn't know a thing about programming, they are both absolutely arcane. Even the concept of variables is fundamentally difficult for people to grasp. It's an entirely abstract concept, and abstraction is not easy. A better measure for the utility of the technology would be to ask how well it solves the problems it is intended for. Empirically, it would seem that C and C++ are both the best tools available for different sets of problems. Go is new, but I don't see it being adopted anywhere outside Google yet. I've looked at it, and while it has some attractive traits, it is fundamentally shaped by a different set of priorities than my own. I just don't find the problems it claims to solve all that problematic.

DannoHung 15y ago
I think there is a distinction to be made: While there is value in grasping things that are complicated or hard to understand, there is little value in designing something that is intentionally complicated or hard to understand. In a certain sense, the problem that a tool maps to must reflect the inherent nature of what it works upon, but the designer of the tool should always intend to make the tool a map more fit for human use. Many of the things Gerrand cites were not created full form with the problems and uses clearly understood. This led to iteration and backwards compatibility, which introduced complications because now there were many ways to do things and not all suited for each other. I don't think his argument is that everything should be simple, but that the design should not feel iterative and piled upon. Instead it should reflect a consistency of vision for a problem and its solution. If I may offer an example: In Haskell, the Prelude defines many types and functions which are imported into all modules (sort of similar to namespaces). Many of these functions have commonly understood names but only apply to certain data types. Within the extended set of libraries available in Haskell, there are many other implementations of these functions in terms of more general data types. The types represented are not simple, really, though they are limited and isolated in purpose. Ideally, if one could go back and rewrite history, these more general functions and data types would be the ones exposed by the Prelude. Instead, the Prelude provides an earlier and less consistent view of common functions and datatypes, while the more consistent view is somewhat obscured inside of a number of neatly organized libraries. Both the Prelude and the hierarchy of libraries seek to solve the solution of common tools for working with data and functions, but one has a more clear cut and comprehensible perspective while the other has an older, less consistent view.
- krig 15y ago
  I agree with you to a point, but I think this is also an issue that is more complicated than it may seem at first glance. A lot of the time, the older, more complex version had some initial design that solved a particular problem but didn't fully consider some alternative use cases. A redesign might capture these other use cases, but inevitably the evolution of a library also contains a lot of tweaks and fixes for smaller but not insignificant cases that are easily lost in the redesign. Often the new technology appears cleaner at first but then grows more complex as it starts getting used and those corner cases and missing bits accumulate, or it may actually have lost some functionality that seemed arcane to the redesigners but was actually a desired feature by some set of users. A problem is rarely as simple as it may appear before it is actually deployed and used.
jbarham 15y ago
> Go is new, but I don't see it being adopted anywhere outside Google yet. 1. http://blog.golang.org/2011/04/go-at-heroku.html http://blog.golang.org/2011/04/go-at-heroku.html 2. http://blog.golang.org/2011/12/building-stathat-with-go.html http://blog.golang.org/2011/12/building-stathat-with-go.html 3. http://www.3dfuture.com.au/2011/12/interview-with-the-tinkercad-developers/ http://www.3dfuture.com.au/2011/12/interview-with-the-tinker...
- krig 15y ago
  Heroku is a meta-adoption, not actual use. How much is it actually being used by the users of Heroku? The other two examples are companies I've never heard of. Of course my statement is hyperbole; I'm sure there are people who use Go, and I didn't intend to hate on Go: I do think it's an interesting language that I am trying to learn. I'm just saying that I haven't seen it in use, and that perhaps the simplicity that its authors are touting lies mostly in their own familiarity with it. Go contains a lot of new and unfamiliar concepts, and it's not trivial to figure out how to best solve a problem using it. But remember that the whole point of my argument is that I don't consider simplicity an interesting criterion for the value of a technology - I can think Go is complex and interesting at the same time. edit: Relevant information regarding the above examples, from the linked page about Tinkercad: "I also used to work on the Go team at Google so I had used it in production before."
  - enneff 15y ago
    > Heroku is a meta-adoption, not actual use. How much is it actually being used by the users of Heroku? A huge part of their billing system is written in Go. > I'm just saying that I haven't seen it in use, and that perhaps the simplicity that its authors are touting lies mostly in their own familiarity with it. The creators are also expert C and C++ programmers, and have also designed several other languages. Go was born out of frustration with the thorns, inconsistencies, and surprises that plague a lot of languages. My personal experience is with JavaScript - I wrote JS code every day for several years, and still regularly had to use the console to test essential elements of the language, often with surprising results. We've tried to fix that with Go. Its features are designed to be simple in isolation and predictable when combined. This is the crux of my Google+ post. Our tools should be clean and consistent, so we can spend more time thinking about what we're building, not how the tool might explode if we hold it in the wrong way.
kabdib 15y ago
I look at web development, and a lot of it seems to be tailchasing on the order of "We had to write a framework to get around a bunch of issues with the frameworks we had to work with." And it's turtles all the way down, at least until you get to the OS layers (which, after all, have linear decades of experience behind their design). I can understand this kind of stuff in a young technology, and indeed things are getting better as people seem to be realizing that architecture astronaut crap like WSDL / JavaBeans / et al did active _damage_ to the industry. (We end-ran OSI with stuff that _worked_, with the exception of X.509 -- ughhh -- and a few other things). I love hard problems that are inherently hard. I hate "hard" problems that are only there because of a bunch of poor technical decisions (I remember looking at SOAP and getting physically ill). So much of working with computers is working out ways not to hurt yourself. If there is any "fu" to be learned, it's the ability to look beyond a technology's implementation and into how people will actually interact with it on a daily basis. Make things work well, end to end, over the whole stack. That's what I try to do these days, and I'm a lot happier.
enneff 15y ago
> I also think this statement betrays an incredible short-sightedness. You are looking at the technology you know and think "Wow! This is so simple! Why aren't those things I don't know this simple?" Your technology appears simple to you primarily because it is yours. That's not a relativistic statement to imply that all technology is equally difficult to learn, it's just how our perspective shifts as we internalize new concepts You are implying that I'm not familiar with other technologies. On the contrary, before I learned Go I was intimately familiar with several other languages. If I hadn't, I wouldn't have any basis to compare or criticize them. > To me, C++ is a lot simpler than Go. I've tried to grasp how to use things like interfaces and channels in Go, but I haven't quite figured it out yet. I think the difference between C++ and Go is that you'll understand Go in its entirety within a year, whereas it took you a decade to get there with C++.
- krig 15y ago
  See, I just don't agree with you that the difficulty of learning is indicative of the relative value of the two languages. Yes, C++ is very difficult to learn and I'm sure Go is less so (I have a hard time imagining a language more complex than C++). At the same time, I'm not yet convinced that Go is unequivocally better than C++ at the problems C++ solve. The decade it takes to learn C++ doesn't tell you anything about the value of C++, only that it is more complex. The question is why that is. The backwards compatibility with C is often cited as a prime reason for the inherent complexity of C++, yet that is the very thing that makes C++ "better" for many people.

by krig 15y ago

DannoHung 15y ago

I think there is a distinction to be made: While there is value in grasping things that are complicated or hard to understand, there is little value in designing something that is intentionally complicated or hard to understand. In a certain sense, the problem that a tool maps to must reflect the inherent nature of what it works upon, but the designer of the tool should always intend to make the tool a map more fit for human use. Many of the things Gerrand cites were not created full form with the problems and uses clearly understood. This led to iteration and backwards compatibility, which introduced complications because now there were many ways to do things and not all suited for each other. I don't think his argument is that everything should be simple, but that the design should not feel iterative and piled upon. Instead it should reflect a consistency of vision for a problem and its solution. If I may offer an example: In Haskell, the Prelude defines many types and functions which are imported into all modules (sort of similar to namespaces). Many of these functions have commonly understood names but only apply to certain data types. Within the extended set of libraries available in Haskell, there are many other implementations of these functions in terms of more general data types. The types represented are not simple, really, though they are limited and isolated in purpose. Ideally, if one could go back and rewrite history, these more general functions and data types would be the ones exposed by the Prelude. Instead, the Prelude provides an earlier and less consistent view of common functions and datatypes, while the more consistent view is somewhat obscured inside of a number of neatly organized libraries. Both the Prelude and the hierarchy of libraries seek to solve the solution of common tools for working with data and functions, but one has a more clear cut and comprehensible perspective while the other has an older, less consistent view.

krig 15y ago
I agree with you to a point, but I think this is also an issue that is more complicated than it may seem at first glance. A lot of the time, the older, more complex version had some initial design that solved a particular problem but didn't fully consider some alternative use cases. A redesign might capture these other use cases, but inevitably the evolution of a library also contains a lot of tweaks and fixes for smaller but not insignificant cases that are easily lost in the redesign. Often the new technology appears cleaner at first but then grows more complex as it starts getting used and those corner cases and missing bits accumulate, or it may actually have lost some functionality that seemed arcane to the redesigners but was actually a desired feature by some set of users. A problem is rarely as simple as it may appear before it is actually deployed and used.

jbarham 15y ago

> Go is new, but I don't see it being adopted anywhere outside Google yet. 1. http://blog.golang.org/2011/04/go-at-heroku.html http://blog.golang.org/2011/04/go-at-heroku.html 2. http://blog.golang.org/2011/12/building-stathat-with-go.html http://blog.golang.org/2011/12/building-stathat-with-go.html 3. http://www.3dfuture.com.au/2011/12/interview-with-the-tinkercad-developers/ http://www.3dfuture.com.au/2011/12/interview-with-the-tinker...

krig 15y ago
Heroku is a meta-adoption, not actual use. How much is it actually being used by the users of Heroku? The other two examples are companies I've never heard of. Of course my statement is hyperbole; I'm sure there are people who use Go, and I didn't intend to hate on Go: I do think it's an interesting language that I am trying to learn. I'm just saying that I haven't seen it in use, and that perhaps the simplicity that its authors are touting lies mostly in their own familiarity with it. Go contains a lot of new and unfamiliar concepts, and it's not trivial to figure out how to best solve a problem using it. But remember that the whole point of my argument is that I don't consider simplicity an interesting criterion for the value of a technology - I can think Go is complex and interesting at the same time. edit: Relevant information regarding the above examples, from the linked page about Tinkercad: "I also used to work on the Go team at Google so I had used it in production before."
- enneff 15y ago
  > Heroku is a meta-adoption, not actual use. How much is it actually being used by the users of Heroku? A huge part of their billing system is written in Go. > I'm just saying that I haven't seen it in use, and that perhaps the simplicity that its authors are touting lies mostly in their own familiarity with it. The creators are also expert C and C++ programmers, and have also designed several other languages. Go was born out of frustration with the thorns, inconsistencies, and surprises that plague a lot of languages. My personal experience is with JavaScript - I wrote JS code every day for several years, and still regularly had to use the console to test essential elements of the language, often with surprising results. We've tried to fix that with Go. Its features are designed to be simple in isolation and predictable when combined. This is the crux of my Google+ post. Our tools should be clean and consistent, so we can spend more time thinking about what we're building, not how the tool might explode if we hold it in the wrong way.

kabdib 15y ago

I look at web development, and a lot of it seems to be tailchasing on the order of "We had to write a framework to get around a bunch of issues with the frameworks we had to work with." And it's turtles all the way down, at least until you get to the OS layers (which, after all, have linear decades of experience behind their design). I can understand this kind of stuff in a young technology, and indeed things are getting better as people seem to be realizing that architecture astronaut crap like WSDL / JavaBeans / et al did active _damage_ to the industry. (We end-ran OSI with stuff that _worked_, with the exception of X.509 -- ughhh -- and a few other things). I love hard problems that are inherently hard. I hate "hard" problems that are only there because of a bunch of poor technical decisions (I remember looking at SOAP and getting physically ill). So much of working with computers is working out ways not to hurt yourself. If there is any "fu" to be learned, it's the ability to look beyond a technology's implementation and into how people will actually interact with it on a daily basis. Make things work well, end to end, over the whole stack. That's what I try to do these days, and I'm a lot happier.

enneff 15y ago

> I also think this statement betrays an incredible short-sightedness. You are looking at the technology you know and think "Wow! This is so simple! Why aren't those things I don't know this simple?" Your technology appears simple to you primarily because it is yours. That's not a relativistic statement to imply that all technology is equally difficult to learn, it's just how our perspective shifts as we internalize new concepts You are implying that I'm not familiar with other technologies. On the contrary, before I learned Go I was intimately familiar with several other languages. If I hadn't, I wouldn't have any basis to compare or criticize them. > To me, C++ is a lot simpler than Go. I've tried to grasp how to use things like interfaces and channels in Go, but I haven't quite figured it out yet. I think the difference between C++ and Go is that you'll understand Go in its entirety within a year, whereas it took you a decade to get there with C++.

krig 15y ago
See, I just don't agree with you that the difficulty of learning is indicative of the relative value of the two languages. Yes, C++ is very difficult to learn and I'm sure Go is less so (I have a hard time imagining a language more complex than C++). At the same time, I'm not yet convinced that Go is unequivocally better than C++ at the problems C++ solve. The decade it takes to learn C++ doesn't tell you anything about the value of C++, only that it is more complex. The question is why that is. The backwards compatibility with C is often cited as a prime reason for the inherent complexity of C++, yet that is the very thing that makes C++ "better" for many people.