Hacker News Reader

This is exactly Larry Wall's point when he talks about the "waterbed theory":

https://en.wikipedia.org/wiki/Waterbed_theory

Users don't often have the luxury of discarding essential complexity in the problem their trying to solve. So, if you don't give them the right tools to tackle that in your language, that doesn't mean they no longer need those tools. It just means they have to build them themselves first.

What matters the sum of total complexity: the language spec + adhoc idioms/patterns/conventions/workarounds used in actual codebases.

This is a great one sentence summary of the history of C++. (Would also do for a history of programming.) Any hoary Ruby veteran probably has a story about the misuse of missing_method. (Likely one in which they were the antagonist.) The way that the programming field has shaken out, it turns out that there is a group of programmers who are fine with application programming and using well thought out libraries. However, only a minority of these programmers have the ability to engage in the thinking about other-POV and 2nd/3rd order effects that are needed to make a good library or meta-level tool. (Not to mention the community management skills needed to keep people happy while not giving them absolutely everything they want.) As a relative noob, I was listening to hoary Smalltalk veterans talking about this in the early 2000's. This situation is pretty analogous to the one surrounding crypto, except that the consequences of hubris are somewhat milder.

The lesson learned from history is to talk about about simplicity/complexity in a more holistic way.

Also from the early 2000's -- The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design.

I've been musing about these sorts of issues of "what is really complex" lately, too. I started evaluating new languages for low-level application code again after spending a lot of time overly close to web browsers, and then ended up deciding that Free Pascal beat them on the stuff I cared about, relative to C compilers as a baseline:

* Best-in-class compile times

* Modules; preprocessor is relevant, but not dominant

* Generics, variant records, function and operator overloads, exceptions, safe string and dynamic array types

* Libraries for common things, with a reasonably conventional style: APIs, containers, bindings, etc.

* No GC; pointers are available, but language features discourage casual usage. RAII pattern is achievable.

* Strong + static types, nominal types and type aliasing.

* Good IDE support, mature tooling, compiler has very broad platform support.

The new languages do win on a lot of the language-feature aspects(particularly memory safety when performing deep optimizations), but they don't have as good a story on the tooling. The compile speed is a major feature and is only likely to remain advantageous over time - and the features already in place are quite effective at limiting source code size, boilerplate, and dangerous constructs. This despite "Pascal is verbose" being memetic.

And if I want more high-level power, I've found that writing a FSM is the most probable path to achieving it. A FSM that embraces the problem domain is a tiny compiler: input source constructs, FSM checks them, applies appropriate algorithms, then emits a list of actions. More power? Add a second FSM to make it a two-pass compiler. Add a stack, or attach it to a database. If it has to be fast, it can generate code in the last step, too. Those things add tons of power to model the problem and aren't heavily dependent on language-side support.

Yup, we already had all of that in Turbo Pascal for MS-DOS, hence why I never saw any value in C back in 1993.

On those days outside UNIX, C was just yet another systems language, with most home micros being written mostly in Assembly.

Also Turbo Pascal OOP features were adopted from Apple's Object Pascal, used to write the initial versions of Lisa, Mac OS and known software like Photoshop.

> The Design Patterns guys were often saying that design patterns and other kinds of common incantations were often symptoms of deficiencies in programming language design.

When I reread the GoF book a few years ago, I was struck by the number of patterns that are just built-in to modern languages.

Most of the behavioural patterns are eased by fp techniques like lambdas+currying and adt/pattern matching (visitors are well known losers).

The structural patterns are however much more a pain in fp while they feel natural in oo. Facades and decorators need type hiding that's only nice(r) with existential types.

The creational patterns are a mixed bag. Builder, singleton fit with fp, Abstract Factory fits with oo and factory methods with both.

What do you think? How are the oo patterns improved by other techniques. Though a lot of those patterns are probably for C style oo.

