* Re: [9fans] ot: pascal rides again?
2015-05-24 15:55 ` erik quanstrom
@ 2015-05-24 16:19 ` Devon H. O'Dell
2015-05-24 17:02 ` Aram Hăvărneanu
` (3 subsequent siblings)
4 siblings, 0 replies; 16+ messages in thread
From: Devon H. O'Dell @ 2015-05-24 16:19 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 15:55 ` erik quanstrom
2015-05-24 16:19 ` Devon H. O'Dell
@ 2015-05-24 17:02 ` Aram Hăvărneanu
2015-05-24 17:53 ` Ryan Gonzalez
2015-05-24 17:50 ` Ryan Gonzalez
` (2 subsequent siblings)
4 siblings, 1 reply; 16+ messages in thread
From: Aram Hăvărneanu @ 2015-05-24 17:02 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 17:02 ` Aram Hăvărneanu
@ 2015-05-24 17:53 ` Ryan Gonzalez
0 siblings, 0 replies; 16+ messages in thread
From: Ryan Gonzalez @ 2015-05-24 17:53 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs, Aram Hăvărneanu
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 15:55 ` erik quanstrom
2015-05-24 16:19 ` Devon H. O'Dell
2015-05-24 17:02 ` Aram Hăvărneanu
@ 2015-05-24 17:50 ` Ryan Gonzalez
2015-05-24 19:00 ` Bakul Shah
2015-05-24 21:25 ` minux
4 siblings, 0 replies; 16+ messages in thread
From: Ryan Gonzalez @ 2015-05-24 17:50 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs, erik quanstrom
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 15:55 ` erik quanstrom
` (2 preceding siblings ...)
2015-05-24 17:50 ` Ryan Gonzalez
@ 2015-05-24 19:00 ` Bakul Shah
2015-05-24 19:36 ` Ryan Gonzalez
2015-05-24 21:25 ` minux
4 siblings, 1 reply; 16+ messages in thread
From: Bakul Shah @ 2015-05-24 19:00 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 19:00 ` Bakul Shah
@ 2015-05-24 19:36 ` Ryan Gonzalez
0 siblings, 0 replies; 16+ messages in thread
From: Ryan Gonzalez @ 2015-05-24 19:36 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs, Bakul Shah
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 15:55 ` erik quanstrom
` (3 preceding siblings ...)
2015-05-24 19:00 ` Bakul Shah
@ 2015-05-24 21:25 ` minux
2015-05-25 1:26 ` C Cirello
` (2 more replies)
4 siblings, 3 replies; 16+ messages in thread
From: minux @ 2015-05-24 21:25 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 21:25 ` minux
@ 2015-05-25 1:26 ` C Cirello
2015-05-25 5:39 ` lucio
2015-05-25 7:59 ` Bakul Shah
2 siblings, 0 replies; 16+ messages in thread
From: C Cirello @ 2015-05-25 1:26 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 21:25 ` minux
2015-05-25 1:26 ` C Cirello
@ 2015-05-25 5:39 ` lucio
2015-05-25 7:59 ` Bakul Shah
2 siblings, 0 replies; 16+ messages in thread
From: lucio @ 2015-05-25 5:39 UTC (permalink / raw)
To: 9fans
> (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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [9fans] ot: pascal rides again?
2015-05-24 21:25 ` minux
2015-05-25 1:26 ` C Cirello
2015-05-25 5:39 ` lucio
@ 2015-05-25 7:59 ` Bakul Shah
2 siblings, 0 replies; 16+ messages in thread
From: Bakul Shah @ 2015-05-25 7:59 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
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).
^ permalink raw reply [flat|nested] 16+ messages in thread