5 ms·

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 r

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.

sdenton4 4y ago
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!
- pif 4y ago
  > 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.
  - fsociety 4y ago
    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.
    - pif 4y ago
      > 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.
      - orbz 4y ago
        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.
  - mariusor 4y ago
    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.
    - billyjobob 4y ago
      https://news.ycombinator.com/item?id=16143918 https://news.ycombinator.com/item?id=16143918
      - deleted 4y ago
        [deleted]
      - mariusor 4y ago
        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.
  - mftb 4y ago
    The smartest people have the best means to outsmart themselves. The bigger they are the harder they fall.
- 62951413 4y ago
  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?
hazelnut-tree 4y ago
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.
RcouF1uZ4gsC 4y ago
> 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.
- lamontcg 4y ago
  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.
  - RcouF1uZ4gsC 4y ago
    > 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.
- mftb 4y ago
  ...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.
jstimpfle 4y ago
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.
- zbentley 4y ago
  > 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/ https://lisp-lang.org/
  - jstimpfle 4y ago
    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?
    - zbentley 4y ago
      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).
bcrosby95 4y ago
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.
- marcofiset 4y ago
  You basically described Lisp.
  - Gordonjcp 4y ago
    Or indeed C.
hgs3 4y ago
> 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.
Someone 4y ago
> 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.

sdenton4 4y ago

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!

pif 4y ago
> 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.
- fsociety 4y ago
  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.
  - pif 4y ago
    > 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.
    - orbz 4y ago
      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.
- mariusor 4y ago
  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.
  - billyjobob 4y ago
    https://news.ycombinator.com/item?id=16143918 https://news.ycombinator.com/item?id=16143918
    - deleted 4y ago
      [deleted]
    - mariusor 4y ago
      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.
- mftb 4y ago
  The smartest people have the best means to outsmart themselves. The bigger they are the harder they fall.
62951413 4y ago
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?

hazelnut-tree 4y ago

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.

RcouF1uZ4gsC 4y ago

> 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.

lamontcg 4y ago
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.
- RcouF1uZ4gsC 4y ago
  > 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.
mftb 4y ago
...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.

jstimpfle 4y ago

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.

zbentley 4y ago
> 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/ https://lisp-lang.org/
- jstimpfle 4y ago
  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?
  - zbentley 4y ago
    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).

bcrosby95 4y ago

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.

marcofiset 4y ago
You basically described Lisp.
- Gordonjcp 4y ago
  Or indeed C.

hgs3 4y ago

> 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.

Someone 4y ago

> 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.