On Friday, 25 December 2009 at 00:31:58 UTC, Walter Bright wrote:
> Andrei and I were just talking about programming language books, and how we both thought it was disingenuous that some of them never admit to any flaws in the language. We hope we don't fall into that trap.

Whoops.

On Wednesday, 30 December 2009 at 14:32:01 UTC, merlin wrote:
> Walter Bright wrote:
>> http://www.reddit.com/r/programming/comments/ai9uc/whats_cs_biggest_mistake/
>
> That's a big one.  I don't know if it's the biggest, there are so many to choose from:
>
> *) lack of standard bool type (later fixed)
> *) lack of guaranteed length integer types (later fixed)
> *) lack of string type and broken standard library string handling (not fixed)
> *) obviously wrong type declaration (int v[] not int[] v)


I agree with your previous point but your type declaration syntax is still awful IMHO declaring int[Y][X] and then using [x][y]..
I don't like reading type declaration right-to-left and then normal code left-to-right..


> *) grammar not context free (so close, yet so far...)
> *) lousy exception handling implementation

You forgot no sane integer overflow behaviour, undefined program on overflow isn't a good default behaviour, it should be only a possible optimisation.
Same with array indexing.

renoX

On Thursday, 8 November 2012 at 09:38:28 UTC, renoX wrote:
> I agree with your previous point but your type declaration syntax is still awful IMHO declaring int[Y][X] and then using [x][y]..
> I don't like reading type declaration right-to-left and then normal code left-to-right..

Well, then read type declarations left-to-right. It's the strangest decision in design of golang to reverse type declarations. I always read byte[] as `byte array`, not `an array of bytes`.

On Thu, 08 Nov 2012 19:45:31 +0100
"Kagamin" <spam@here.lot> wrote:

> On Thursday, 8 November 2012 at 09:38:28 UTC, renoX wrote:
> > I agree with your previous point but your type declaration
> > syntax is still awful IMHO declaring int[Y][X] and then using
> > [x][y]..
> > I don't like reading type declaration right-to-left and then
> > normal code left-to-right..
> 
> Well, then read type declarations left-to-right. It's the strangest decision in design of golang to reverse type declarations. I always read byte[] as `byte array`, not `an array of bytes`.

Doing "int[y][x] ... foo[x][y]" is an odd reversal. But Issue 9's "[x][y]int" *also* feels very backwards to me (though perhaps I'd get used to it?). Either way though, they still both beat the hell out of C/C++'s seemingly random arrangement which can't be read left-to-right *or* right-to-left. So I'm happy either way :)

Well, in the same vein one could argue that write(a,b) looks as if first function is called then arguments are computed and passed so the call should be written (a,b)write instead. The language has not only syntax, but also semantics.

On Thursday, 8 November 2012 at 18:45:35 UTC, Kagamin wrote:
> Well, then read type declarations left-to-right. It's the strangest decision in design of golang to reverse type declarations. I always read byte[] as `byte array`, not `an array of bytes`.

How do you read byte[5][2] from left to right? "Byte arrays of 5 elements 2 times in an array". It's impossible. On the other hand, [5][2]byte reads nicely from left to right: "Array of 5 arrays of 2 bytes". You start with the most important fact: that it's an array. Then you start describing what the array is made of.

On Thu, 08 Nov 2012 21:04:06 +0100
"Kagamin" <spam@here.lot> wrote:

> Well, in the same vein one could argue that write(a,b) looks as if first function is called then arguments are computed and passed so the call should be written (a,b)write instead. The language has not only syntax, but also semantics.

Actually, that's one of the reasons I prefer UFCS function chaining over nested calls.

On Thu, Nov 08, 2012 at 10:47:10PM -0500, Nick Sabalausky wrote:
> On Thu, 08 Nov 2012 21:04:06 +0100
> "Kagamin" <spam@here.lot> wrote:
> 
> > Well, in the same vein one could argue that write(a,b) looks as if first function is called then arguments are computed and passed so the call should be written (a,b)write instead. The language has not only syntax, but also semantics.

In that case, we should just switch wholesale to reverse Polish notation, and get rid of parenthesis completely. Why write hard-to-read expressions like a+2*(b-c) when you can write a 2 b c - * +? Then function calls would fit right in:

	1 5 sqrt + 2 / GoldenRatio == assert;

Even constructs like if statements would be considerably simplified:

	i 10 < if i++ else i--;

Things like function composition would actually make sense, as opposed to the reversed order of writing things that mathematicians have imposed upon us. Instead of f(g(x)) which makes no sense in terms of ordering, we'd have x g f, which shows exactly in what order things are evaluated.

;-)


> Actually, that's one of the reasons I prefer UFCS function chaining over nested calls.

Fortunately for me, I got used to UFCS-style function chaining when learning jQuery. (Yes, Javascript actually proved beneficial in that case, shockingly enough.)


T

-- 
Prosperity breeds contempt, and poverty breeds consent. -- Suck.com

On Friday, 9 November 2012 at 00:18:40 UTC, Tommi wrote:
> How do you read byte[5][2] from left to right?

The structure is fairly the same as byte[].

On Friday, 9 November 2012 at 03:47:16 UTC, Nick Sabalausky wrote:
> Actually, that's one of the reasons I prefer UFCS function chaining
> over nested calls.

Left-to-right chaining, right-to-left chaining and nesting are three different cases.