Hacker News Reader

Comment by martincmartin | Hacker News Reader

Many domains are inherently complex. If your programming language is simple, then the complexity will be in the code. Think Java's boilerplate, or having to re-implement hash tables every time in C because you can't abstract over data types.

In a wood shop, you can do everything with a hammer and chisel. You can make a table leg with them. It'll take a long time and won't be super round. However, having a lathe makes it much faster and gives you a better end result.

Also, it's been said that design patterns are just ways around missing language features. What one person considers language complexity, another seems as an essential abstraction.

View on HN

I think Go had a great observation that reading complexity != writing complexity for a language, and that many features which make writing coffee easier make the language harder to read.

Go also made the fantastic decision to design in concurrency as a primitive... And then kinda for on the hill of generics. There's a lot to be said for choosing the right set of features, keeping the code readable as a first priority, and letting libraries handle the rest... Need a lathe? Import lathe!

It's probably not your cup of tea but I cannot resist reminding you about that coffee language and its "decision to design in concurrency as a primitive". How about Object::wait(), Object::notifyAll(), the "synchronized" keyword, every Object a monitor?

> There's a lot to be said for ...

There's nothing to add for what its creators stated: Go is meant for under-average programmers, not for professional software developers.

You, software developer, are tasked with building a complex distributed system. Do you pick a high complexity language to build your high complexity system, or do you opt for a low complexity language do you can focus on the system?

It depends on what benefits those language features have. More often than not, they do not provide benefit to your business.

Plenty of professional systems are built in Go. This opinion that Go developers are subpar is silly rhetoric. It is not meant for everything, but for distributed systems it is great.

> This opinion that Go developers are subpar is silly rhetoric.

I don't think so. But it's a fact that Go was meant for sub-par programmers.

That really isn’t a fact. It was created to be easy to learn such that junior software engineers or people coming from other languages could get to writing effective code in a short period of time. Neither of those groups are sub-par.

That looks like a citation needed situation.

Seeing the kind of usage go is known to have inside Google, and how is generally accepted that Google hires only the best engineers, this fails to be consistent. I doubt it very much that anyone involved in Go development has said anything that can be interpreted anywhere close to what you said.

https://news.ycombinator.com/item?id=16143918

Haha, thank you. However it's weird that a request for citation is met with a negative score especially since it's not really obvious how Rob Pike's quote is referring to "under average developers". :)

Also, to continue being pedantic I must say that by definition every programmer that gets paid for their work is a "professional software developer" despite the hyperboles grandparent seems to be fond of.

The smartest people have the best means to outsmart themselves. The bigger they are the harder they fall.

> Many domains are inherently complex. If your programming language is simple, then the complexity will be in the code.

I think this is equivalent to the "spherical cow" problem in physics. A lot of calculations in physics are much simpler, if you assume everything is a spherical cow. However, the real world is messy, and not everything is a spherical cow.

In programming, a lot of complexity comes from interfacing to the real world. Whether it is CPU performance/memory hierarchy, or messy business logic.

The drive for simplicity, often ends up sweeping these under the rug.

pretty well put.

it is an optimization problem, and the optimum isn't at the extremum of the constraints, it is somewhere in the middle.

just because C++ is a bit of a mess after 37 years of evolution doesn't mean that the simplest language is best.

rust is also the first widely used language with a borrow checker and may suffer from having to discover the correct primitives while hunting around in the dark to begin with.

> rust is also the first widely used language with a borrow checker and may suffer from having to discover the correct primitives while hunting around in the dark to begin with.

Rust is the first widely used language that addresses the question, how do you have memory safety without garbage collection and loss of efficiency. It comes up with (IMO) a very good answer, but likely not the final answer to this question.

But I think trying to answer that question, more than justifies the complexity.

...and all the expressive syntax in the world just leaves the pointy-eared, spike-tailed, non-spherical cows, poking out all over the place.

