Go versus Brand X

[Aahz]

Comparing Go to another computer language -- do you recognize it?

http://www.cowlark.com/2009-11-15-go/
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it." --Brian W. Kernighan

 

[Mensanator]

Comparing Go to another computer language -- do you recognize it?

No, it predates my entry into the computer biz.

 

[Michel Claveau - MVP]

Hi!

http://www.cowlark.com/2009-11-15-go

Funny
;-)

 

[John Roth]

Yes, spotted it at the first 'fi'.

This isn't the first time anyone has criticized Go. The interesting,
and somewhat sad, thing is that the entire mess can be explained
very easily by looking at the beginning of the language design
FAQ on the Go web site. See if you recognize the names of the
principle people who designed it.

Yep. Go is simply C with most (but not all) of the warts
removed and some more modern features added. Brought to you
by the same people who brought you C and Unix all those years ago.
The use of the Plan 9 toolchain is not a coincidence.

John Roth

 

[Nobody]

Comparing Go to another computer language -- do you recognize it?

"Here is a language so far ahead of its time that it was not only an
improvement on its predecessors but also on nearly all its successors."

- C. A. R. Hoare (although he was actually referring to ALGOL-60).

 

[Steve Howell]

This isn't the first time anyone has criticized Go. The interesting,
and somewhat sad, thing is that the entire mess can be explained
very easily by looking at the beginning of the language design
FAQ on the Go web site. See if you recognize the names of the
principle people who designed it.

Yep. Go is simply C with most (but not all) of the warts
removed and some more modern features added. Brought to you
by the same people who brought you C and Unix all those years ago.
The use of the Plan 9 toolchain is not a coincidence.

The assertion that Go is simply C with warts removed and modern
features added is not surprising.

If you read the Go FAQ, you will see that there is no claim anywhere
that they are trying to solve the problem that 40 years of language
development since Algol has not produced super-sexy quantum leaps of
improvement. Instead, they are trying to solve the problem that in
the last ten years, there haven not seen ANY improvement in systems
programming languages ("No major systems language has emerged in over
a decade"). The critics of Go probably fall into four categories:

1) Some do not understand the goals of the Go project itself, so
they are criticizing Go for not solving problems that were never in
Go's bailiwick to begin with.
2) Some believe that Go does not deliver on its goal to modernize
systems programming languages.
3) Some do not accept the premise that there has been no progress
outside of Go in the last ten years with regards to systems
programming languages, and they are wondering why Google invented Go
instead of embracing other technologies.
4) Some people do not even believe that the problem is important--do
we actually need a modern systems programming language, or do we just
need modern programming languages to perform well under all
circumstances, or at least be adaptable?

My list probably isn't even nearly exhaustive.

 

[Mensanator]

The assertion that Go is simply C with warts removed and modern
features added is not surprising.

If you read the Go FAQ, you will see that there is no claim anywhere
that they are trying to solve the problem that 40 years of language
development since Algol has not produced super-sexy quantum leaps of
improvement.  Instead, they are trying to solve the problem that in
the last ten years, there haven not seen ANY improvement in systems
programming languages ("No major systems language has emerged in over
a decade").  The critics of Go probably fall into four categories:

  1) Some do not understand the goals of the Go project itself, so
they are criticizing Go for not solving problems that were never in
Go's bailiwick to begin with.
  2) Some believe that Go does not deliver on its goal to modernize
systems programming languages.
  3) Some do not accept the premise that there has been no progress
outside of Go in the last ten years with regards to systems
programming languages, and they are wondering why Google invented Go
instead of embracing other technologies.
  4) Some people do not even believe that the problem is important--do
we actually need a modern systems programming language, or do we just
need modern programming languages to perform well under all
circumstances, or at least be adaptable?

My list probably isn't even nearly exhaustive.

Like those who think Python programmers would be interedted in
Go because it has an import statement.

 

[Gregory Ewing]

>

