7 ms·

The "easy to learn" argument is getting old. If the cognitive load never decreases, that's one thing, but initial ramp-up time shouldn't be a large determining

The "easy to learn" argument is getting old. If the cognitive load never decreases, that's one thing, but initial ramp-up time shouldn't be a large determining factor. The MVC pattern, ADTs, functional programming, and so many other useful concepts were foreign at first, but have a substantial impact on how you think and work. With the exception of channels, Go doesn't add much when compared to other languages. Maybe that's a pragmatic choice, but it feels short-sighted to me.

webscalist 9y ago
Huge success of mongodb was due to "easy to learn" advertisement, paired with getting shit done and rewrite later agile trend, and web scale.
- eeZah7Ux 9y ago
  Is this a positive or negative example?
emperorcezar 9y ago
Sadly our entire industry is based around being short sighted. Quick to learn is only important if you have the lack of patience to spend the time to learn something you'll be using for years.
- holydude 9y ago
  Our industry is hugely based on illusions and misconceptions. There are only few places on earth where people regularly rebuild the skyscrapers to build taller ones. The IT industry simply forces you to re-learn the same old paradigms in a new package just to gain 0.1% of something we cannot even define as an improvement.
  - pjmlp 9y ago
    Quite common in fashion driven industries.
  - jwdunne 9y ago
    One thing I've been looking at lately is the various strands of engineering (civil, electrical, mechanical). I've been looking for common threads and general principles that apply to software engineering that otherwise haven't been. A part of what inspired that search is what you discuss: a huge amount of rework. Tools that shift like sand dunes. Many principles and best practice based on "this is what worked for us". I can't seem to shake the feeling there must be a better way.
    - dasil003 9y ago
      The fundamental difficulty is the blue sky nature of software. You can literally code anything you can imagine. Language semantics, algorithms, architecture, it's all up for grabs, it's all cheap, and the applications are unlimited. Compare with traditional engineering disciplines where you have massively constrained costs, materials, and even goals. What would civil engineering be like if instead of the immutable laws of physics you had a system designed from the tiniest quark up to the largest galaxy by humans, and if that design was subject to change on a whim?
    - cyphar 9y ago
      I think that attempts to unify traditional forms of engineering with software engineering are doomed to failure, because they're so different as vocations. For example, the design and construction stages are indistinguishable (any sufficiently detailed design of software is effectively an implementation of the design). Normal engineering is not the same, and is likely one of the reasons that software prototyping often become the final product (which is definitely not true for traditional engineering). Fields like electrical engineering that use software engineering quite heavily are only similar to traditional engineering because of the traditional components of the other engineering discipline (electrical engineering requires circuit-board design that is distinct from fabrication, and prototypes are rarely promoted directly to the final product).
      - jwdunne 9y ago
        That's true. I don't think that there are major things in those disciplines that are directly applicable in a timeless fashion. My main goal is to find out how these disciplines came about. How exactly did they settle upon their body of knowledge such that they can produce reliable results in the way they do. Not so much what those methods are, but rather how they came about. What is the common thread there and how, if at all possible, can we use that accelerate the same maturity in software? Maybe it's a process that has to run its course? Maybe at 80 years old, if I live that long, I'll look on a very different kind of software development. With that said, I also have Fred Brooks whispering "no silver bullet" into my ear on the other shoulder.
  - eeZah7Ux 9y ago
    This is what I most dislike about Go: it's a modest improvement. It could have been much better, with a higher-level and less verbose syntax and allow metaprogramming (e.g. like Nim).
  - wyager 9y ago
    Architecture is thousands of years old. Programming as we know it is maybe 60. We're still figuring out how to do things correctly. Maybe we just figured out how to build a log cabin, but now some people are going back to mud huts because they're simpler.
