On Sun, 24 May 2015 17:25:54 EDT minux <minux...@gmail.com> wrote:
>
> On Sun, May 24, 2015 at 11:55 AM, erik quanstrom <quans...@quanstro.net>
> wrote:
>
> > > Uhm I might be mistaken, but I guess [8192]byte is an array, and []byte
> > are
> > > slices - therefore they are different types.
> > >
> >
> > yes, exactly. i suppose this implies that different size arrays are not
> > type compatable
> > (yea pascal). also the fu := bar[:] looks a lot like the tedious casting
> > from c, and implies
> > dynamic allocation of the slice, i'm guessing.
> >
>
> You can also argue that C arrays are pascal style. char x[8192] and
> char y[4096] do not have compatible types.
In C arrays are not first class objects. In Pascal they are.
They are passed by value (unless explicitly passed as a ref).
In C you can't even do
a = b
Where a & b are the same size and type arrays.
> In fact. how could different array types be really compatible in a C like
> language?
>
> void f(int a[50]);
>
> even though you can pass a (pointer to) array of 25 ints, I doubt the
> function would do the right thing.
>
> If you pass both the pointer and the length to the function, then you're
> just emulating a Go slice (without the capacity).
To pass a ref parameter, in Pascal you can do, for example,
function f(var a:array[0..3][0..3] of integer)
You can easily pass a subarray to f as:
var a: array[0..99][0..99] of integer
...
f(a[3..5][4..7])
And any modifications in f will update a. It is upto the
compiler to do the right thing. [you can implement this a
couple of different ways]
You can even pass a var array parameter by value later (and
the compiler will do the appropriate copying).
I think that by exposing "slice" as a user visible type, Go
gave up some things. Referencing a sub-array and extending an
array are two very different things but a go slice is used for
both and you can get some bizarre results. Try something like
func f(b []int) {
b = append(b, 55)
}
func main() {
a := []int{0,1,2,3,4,5}
f(a[0:2])
fmt.Printf("a=%v\n", a)
f(a[5:])
fmt.Printf("a=%v\n", a)
}
To a newbie it would be very suprising that 2 got overwritten
with 55 but the second 55 got lost! An experienced Go
programmer would navigate around such sandbars but such
behavior is disconcerting.
> Regarding the boring comment, I agree to some extent. There isn't
> many fancy features that other languages have, but that's exactly the
> advantage of Go, and it's the price to pay when you want readability.
> (i.e. you don't need ~65 pages of style guide just to tell you how to
> write acceptable code.)
Boring != simple. Plan9 is simple but not boring. Scheme is
simple but not boring. Go lacks some features but it is not
simple (nor orthogonal -- though I don't think that was a
stated goal). In Go's favor, the Go code *is* easy to read
and overall it is a well engineered practical language (that
is what I meant by boring).
