[9fans] ot: pascal rides again?

[9fans] ot: pascal rides again?

[erik quanstrom]

well, at least dennis wrote "why pascal is not my favorite programming language".

from go build

	./cat.go:36: cannot use data (type [8192]byte) as type []byte in argument to cat

what?  perhaps i'm missing something about the language, but it sure seems ironic.

- erik

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

[Eduardo Alvarez]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

I thought the author was Brian Kernighan?
<http://www.lysator.liu.se/c/bwk/index.html>

On Sat, May 23, 2015 at 12:53 PM, erik quanstrom <quanstro@quanstro.net>
wrote:

> well, at least dennis wrote "why pascal is not my favorite programming
> language".
>
> from go build
>
>         ./cat.go:36: cannot use data (type [8192]byte) as type []byte in
> argument to cat
>
> what?  perhaps i'm missing something about the language, but it sure seems
> ironic.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 894 bytes --]

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

[Aram Hăvărneanu]

http://blog.golang.org/slices
http://blog.golang.org/go-slices-usage-and-internals

-- 
Aram Hăvărneanu

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

[C Cirello]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Uhm I might be mistaken, but I guess [8192]byte is an array, and []byte are
slices - therefore they are different types.

        - CC

2015-05-23 17:53 GMT+02:00 erik quanstrom <quanstro@quanstro.net>:

> well, at least dennis wrote "why pascal is not my favorite programming
> language".
>
> from go build
>
>         ./cat.go:36: cannot use data (type [8192]byte) as type []byte in
> argument to cat
>
> what?  perhaps i'm missing something about the language, but it sure seems
> ironic.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1120 bytes --]

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

[Ryan Gonzalez]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

I read the Go docs *once*, but I'm pretty sure you're right.

I think to make a slice out of an array, you'd do something like the_array[:].

All to say why I don't like Go. :)

On May 23, 2015 1:14:55 PM CDT, C Cirello <uldericofilho@gmail.com> wrote:
>Uhm I might be mistaken, but I guess [8192]byte is an array, and []byte
>are
>slices - therefore they are different types.
>
>        - CC
>
>2015-05-23 17:53 GMT+02:00 erik quanstrom <quanstro@quanstro.net>:
>
>> well, at least dennis wrote "why pascal is not my favorite
>programming
>> language".
>>
>> from go build
>>
>>         ./cat.go:36: cannot use data (type [8192]byte) as type []byte
>in
>> argument to cat
>>
>> what?  perhaps i'm missing something about the language, but it sure
>seems
>> ironic.
>>
>> - erik
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1745 bytes --]

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

[erik quanstrom]

> 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.

- erik

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

[Devon H. O'Dell]

http://blog.golang.org/go-slices-usage-and-internals

2015-05-24 8:55 GMT-07:00 erik quanstrom <quanstro@quanstro.net>:
>> 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.
>
> - erik
>

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

[Aram Hăvărneanu]

On Sun, May 24, 2015 at 5:55 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> and implies dynamic allocation of the slice, i'm guessing.

Don't guess. Please read the links I provided, they explain all this.
Arrays in Go are not like arrays in C and Pascal, slices are more
close. Go arrays are values, so copying one is an O(n) operation.

-- 
Aram Hăvărneanu

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

[Ryan Gonzalez]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

It's actually a reference to the original array, I believe.

On May 24, 2015 10:55:31 AM CDT, 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.
>
>- erik

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

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

[Ryan Gonzalez]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

Go array =~ C++ std::array
Go slice =~ C++ std::vector&


On May 24, 2015 12:02:54 PM CDT, "Aram Hăvărneanu" <aram.h@mgk.ro> wrote:
>On Sun, May 24, 2015 at 5:55 PM, erik quanstrom <quanstro@quanstro.net>
>wrote:
>> and implies dynamic allocation of the slice, i'm guessing.
>
>Don't guess. Please read the links I provided, they explain all this.
>Arrays in Go are not like arrays in C and Pascal, slices are more
>close. Go arrays are values, so copying one is an O(n) operation.
>
>-- 
>Aram Hăvărneanu

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1001 bytes --]

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

[Bakul Shah]

On May 24, 2015, at 8: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.
> 
> - erik
> 
Later pascal standards supported conformant array parameters. And several extended pascal compilers provided dynamic arrays.

In Go multidimensional arrays are not well supported. Try this:

var x [5][6]int
y := x[:2][:3]
fmt.Printf("%v\n", y)

It is what it is. Get used to it if you want/have to use Go! Apart from its concurrency features it is a pretty boring language but it is surprisingly easy to write code in it.

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

[Ryan Gonzalez]

On May 24, 2015 2:00:05 PM CDT, Bakul Shah <bakul@bitblocks.com> wrote:
>
>
>On May 24, 2015, at 8: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.
>> 
>> - erik
>> 
>Later pascal standards supported conformant array parameters. And
>several extended pascal compilers provided dynamic arrays.
>
>In Go multidimensional arrays are not well supported. Try this:
>
>var x [5][6]int
>y := x[:2][:3]
>fmt.Printf("%v\n", y)
>
>It is what it is. Get used to it if you want/have to use Go! Apart from
>its concurrency features it is a pretty boring language but it is
>surprisingly easy to write code in it.

Seriously. I like Nim better. And K...


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[minux]

[-- Attachment #1: Type: text/plain, Size: 1409 bytes --]

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 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).

In essence, Go's array is not directly related to C's, it's more like a C
array wrapped in a struct. A slice is what C programmers normally
use to pass an array.

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.)

[-- Attachment #2: Type: text/html, Size: 2018 bytes --]

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

[C Cirello]

2015-05-24 23:25 GMT+02:00 minux <minux.ma@gmail.com>:
>
> 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.)


This is a plan9 list - so I really don't want to extend the debate
further. Being a simpler language, it means also you can write a style
guide which says "you are free to use the whole language" instead of
the usual C++ recommendations : "use this subset of the language".

BTW, that's what happened with Plan 9's C - they simplified the
language by trimming the preprocessor and forcing few stylistic
choices in syntax (like ANSI C function declarations over K&R function
declarations).

By the same token we can say Go is boring, we can say Plan 9 is
boring: rio does less with a much simpler design than X11, but it
delivers much more - including window recursion and the ability to run
X11 itself. In Plan 9 too, less is exponentially more.

        - CC

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

[lucio]

> (i.e. you don't need ~65 pages of style guide just to tell you how to
> write acceptable code.)

I think it's wasteful to defend Go.  Let history do that...

Lucio.

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

[Bakul Shah]

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).