grey-area 9y ago
With the exception of channels, Go doesn't add much when compared to other languages. It doesn't add things, it takes them away, notably exceptions, inheritance, generics. I disagree that's short sighted, it's precisely for long term maintenance that it becomes important to have less ways to do things. You may not agree with the choices, but they are not only about being easy to learn, more about being easy to read.
- wasted_intel 9y ago
  People just end up inventing idioms to handle those, anyway. Go's nil-check error handling is a prime example. That's a beautifully solved problem with ADTs, but it's impossible without generic support, for starters. Runtime errors, abound!
  - warent 9y ago
    Go can handle errors in a very deterministic way, and it can easily recover from a weird panicked state. If someone's Go code has "runtime errors abound" then they probably didn't RTFM ;)
    - wasted_intel 9y ago
      Ah, so when I think of deterministic error handling, I think of compile-time enforcement, like that provided by a Result or Option type. Those can be ignored too, though, although the effort to do so is a little bit more explicit. :)
- dozzie 9y ago
  > It doesn't add things, it takes them away, notably exceptions, inheritance, generics. s/exceptions/error handling/ What Go proposes is awful for a modern language.
  - weberc2 9y ago
    Go has error handling, it doesn't have exceptions for non-exceptional error cases.
jernfrost 9y ago
It matters for large teams and when you got hundreds of languages to choose from. I am sure Haskell is great but after a couple of weeks studying it I realize I don't have time for something I don't know if will pay off or not. In contrast with Go you can see benefits almost immediatly
- wasted_intel 9y ago
  Two weeks is a tiny investment to properly evaluate a language. Haskell is tripping you up because you're likely new to proper FP and very strongly typed languages. Pushing past two weeks, even if you don't use it, will make you a better developer, and the next FP or strongly typed language will come more easily.
  - pmoriarty 9y ago
    You probably mean statically typed, not strongly typed. The distinction is clarified in "What To Know Before Debating Type Systems": https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wr...
    - wasted_intel 9y ago
      I didn't, actually! I don't know how else I'd express it, but I'm thinking of Rust, Haskell, etc's "step beyond" plain static typing with sum/ADTs, pattern matching, and exlusion of null. A seemingly small detail, but it does feel like it makes the type system more deterministic and "stronger", in a sense.
Thaxll 9y ago
Lot of new languages try do to everything which is imo a big mistake.

webscalist 9y ago

Huge success of mongodb was due to "easy to learn" advertisement, paired with getting shit done and rewrite later agile trend, and web scale.

eeZah7Ux 9y ago
Is this a positive or negative example?

emperorcezar 9y ago

Sadly our entire industry is based around being short sighted. Quick to learn is only important if you have the lack of patience to spend the time to learn something you'll be using for years.

holydude 9y ago
Our industry is hugely based on illusions and misconceptions. There are only few places on earth where people regularly rebuild the skyscrapers to build taller ones. The IT industry simply forces you to re-learn the same old paradigms in a new package just to gain 0.1% of something we cannot even define as an improvement.
- pjmlp 9y ago
  Quite common in fashion driven industries.