Syntax-wise, I find myself disappointed that they didn't
do as good a job of removing the warts as they could
have.

For example, there are good reasons for putting types
after variable names, but just swapping them around doesn't
quite work. C's "int x" reads well because it mimics similar
constructs in English which qualify a noun with another
noun, e.g. "President Obama". If you say "Obama President",
it doesn't sound right. You need some extra punctuation
to make it meaningful: "Obama, President".

Similarly, I think just a little bit more punctuation
is needed to make name-first declarations readable. For
my money, it's hard to beat the Wirth style:

func foo(x: int; y: char): float

However, Go's designers seem to favour using the absolute
minimum number of characters they can get away with.

Although if they *really* wanted that, they would have
dropped most of the semicolons and used indentation-based
block structure instead of curly braces. I would have
forgiven them several other sins if they'd done that.

 

[Aahz]

However, Go's designers seem to favour using the absolute minimum
number of characters they can get away with.

Although if they *really* wanted that, they would have dropped most of
the semicolons and used indentation-based block structure instead of
curly braces. I would have forgiven them several other sins if they'd
done that.

That's essentially my issue with Go based on the code samples I've seen:
no over-arching design sensibility at the syntax level. It looks like an
aggolomeration of semi-random C-like syntax. There's nothing that
shouts out, "This is a Go program," unlike Python, C, and even Perl.

 

[Robert Kern]

That's essentially my issue with Go based on the code samples I've seen:
no over-arching design sensibility at the syntax level. It looks like an
aggolomeration of semi-random C-like syntax. There's nothing that
shouts out, "This is a Go program," unlike Python, C, and even Perl.

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.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Antoine Pitrou]

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.

 

[J Kenneth King]

Comparing Go to another computer language -- do you recognize it?

http://www.cowlark.com/2009-11-15-go/

If you skip to the conclusion, you'll be better off.

The author has an interesting point.

Go (the language) is not really ground-breaking.

I don't understand why they're so busy creating their own walled
garden...

Their own browser, their own programming languages, their own file
systems, etc.

Weird.

 

[Lie Ryan]

If you skip to the conclusion, you'll be better off.

The author has an interesting point.

Go (the language) is not really ground-breaking.

I don't understand why they're so busy creating their own walled
garden...

Their own browser, their own programming languages, their own file
systems, etc.

because they can, no?

Normal business logic doesn't apply to Google.

 

[Steve Howell]

Le Mon, 23 Nov 2009 02:36:33 -0600, Robert Kern a écrit :




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.

 

[Robert Kern]

Le Mon, 23 Nov 2009 02:36:33 -0600, Robert Kern a écrit :

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.

You will get no argument from me. My point was only that they had an overall
design sensibility, not that it was a good one.

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.

Not really. The idea was to make the language easily parsed and lexed and
analyzed by *other* tools, not written in Go, that may have limited
capabilities. Vim isn't written in Go and won't be able to use their API, for
example.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Terry Reedy]

You will get no argument from me. My point was only that they had an
overall design sensibility,

I think you characterized it fairly, even if it is not one many of us
here want to work within.

Of course, one way they could show the benefit of Go would be to rewrite
CPython in Go and have it be faster, at least for appropriate programs
on multicore machines. Or write a Python compiler. Either way, include a
foreign function interface that could connect to existing C extensions.
Google and the rest of the world certainly have lots of code to test such.

 

[Antoine Pitrou]

Le Mon, 23 Nov 2009 11:54:19 -0600, Robert Kern a écrit :

Not really. The idea was to make the language easily parsed and lexed
and analyzed by *other* tools, not written in Go, that may have limited
capabilities.

Well, if Go doesn't allow you to write libraries usable from other low-
level languages I'm not sure it is a good systems programming language.
One point of C is that you can bridge it with everything.

Vim isn't written in Go and won't be able to use their
API, for example.