I think the author was actually referring to the fact that it makes the written software using Go more complex to understand and maintain. Quoting: "...efforts to add templated types and immutability to the language would unlock the ability to write more complex, less readable software. Indeed, the addition of these features would have a knock on effect that would profoundly alter the way error handling, collections, and concurrency are implemented."

It's not clear to me how templated types and immutability inevitably lead to more complex and less readable software. Can you or someone else explain?

Well, you've got two choices about how you want usage of user-implemented generic container types to look:

1) there are no parameters on the container types, every usage involves a cast to or from 'void*', 'interface{}', or the equivalent, and usage is effectively not type-checked.

2) there are parameters on the container types, subsequent usage isn't cluttered up with uninformative type-casts, and the types get checked by the compiler.

These lead to the same code at runtime (or can, in a Java-style implementation of generics); however, the Go maintainers seem to act as if the first is more maintainable and less error-prone. That seems ... odd, to some of us.

(There are other possible implementations of generics, of course. In fact, another post by the same author, [1], lists "everything is boxed" as a bad outcome that he'd like to avoid, in favor of specialized implementations for containers of, say, characters. But scenario 1, the Go status quo, effectively requires that everything be boxed when using a generic container type written the only way the language allows you to write them. Scenario 2 at least potentially gives the compiler other options. But the Go status quo doesn't avoid the "everything is boxed" bad outcome. Instead it mandates it -- with additional compile-time clutter.)

[1] https://research.swtch.com/generic

I think it's perhaps a reference to the original intent of Go at Google. They want new joinees to be quickly productive and also be able to write problem free software (and maybe maintain a lot of old software in addition to writing new software). Having more advanced language features is perhaps not conducive to this. Features like templates do take a bit more effort to grok and also take a bit more effort to understand the flow of code when maintaining software.

As a primarily .NET developer, I think I can count on two hands the number of times that I've needed to actually write my own generic types. Generic functions are maybe slightly more common, but still pretty rare.

However, if I had a penny for every time I've taken advantage of the generic collections built into the standard library, instead of using the old shitty, type-unsafe ArrayList or HashTable collections, I wouldn't have to work for the rest of my life.

.Net generics are more limited than full C++ style templates, or maybe I've been lucky enough to never encounter any code where people have gone overboard with them, but that seems to be a pretty sweet spot.

Anecdotally, there seems to be a giant rush to get everything covered in generics when people first start learning them. So, what could have been a short section of code that did its job well, is now a larger portion of code that doesn't quite do what anyone wants and you can find yourself just doing a dance with the generic types.

I do not know of any studies that explore this concept at large. I would be interested in them.

Templates have a very complex semantics, because they are checked at instantiation time and can be specialized anywhere. Fortunately, parametric polymorphism and templates have nothing to do with each other. :-)

But by pushing complexity into third parties, the vast majority can benifit from a smaller spec and less cognitive load. It's a trade off for sure, but I think as a language designer you have to be careful not to let the 1% convince you that the 99% needs x feature. There are tons of existing Go projects that are working just fine as is. How many of them really need more than what exists already?

A formulation of this argument has been used since the 1970s and it keeps being proven wrong over and over as progressively people realize the ML and Common Lisp folks were right. Those features are not bullshit invented to make a mathematician happy, they're features that make code safer, more concise, easier to reason about, and easier for optimizers to turn into performant code.

Why is it that folks keep trying to formulate this as "the egghead 1% vs the sane 99%?" Stuff is constantly flowing out of academia and advanced production labs and our industry re-levels to that. It's the way a growing industry is supposed to work.

Go is not a good language in a technical sense. It's an expression of Google's business needs. Google's got 0 interest in making rank and file programmers better; they're tuned for revolving door recruiting on a massive scale. For them, their goal is to make programmers who only have domain knowledge and require no training. They're not even that interested in lowering shipped error rates; they have a ton of machinery and a whole legion of SRE folks to help manage deployments when testing is minimal and hand-written.

To be clear btw, I am not condemning Google for arriving at this conclusion. Their economics are totally different from everyone else's. Every Big Company(tm) has a unique angle of attack on the training problem. Ironically, google's SRE folks are aggressively in the opposite camp in terms of recruiting and practice because they're the ones who actually have to enable this model of shipping broken code safely.