- jwdunne 9y ago
  One thing I've been looking at lately is the various strands of engineering (civil, electrical, mechanical). I've been looking for common threads and general principles that apply to software engineering that otherwise haven't been. A part of what inspired that search is what you discuss: a huge amount of rework. Tools that shift like sand dunes. Many principles and best practice based on "this is what worked for us". I can't seem to shake the feeling there must be a better way.
  - dasil003 9y ago
    The fundamental difficulty is the blue sky nature of software. You can literally code anything you can imagine. Language semantics, algorithms, architecture, it's all up for grabs, it's all cheap, and the applications are unlimited. Compare with traditional engineering disciplines where you have massively constrained costs, materials, and even goals. What would civil engineering be like if instead of the immutable laws of physics you had a system designed from the tiniest quark up to the largest galaxy by humans, and if that design was subject to change on a whim?
  - cyphar 9y ago
    I think that attempts to unify traditional forms of engineering with software engineering are doomed to failure, because they're so different as vocations. For example, the design and construction stages are indistinguishable (any sufficiently detailed design of software is effectively an implementation of the design). Normal engineering is not the same, and is likely one of the reasons that software prototyping often become the final product (which is definitely not true for traditional engineering). Fields like electrical engineering that use software engineering quite heavily are only similar to traditional engineering because of the traditional components of the other engineering discipline (electrical engineering requires circuit-board design that is distinct from fabrication, and prototypes are rarely promoted directly to the final product).
    - jwdunne 9y ago
      That's true. I don't think that there are major things in those disciplines that are directly applicable in a timeless fashion. My main goal is to find out how these disciplines came about. How exactly did they settle upon their body of knowledge such that they can produce reliable results in the way they do. Not so much what those methods are, but rather how they came about. What is the common thread there and how, if at all possible, can we use that accelerate the same maturity in software? Maybe it's a process that has to run its course? Maybe at 80 years old, if I live that long, I'll look on a very different kind of software development. With that said, I also have Fred Brooks whispering "no silver bullet" into my ear on the other shoulder.
- eeZah7Ux 9y ago
  This is what I most dislike about Go: it's a modest improvement. It could have been much better, with a higher-level and less verbose syntax and allow metaprogramming (e.g. like Nim).
- wyager 9y ago
  Architecture is thousands of years old. Programming as we know it is maybe 60. We're still figuring out how to do things correctly. Maybe we just figured out how to build a log cabin, but now some people are going back to mud huts because they're simpler.

grey-area 9y ago

With the exception of channels, Go doesn't add much when compared to other languages. It doesn't add things, it takes them away, notably exceptions, inheritance, generics. I disagree that's short sighted, it's precisely for long term maintenance that it becomes important to have less ways to do things. You may not agree with the choices, but they are not only about being easy to learn, more about being easy to read.

wasted_intel 9y ago
People just end up inventing idioms to handle those, anyway. Go's nil-check error handling is a prime example. That's a beautifully solved problem with ADTs, but it's impossible without generic support, for starters. Runtime errors, abound!
- warent 9y ago
  Go can handle errors in a very deterministic way, and it can easily recover from a weird panicked state. If someone's Go code has "runtime errors abound" then they probably didn't RTFM ;)
  - wasted_intel 9y ago
    Ah, so when I think of deterministic error handling, I think of compile-time enforcement, like that provided by a Result or Option type. Those can be ignored too, though, although the effort to do so is a little bit more explicit. :)
dozzie 9y ago
> It doesn't add things, it takes them away, notably exceptions, inheritance, generics. s/exceptions/error handling/ What Go proposes is awful for a modern language.
- weberc2 9y ago
  Go has error handling, it doesn't have exceptions for non-exceptional error cases.

jernfrost 9y ago

It matters for large teams and when you got hundreds of languages to choose from. I am sure Haskell is great but after a couple of weeks studying it I realize I don't have time for something I don't know if will pay off or not. In contrast with Go you can see benefits almost immediatly

wasted_intel 9y ago
Two weeks is a tiny investment to properly evaluate a language. Haskell is tripping you up because you're likely new to proper FP and very strongly typed languages. Pushing past two weeks, even if you don't use it, will make you a better developer, and the next FP or strongly typed language will come more easily.
- pmoriarty 9y ago
  You probably mean statically typed, not strongly typed. The distinction is clarified in "What To Know Before Debating Type Systems": https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wr...
  - wasted_intel 9y ago
    I didn't, actually! I don't know how else I'd express it, but I'm thinking of Rust, Haskell, etc's "step beyond" plain static typing with sum/ADTs, pattern matching, and exlusion of null. A seemingly small detail, but it does feel like it makes the type system more deterministic and "stronger", in a sense.

Thaxll 9y ago

Lot of new languages try do to everything which is imo a big mistake.