I pretty much agree with everything you said, and think it's a good analogy, but eventually come back to the point of the article we're responding to, which is that a lot of the complicated syntax, and features that languages introduce, just ends up non-essential complexity around the inherent complexity of the real world, that you're highlighting.

IMHO, languages should aim to be minimal, simple constructs, that provide powerful, well thought out building blocks to solve your problem.

Most of the complexity should be in the libraries. Only a small set of select people can modify the core language. Anyone can make a library.

You basically described Lisp.

Or indeed C.

There is a difference between a simple language and a small language - sometimes they are the same thing, in other cases the language is small but not necessarily simple.

The C language is a relatively small language, but has been used to write complex databases and operating systems. So is C simple or complex? Or both? (Everyone has a different opinion).

Also, there's also a distinction from the small language core (the syntax and lanuage features) and the much bigger standard library that provides additional functionality.

Sorry, but I have a hard time believing the common trope that something silly like more language complexity will significantly help keeping the complexity of the code down. Personally, I believe it is often the opposite.

So you can't abstract over data types in C? I often do. Some random thing I often do:

    void linear_allocate(Linear_Allocator *alloc, size_t size, size_t align, size_t count);
    
    #define linear_allocate_type(alloc, type, count) ((type *) (linear_allocate((alloc), sizeof (type), alignof (type), (count))))

(Anybody objecting they don't like macros and this is not a real abstraction: You are all fools. To a certain point, that is - before you possibly start being right. But don't underestimate how far this can go, and how long this can be a superior solution over alternatives.)

You know something that is very hard to abstract over? Programming language FEATURES! Anybody, please show me the ways of doing computation over all the data that was encoded as fancy programming language syntax. This requires even more language features to get this data back from the compiler in some weird form... if possible at all.

> Anybody, please show me the ways of doing computation over all the data that was encoded as fancy programming language syntax. This requires even more language features to get this data back from the compiler in some weird form... if possible at all.

Happily! https://lisp-lang.org/

So you show me (or do not show me, instead you just link a website) your ways of retrieving the data encoded by fancy syntax, using a language that has literally almost no syntax at all?

Exactly! The extremely simple syntax of a lisp is what enables similarly extreme syntactic consistency. That consistency, in turn, is what enables lisps' uniquely powerful treatment of code as data, so that programmers can access and transform what would be represented in other languages as "syntactic constructs" and "data values" in a uniform (and, in my opinion, quite nice and expressive) way.

At risk of stereotyping myself, if you like this kind of thing, check out SICP. It is a really good dive into exactly how far you can go with this kind of tool, and also has applicability across the engineering discipline (not just for lisp folks).

I've read through most of SICP, but I never found what's so great about it. Maybe it is that you can apply this argument to any other language as well: Represent your theoretical model as data structures that you control, instead of giving up control to the compiler.

Representing code as data is not very interesting IMO. Code is code, data is data. Granted both are stored in RAM, but they are very different beasts considering how they flow through the machine. Almost any language allows to parameterize over functions (e.g. function pointers), but there is no need to make closures a first class citizen. After all, closures are a brutal abstraction, isolating any context from the caller. When overdone this ends up in a terrible mess where you don't know what's happening anymore (otherwise known as callback hell). Conclusion, use this only as a last resort.

> If your programming language is simple, then the complexity will be in the code

I think there are two different definitions of simple in programming languages: simple to implement and simple to use. Simple to use programming languages can be quite complex under the hood. Python’s bigints are an example of a relatively complex to implement feature that simplifies life for developers.

Whether language features and restrictions simplify life for developers depends on what programs they want to write, though. If you want to emulate wrap-around 32-bit unsigned integers, for example, that’s harder in python than in C.

So, whether a language is simple to use will depend on what programs developers want to write in it. Consequently, language designers should know their audience when designing a language.

> If your programming language is simple, then the complexity will be in the code.

You can have a conceptually simple language, but include a massive standard library with everything most users would need.

Reply on news.ycombinator.com