Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Lucky for you there's an article explaining exactly that: http://blog.golang.org/gos-declaration-syntax

---

I like the map. Here's the rules for Conway's Game of Life as a nested map:

    var cgol = map[state]map[int]state{
        alive: {
            0: dead,
            1: dead,
            2: alive,
            3: alive,
            4: dead,
            5: dead,
            6: dead,
            7: dead,
            8: dead,
        },
        dead: {
            0: dead,
            1: dead,
            2: dead,
            3: alive,
            4: dead,
            5: dead,
            6: dead,
            7: dead,
            8: dead,
        },
    }


That type declaration is easily as unreadable as any "pointer to function returning pointer" declaration in C.


What nonsense, where is there any remote ambiguity? Where is it even slightly unreadable?


Reads pretty clearly left-to-right to me:

map[state]map[int]state -> a map of state keys pointing to maps of int keys pointing to states


    "map of int to string"
     map   [int]   string
    
    "map of state to map of int to state"
     map   [state]   map   [int]   state
In Rich Hickey terminology, it seems people reject that it is simple (non-interwoven) because it does not strike them as easy (familiar / close to hand).

( ...Any excuse to link to this excellent presentation: http://www.infoq.com/presentations/Simple-Made-Easy )


I read that as arrogance.

Before C, naturally no-one knew C.

Before Go though, tens of millions know C.

They are casually throwing away all of that familiarity in the name of elegance. I think this is what might mean that Go doesn't "win".


For someone who can already program, such things are trivial to learn.

If you class doing basic design work and taking time to document it as "arrogance" then I'm afraid you may be suffering from negative mindset.


It's important to note that a lot of C programmers don't really understand the C declaration syntax anyway. Most are familiar with the simple cases, very few are familiar with how to declare complex types.

I can barely read this: void (signal(int, void (fp)(int)))(int);

I can read this easily: func signal(int, func(int)) func(int)


> throwing away all of that familiarity in the name of elegance

That looks like a good deal to me! :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: