71–80 of 249 posts
3542 files 540,000 lines of Go code 65,000 lines of comments So on average only 170 lines per file, including 17 lines of comments. Are this normal ratios ?
Six functions sounds very reasonable to me.
Earlier quoted context omitted.
You're now the third person in the past couple of weeks I've seen who are insisting that the only explanation is that Go language users must be ignorant of all these other wonderful features. But I'd say that in order for that to be true, you must believe that there is a large number of Go programmers who either learned Go for their first language, or their other languages they know are all bereft of these features.…
>... 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 grabcocque was complaining about. It seems grabcocque was criticizing the writing about Go but others seem to be interpreting it as an insult to Go programmers . They are 2 different things! (My guess is that the word "blub" triggers the misinterpretation.) All of the…
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()
In more Pythonic Python, the following is middling magic:
@somedecorator
class Something: # entire rest of code example pasted here
Not magic at all:
class Something(Superclass): # rest of example follows
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.)
Earlier quoted context omitted.
I can't believe that I read a nice article about working on a massive project in Go over a couple of years - a meaningful experience that we could probably all learn from - and the top comment doesn't build on the content of the post at all, but is rather a thinly veiled accusation of "Go is a terrible language".
Really? Because your profile says you've been a member for over 2700 days, so you should be used to HN comments by now.
3542 files 540,000 lines of Go code 65,000 lines of comments So on average only 170 lines per file, including 17 lines of comments. Are this normal ratios ?
I'd say those ratios are very similar.
Earlier quoted context omitted.
Example, properties in C# can be method calls, and while they appear to have the complexity of accessing a field they actually could be arbitrarily algorithmically complex. This leads to a programmer down the road, calling it in a tight look, expecting field access overhead and getting somones complex property-method-logic. That is an example of magic. IMHO magic is when the run or space time complexity of a code isn…
So these will be made into functions with uncertain O complexity. How's this situation preferable?
This entire piece sounds like the Blub Paradox made real. http://paulgraham.com/avg.html It's written with knocking down a very specific set of straw men in mind, but rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. One of the things that's most irritating about Go enthusiasts is the way they try to close ranks on legitimate critique and reframe their language…
I can't believe that I read a nice article about working on a massive project in Go over a couple of years - a meaningful experience that we could probably all learn from - and the top comment doesn't build on the content of the post at all, but is rather a thinly veiled accusation of "Go is a terrible language".
That's because it is.
Earlier quoted context omitted.
Example, properties in C# can be method calls, and while they appear to have the complexity of accessing a field they actually could be arbitrarily algorithmically complex. This leads to a programmer down the road, calling it in a tight look, expecting field access overhead and getting somones complex property-method-logic. That is an example of magic. IMHO magic is when the run or space time complexity of a code isn…
So these will be made into functions with uncertain O complexity. How's this situation preferable?
Earlier quoted context omitted.
Example, properties in C# can be method calls, and while they appear to have the complexity of accessing a field they actually could be arbitrarily algorithmically complex. This leads to a programmer down the road, calling it in a tight look, expecting field access overhead and getting somones complex property-method-logic. That is an example of magic. IMHO magic is when the run or space time complexity of a code isn…
I don't think that's quite right. E.g. if you do call a method, it's complexity is unknowable with only local context, so it can't be obvious. I would rewrite that to: > Magic is when the run or space time complexity of code is misleading by its on-screen representation. An apparent field access that is actually a method is misleading. Calling a method explicitly just directs you to check that method to know for sure…
I mean, you don't have to implement all the interfaces explicitly, you just have to get your structure right and be done with it.
Am I missing something?
Earlier quoted context omitted.
> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.
When people say "magic", what they often mean is "code over here can effect the execution of code over there in an implicit way". Like in Ruby, I could conditionally monkey-patch a function into an object someone way over there was using, causing code to break. Other languages, like those with stronger type systems, will not allow this to happen.
If it gets overused it causes problems but there are times when it is close to a miracle. That said, there is a reason ruby devs are so test conscious.