Syntax highlighting doesn't require a full-blown parser. You probably
want to handle three types of events:
- comments (and docstrings and the like for languages which have them)
- keywords
- delimiters of basic syntactical blocks (which most of the time is
simply matching pairs of parens / square brackets / curly brackets)

That is, you need a very small part of the information a complete parser
would give you.
In particular, you don't need to know about operator precedence. You
don't need to know about what kind of block you are inside (function,
method, class...). You don't need to know whether an identifier is a
local variable, a global variable, a type, etc. You don't even need to
know the different operators. You only need to recognize the basic
lexemes and that's all.

The reason the Go designers gave for the braindead syntax looks
dramatically unserious and makes it look a bit like a joke.
(actually, what really made me wonder whether Go was a joke was the
"iota" keyword)

 

[Robert Kern]

Le Mon, 23 Nov 2009 11:54:19 -0600, Robert Kern a écrit :

Well, if Go doesn't allow you to write libraries usable from other low-
level languages I'm not sure it is a good systems programming language.
One point of C is that you can bridge it with everything.

That doesn't help tools that are already built with their own capabilities. I
don't link Python into my editor to get Python syntax highlighting. The easier
it is to write *a* parser/analyzer for the language in any other programming
language, the more tools you will get for a broader range of runtime
environments, particularly constrained environments like editors that may not be
extensible at all.

Syntax highlighting doesn't require a full-blown parser.

Most of the time. FORTRAN does require a full-blown parser if you want to be
accurate. And the more regular a language is, the more interesting things one
can do with just the tools that are usually available for syntax highlighting.
FORTRAN and Go represent two opposite sides of that spectrum.

You probably
want to handle three types of events:
- comments (and docstrings and the like for languages which have them)
- keywords
- delimiters of basic syntactical blocks (which most of the time is
simply matching pairs of parens / square brackets / curly brackets)
>
That is, you need a very small part of the information a complete parser
would give you.
In particular, you don't need to know about operator precedence. You
don't need to know about what kind of block you are inside (function,
method, class...). You don't need to know whether an identifier is a
local variable, a global variable, a type, etc. You don't even need to
know the different operators. You only need to recognize the basic
lexemes and that's all.

You can get away with just that and have something people recognize as syntax
highlighting, yes. But if it is possible to highlight local variables, globals,
and types differently, that *is* useful. And you will even see some syntax
highlighters doing more advanced things like that even for Python (though mostly
with heuristics).

But note that the more regular the language is, the less you need to rely on a
full parser, and the more interesting things you can do with just lexing and
other simpler approaches. That's what they are going for. If I were designing a
language, that wouldn't be the tradeoff I would make, but they have their own needs.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Gregory Ewing]

The easier it is to write *a* parser/analyzer for the
language in any other programming language, the more tools you will get
for a broader range of runtime environments, particularly constrained
environments like editors that may not be extensible at all.

Seems to me that having a bit more punctuation in the
language would make it easier for things like editors
that don't have sophisticated parsing abilities to
do a better job of syntax highlighting.

 

[Antoine Pitrou]

Le Mon, 23 Nov 2009 15:30:16 -0600, Robert Kern a écrit :

particularly constrained environments like editors that may not be
extensible at all.

I'm not really an expert on this, but I think most good editors /are/
extensible (through plugins, scripts or other things).

You can get away with just that and have something people recognize as
syntax highlighting, yes. But if it is possible to highlight local
variables, globals, and types differently, that *is* useful. And you
will even see some syntax highlighters doing more advanced things like
that even for Python (though mostly with heuristics).

I suppose it's a matter of taste. I don't expect syntax highlighting to
do anything else than make the source code more readable and make some
important things stick out (comments, keywords etc.). It's probably the
same debate as text editor vs. full IDE. Users of text editors view
programming as a literary practice where they manipulate text, while
users of IDEs view programming as bringing technologies together through
specialized tools.

Interestingly, we don't know how easy to parse Go is. We just have to
trust their word on that, but perhaps Python is easier to parse (while
being less ugly).