Re: [9fans] ot: pascal rides again?

[Bakul Shah <bakul@bitblocks.com>]

On Sun, 24 May 2015 17:25:54 EDT minux <minux.ma@gmail.com> wrote:
>
> On Sun, May 24, 2015 at 11:55 AM, erik quanstrom <quanstro@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).