Go versus Brand X

[Steve Howell]

On Nov 23, 2:47 am, Antoine Pitrou <solip... at pitrou.net> wrote:
> Le Mon, 23 Nov 2009 02:36:33 -0600, Robert Kern a écrit :
>
>
>
> > I think there is an overall design sensibility, it's just not a
> > human-facing one. They claim that they designed the syntax to be very
> > easily parsed by very simple tools in order to make things like syntax
> > highlighters very easy and robust. So indentation-based blocks are right
> > out.
>
> But computer languages should be designed to be readable by humans.
> It's not like you need to write a new parser once a year, but you have to
> read code everyday.
> Besides, if you want parsing to be easy, you don't need to make the
> syntax minimal, you just have to provide the parsing routines as part of
> the standard library and/or of an external API.

You could argue that by keeping the computer-facing part of the
language simple, you make it easier for tools to take care of the
human-facing side.  But when you leave it up to third-party tools (or
diligent programmers) to format code, the language designers have a
lot less control over the aesthetics of programs in the wild, and you
start having style wars over braces, etc., and no two Go programs will
look like they reflect the same sensibility.

Human readability and computer readability obviously do not have to be
completely orthogonal, as proven by Python.  But to the extent that
they are orthogonal, I think there's a natural inclination to make a
systems programming language focus on the computer-facing issues, with
the huge caveat that leaving human-side issues to higher levels on the
stack (linters, code formatters, etc.) complicates the overall
ecosystem.

Since Go is designed for building large programs, any failure of the
Go community to prescribe a common aesthetic will probably get
magnified to a large degree.

Finally, a lot of aesthetics transcend syntax, so you can argue that
the most important thing to do to enable programmers to create
beautiful programs is to make them be more productive, and a fast
compiler is pretty crucial for that, since a lot of human programmers
work better in a "flow" state.