Everything about Go is designed to maximize what Google wants out of mid-experience programmers. It's so weird how non-google people seem to find this state of affairs good, as they almost certainly cannot afford to do it this way.

> Everything about Go is designed to maximize what Google wants out of mid-range programmers. It's so weird how non-google people seem to find this state of affairs good.

If it let's them build products that serve billions of users in ways that that were completely inconceivable even 30 years ago then maybe it's not such a bad tradeoff. To be clear I'm talking more about the philosophy that produced go, not so much the language itself. Obviously Google is more than go.

Given the features of Go, Google could have used Algol 68 instead, or Active Oberon just to refer something modern, and still make those wonderful products you mention.

Which are still a minority compared with the amount of Google products written in Python, Java, C++ or even Dart.

So, all the products were already conceivable in some 30 year old languages.

As I suggested, it's not inherently bad but it's functioning at a scale that simply isn't replicatable by most orgs.

If you think that approach can work for you in your job and that job is not at once of the top 10 tech find? Write an experience report about how you made it work.

That's his point. It's not a bad tradeoff... for Google. It might be a bad tradeoff for you, if you don't (according to his thesis) have a revolving door of mid-level engineers lacking domain knowledge and/or a large fleet of SREs.

Just an aside, it's slightly opposite from what you said. Google doesn't want software engineering at a larger scale to enter into the world of domain specific folks at all. So they specialize in giving domain specific folks a very tight coupling to the computer without a care in the world for most anything other than a narrow band of parameters.

They very much have an org for generating software that treats domain specialists as pluggable domain optimizers. Architects and SRE all enable that.

How does this only benefit Google? Other businesses can surely benefit from this aspect of Go. Heck if your an aspiring startup that has to hire new people, you gain from this.

Why would this be beneficial unless you're also paying Google to host your software?

Cheney is also speaking to a camp who have argued against generics in Go using various definitions of simplicity and complexity. Rather than getting into the weeds and highlighting differences in opinion about precise definitions Cheney seems to be acknowledging the validity of the positions of the other side _on their own terms_. This is how compromises are built and IMO a good step for the Generics in Go camp.

> It's not important if generics make the "language specification" more complex. What's really more important is if it makes the real-world language usage more complex.

This is what he was talking about when he mentions "more complex, less readable software." On the other hand, he doesn't mention the language specification once.

>This is what he was talking about when he mentions "more complex, less readable software."

You're making a facile argument without realizing it. For example, when you allow the ability to parameterize a thing, it can make the source code a little "less readable" while simultaneously reducing overall cognitive load.

Generics is the ability to parameterize _types_. As comparison, the language feature we are all familiar with is functions which allow us to parameterize _values_. Illustration of abstraction over _values_:

This is more readable (using technique of copy & paste):

  fmt.Println("Hello World")
  fmt.Println("Hello Jane")

The is less readable:

  func greeting(x string) (string) {
    return "Hello " + x
  }

  func main() {
    fmt.Println(greeting("World"))
    fmt.Println(greeting("Jane"))
  }

Programmers may not think the function with passing parameters isn't less readable (because they are used to it) but it actually is. An extra layer of indirection will make the source text somewhat less readable but it's worth it if the net gain in comprehension, maintainability, correctness, etc is improved.

That's what parameterizing values via functions allows: it's simultaneously more complex and also more simple at the same time. It's complex at a superficial level but actually simpler at a deeper level. Programmers have embraced the additional "complexity" of "parameterized values" because it makes the language easier to use. A similar analogy about "parameterizing types" can also be made.

>, he doesn't mention the language specification once.

Yes, if you do Ctrl+F looking for the exact phrase "language specification", you're not going to find it. However, if you understand the meaning of the quotes I pulled, that _is_ what Cheney is actually talking about.

If you're trying to address the topic of simplicity you're being awfully ironic about it.