3 ms·

>... Go language users must be ignorant of all these other wonderful features. All of your comments are reasonable but I don't think it addresses what grabcocq

• jerf 10y ago
  "Whenever I see a writer talk about "magic", "simplicity", "spooky action at a distance", etc it usually turns out that the author picked adjectives that sounded good but not well-defined enough for readers to learn anything useful from it." A valid objection. Here's my personal definition for "magic", which is still a bit fuzzy around the edges, but much more solid than most loose definitions of it: A bit of code is magic when it is not sufficient to examine the tokens the code is made up of and go back to the static textual definitions of those tokens to understand what is going on. In Python-esque psuedo-code, this is magic: class Something: def method(): return 1 s = Something() s.WhereDidThisMethodComeFrom() and the last line does something useful, rather than crash with method not found. You follow s back to its definition, you see it's a "Something". You follow back to the Something class... and there's no "WhereDidThisMethodComeFrom". Something came along later and added it. Who? Where? Oftimes these are so magical that grepping over the entire code base for "WhereDidThisMethodComeFrom" may not help because the name itself may be constructed. In more Pythonic Python, the following is middling magic: @somedecorator class Something: # entire rest of code example pasted here Following back to "Something" you can at least see that something has decorated it and it's a good guess that that much be involved. Still, it's a bit subtle and decorators aren't generally supposed to do that. Not magic at all: class Something(Superclass): # rest of example follows Ah, WDTMCF comes from the superclass. Inheritance is defined as doing that in the language spec so you can follow it up the inheritance hierarchy. (But note this holds for statically-coded inheritance; the fancier your dynamic setting up of the hierarchy gets, the more magical it gets.) Go is entirely non-magical by this definition. The two closest things to magic is having an interface value and calling a method on it, where you can't statically determine exactly which method will be used, and struct composition making methods appear on the composing struct, but both are in the spec and can still be traced back. (The only tricky thing about the struct composition is if you compose in multiple things you might have some non-trivial work to figure out which thing is providing which method.) Haskell, perhaps surprisingly given its reputation, is mostly unmagical. (The OverloadedStrings and friends extensions make it a bit magical, and there is some syntax you can bring in via extension which can be tricky. But otherwise you can, if you work at it, pretty much just use term rewriting by hand to understand anything Haskell is doing.) Python can be magical, though the community tends to avoid it. Ruby and certain chunks of the Javascript community can be very magical. (No non-esolang mandates magic that I can think of. INTERCAL's COME FROM operator/statement/whatever it is may be the epitome of magical.)
  • taco_emoji 10y ago
    I really appreciate this definition of "magical"... reminds me of some code I was reviewing that was something like this: HTML: <button class="does-stuff" id="foo">Foo</button> <button class="does-stuff" id="bar">Bar</button> <!-- etc --> JS: var handlers = { fooClicked: function() { /* stuff */ }, barClicked: function() { /* stuff */ }, /* etc */ }; $('.does-stuff').each(function() { $(this).click(handlers[this.id + "Clicked"]); }); And like... OK, that's clever, but when I'm debugging the fooClicked() method 4 months from now, I can't just do a Find All for "fooClicked" and track down where it's being called from.
  • solidsnack9000 10y ago
    I suspect you would have the same problem as you see in Python, in any situation where you use code generation with Go.