On Jun 26, 2020, at 2:59 PM, Ian Lance Taylor <i...@golang.org> wrote:
> 
> I honestly don't think that append is an example of worse-is-better.
> I think it's an example of preferring to pass and return values rather
> than pointers.  The language could easily have made append take a
> pointer to a slice as its first argument, which would eliminate a
> certain class of bugs.  But it would also mean that you couldn't
> create a slice by simply appending to nil, as in s :=
> append([]int(nil), 1, 2, 3).  You would instead have to declare the
> variable first.

I should clarify that I don't consider it a dig; I think it's a practical 
solution to the problem even if it has its warts, because it is both performant 
and flexible.  Other languages choose either in-place operations (e.g. Java) or 
copies (e.g. Erlang), but you can do a lot more with what's offered in Go.  It 
just takes some getting used to.

> While append does confuse people from time to time, I think it's
> clearly documented, as pointed out upthread.  It's not really all that
> hard to understand.  And once you understand it, it's easy to use.

The "once you understand it" part is really the issue here, because it's not 
immediately obvious if you're not reading the manual.

> I don't think any particular approach is obviously better here, so I
> don't think this is an example of worse-is-better.

The canonical example in Worse Is Better is Unix's solution to the problem 
where you get an interrupt in the middle of a syscall; Unix just said "hey, 
this failed, do it again" instead of going to great lengths to try to resume 
the operation, which was the pragmatic choice even if it led to a somewhat 
quirky interface.

"Worse Is Better" is often characterized more by quirkiness rather than 
outright badness, and Richard Gabriel (LISP purist that he was) was pretty 
upfront about being cheekily hyperbolic about the properties that Unix and C 
had that made them perhaps occasionally inelegant but ultimately more effective 
and survivable.  I think a lot of aspects of Go embody that particular spirit, 
again for good reason considering its progenitors.


- Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/46EE15DC-9728-4DD3-BAAA-F794A78DE123%40gmail.com.

Reply via email to