9 ms·

Go Isn't C

76 points by srl 15y ago

101001010101 15y ago
An astounding conclusion! (Sorry, couldn't resist.)
- 101001010101 15y ago
  There we go again. Sense of humour is penalised on HN.
  - srl 15y ago
    I'll give you a pity upvote. It's not sense of humor that's penalized, though. It's comments without content. (Generally.)
    - 101001010101 15y ago
      Thanks. I've learnt the lesson now. I can understand why that's a good rule. Am I the only one who thinks these titles are too often unoriginal, suggestive and often conclusive? And sometimes the conclusions in the title are not even supported in the article. It's not just HN. It's everywhere on the web. I just don't get it.
      - Radix 15y ago
        You aren't the only one, but that's a harder problem to solve as I there are a limited number of mods and people understandably want their posts read. The public high humor bar and one or two post commentary seem to work well for keeping HN only half way over the shark. I upvoted you to make up for it.
      - loopdoend 15y ago
        It's called link bait.
  - rkalla 15y ago
    It is just the (unfortunate) tendency for humor or snark-only comments to devolve into a thread of equivalent snark or hand-slapping that people worry about. So the response is to slap content-thin replies down immediately before they blossum into something worse... Even if they were clever.
  - itmag 15y ago
    I guess the reasoning for it is that HN shouldn't be Reddit. Then again, I've gotten away with humor many times. Actually, some of my highest karma comments are humorous in nature. Examples: http://news.ycombinator.com/item?id=3301212 http://news.ycombinator.com/item?id=3301212 http://news.ycombinator.com/item?id=3299170 http://news.ycombinator.com/item?id=3299170
    - 101001010101 15y ago
      The first one seems to suggest HN may be more like Reddit than I'd imagine some would care to admit. The second one was quite good. Nice one.
    - skore 15y ago
      But that's not even humor just for its own sake - it's actually rather insightful. Which is why it's correct that it wasn't downvoted.
      - itmag 15y ago
        Yeah, I guess you're right. So the take-home message is that HN isn't Reddit. One should be a witty smart-alec rather than a funny wise-ass.
        deleted 15y ago
        [deleted]
        scott_s 15y ago
        I don't think that's the right conclusion. The correct conclusion is, I think: What you say should add something non-trivial to the conversation. If what you have to say is funny, that's a bonus.
timtadh 15y ago
So this all arose because you added a "type" field to your structs and then wrote a lot of code to do type switches. Finally, you realized Go already has this functionality. Note Go makes your life even nicer than you think. your code: v := eval(e) switch v.(type) { case cons: fmt.Printf("<cons>\n") case sym: fmt.Printf("<sym : %s>\n", string(v.(sym))) case float64: fmt.Printf("%f\n", v.(float64)) case string: fmt.Printf("\"%s\"\n", v.(string)) default: fmt.Printf("nil\n") } now without the redundant type assertions. switch v := eval(e).(type) { case cons: fmt.Printf("<cons>\n") case sym: fmt.Printf("<sym : %s>\n", string(v)) case float64: fmt.Printf("%f\n", v) case string: fmt.Printf("\"%s\"\n", v) default: fmt.Printf("nil\n") } It seems like your problem isn't that you don't "trust your tools" it's that you don't known them. That's fine. I don't really know half of mine half as well as I should. Programmers not understanding their tools is a long studied problem with no good solution.
- srl 15y ago
  I do know my tools, actually (having helped create them) - before creating the structs, I did consider this approach, and consciously decided against it for roughly the reasons described. I'm talking about a distinct problem from programmers not knowing their tools - programmers who do know and understand their tools quite well, but decide, for whatever horrible reason, that those tools are "quite good enough", and insist on going from scratch. Sometimes justified, and usually not - and it can lead to a great deal of harm in the way of unmaintainable bloat.
  - omaranto 15y ago
    I think timtadh's jab about you not knowing your tools wasn't about the structs with a type field but about the .(float64) in case float64: fmt.Printf("%f\n", v.(float64)) which can be simplified to case float64: fmt.Printf("%f\n", v)
  - deleted 15y ago
    [deleted]
- 15y ago
joe_the_user 15y ago
On the debugger point that begins the article: I feel oppositely. I feel more like I too often use a debugger when I should be setting up a robust logging system. Debuggers are often "a temporary solution to permanent problem"... Contrary to the author's comments, it makes perfect sense for every system to have its own logging system. 1) It isn't at all hard to create so it doesn't cost you. 2) Every system is a little different in the levels of logging that are use as well as the details that it wants to include or exclude. I'm using Qt currently and their qDebug() statement just sucks for my purposes - there's arbitrary limit on the number of debug outputs allowed. Why? Why? ...
- angkec 15y ago
  That's annoyingly funny. Is there a way to change the limit?
  - joe_the_user 15y ago
    You can change the limit for qDebug() maximum message # but like a lot of defaults, it just tends to stay default...
- wisty 15y ago
  The advantage of hand-rolled loggers is they are easier, for one person, but more difficult for outsiders to get a grip on (compared to a standard solution, which should be well documented). The question is - should other people modify the logging code? If it's just a part of your scaffolding, it might not be a huge issue. It then becomes a trade-off between productivity, and technical debt. Prototypes don't need to be sustainable, they just need to be done. You'll either re-write them, or they will work forever (by some miracle) without maintenance, or most likely end up in the big bit bucket in /dev/null
jroseattle 15y ago
I call this the not-invented-here (NIH) syndrome. Where a seemingly rational developer runs off into esoteric land to add this, that and the other to a system that is used to replace functionality already provided in other well-known applications/systems/constructs/etc. All because they don't know how something works, therefore it's being replaced because it's NIH. Big tech companies are famous for doing this. One of my favorite uses of NIH is to replace something like, oh I don't know -- SQL -- with another query language "to make it easier to write queries". Right. Because SQL is so baffling, that we need to replace it with another syntax. And what will that syntax do? Convert a statement to SQL. I use NIH as a filter in interviewing. If someone cannot appreciate NIH as a productivity killer, I know they generally won't be a good fit for my team.
- kaeluka 15y ago
  one colleague has been renaming my functions recently: she created new functions that did nothing except calling my implementation. The reason was probably that the name of mine was too general..
bballbackus 15y ago
I think most programmers and engineers have personalities that constantly question their own competency. This is predominantly a good quality as it leads to much more rapid talent development, but it also leads to irrational actions like recreating libraries out of fear that you're "not a real programmer" if you use the work of others.
pragmatic 15y ago
I think this is more appropriate for reddit/r/programming. Nothing earth shattering or really related to go or c specifically...rather disappointing.
scott_s 15y ago
I think you should go one step further. Any time you are switching on a type, you're re-implementing virtual functions. I have never coded in Go, but I know it has interfaces and allows this kind of polymorphism. It looks like your type "sexpr" should really be an interface, and then you would have separate structs for a cons cell, a symbol, number and a string.
tree_of_item 15y ago
>And so we end up re-writing parsers where yacc would do, Had me going until there. Rolling your own parser to avoid yacc sounds like an absolutely splendid idea. Techniques like parsing expression grammars are worth some mild sense of "NIH", and in any case there are plenty of PEG libraries to take advantage of as well.

Go Isn't C

76 points by srl 15y ago

101001010101 15y ago

An astounding conclusion! (Sorry, couldn't resist.)

101001010101 15y ago
There we go again. Sense of humour is penalised on HN.
- srl 15y ago
  I'll give you a pity upvote. It's not sense of humor that's penalized, though. It's comments without content. (Generally.)
  - 101001010101 15y ago
    Thanks. I've learnt the lesson now. I can understand why that's a good rule. Am I the only one who thinks these titles are too often unoriginal, suggestive and often conclusive? And sometimes the conclusions in the title are not even supported in the article. It's not just HN. It's everywhere on the web. I just don't get it.
    - Radix 15y ago
      You aren't the only one, but that's a harder problem to solve as I there are a limited number of mods and people understandably want their posts read. The public high humor bar and one or two post commentary seem to work well for keeping HN only half way over the shark. I upvoted you to make up for it.
    - loopdoend 15y ago
      It's called link bait.
- rkalla 15y ago
  It is just the (unfortunate) tendency for humor or snark-only comments to devolve into a thread of equivalent snark or hand-slapping that people worry about. So the response is to slap content-thin replies down immediately before they blossum into something worse... Even if they were clever.
- itmag 15y ago
  I guess the reasoning for it is that HN shouldn't be Reddit. Then again, I've gotten away with humor many times. Actually, some of my highest karma comments are humorous in nature. Examples: http://news.ycombinator.com/item?id=3301212 http://news.ycombinator.com/item?id=3301212 http://news.ycombinator.com/item?id=3299170 http://news.ycombinator.com/item?id=3299170
  - 101001010101 15y ago
    The first one seems to suggest HN may be more like Reddit than I'd imagine some would care to admit. The second one was quite good. Nice one.
  - skore 15y ago
    But that's not even humor just for its own sake - it's actually rather insightful. Which is why it's correct that it wasn't downvoted.
    - itmag 15y ago
      Yeah, I guess you're right. So the take-home message is that HN isn't Reddit. One should be a witty smart-alec rather than a funny wise-ass.
      - deleted 15y ago
        [deleted]
      - scott_s 15y ago
        I don't think that's the right conclusion. The correct conclusion is, I think: What you say should add something non-trivial to the conversation. If what you have to say is funny, that's a bonus.

timtadh 15y ago

So this all arose because you added a "type" field to your structs and then wrote a lot of code to do type switches. Finally, you realized Go already has this functionality. Note Go makes your life even nicer than you think. your code: v := eval(e) switch v.(type) { case cons: fmt.Printf("<cons>\n") case sym: fmt.Printf("<sym : %s>\n", string(v.(sym))) case float64: fmt.Printf("%f\n", v.(float64)) case string: fmt.Printf("\"%s\"\n", v.(string)) default: fmt.Printf("nil\n") } now without the redundant type assertions. switch v := eval(e).(type) { case cons: fmt.Printf("<cons>\n") case sym: fmt.Printf("<sym : %s>\n", string(v)) case float64: fmt.Printf("%f\n", v) case string: fmt.Printf("\"%s\"\n", v) default: fmt.Printf("nil\n") } It seems like your problem isn't that you don't "trust your tools" it's that you don't known them. That's fine. I don't really know half of mine half as well as I should. Programmers not understanding their tools is a long studied problem with no good solution.

srl 15y ago
I do know my tools, actually (having helped create them) - before creating the structs, I did consider this approach, and consciously decided against it for roughly the reasons described. I'm talking about a distinct problem from programmers not knowing their tools - programmers who do know and understand their tools quite well, but decide, for whatever horrible reason, that those tools are "quite good enough", and insist on going from scratch. Sometimes justified, and usually not - and it can lead to a great deal of harm in the way of unmaintainable bloat.
- omaranto 15y ago
  I think timtadh's jab about you not knowing your tools wasn't about the structs with a type field but about the .(float64) in case float64: fmt.Printf("%f\n", v.(float64)) which can be simplified to case float64: fmt.Printf("%f\n", v)
- deleted 15y ago
  [deleted]
15y ago

joe_the_user 15y ago

On the debugger point that begins the article: I feel oppositely. I feel more like I too often use a debugger when I should be setting up a robust logging system. Debuggers are often "a temporary solution to permanent problem"... Contrary to the author's comments, it makes perfect sense for every system to have its own logging system. 1) It isn't at all hard to create so it doesn't cost you. 2) Every system is a little different in the levels of logging that are use as well as the details that it wants to include or exclude. I'm using Qt currently and their qDebug() statement just sucks for my purposes - there's arbitrary limit on the number of debug outputs allowed. Why? Why? ...

angkec 15y ago
That's annoyingly funny. Is there a way to change the limit?
- joe_the_user 15y ago
  You can change the limit for qDebug() maximum message # but like a lot of defaults, it just tends to stay default...
wisty 15y ago
The advantage of hand-rolled loggers is they are easier, for one person, but more difficult for outsiders to get a grip on (compared to a standard solution, which should be well documented). The question is - should other people modify the logging code? If it's just a part of your scaffolding, it might not be a huge issue. It then becomes a trade-off between productivity, and technical debt. Prototypes don't need to be sustainable, they just need to be done. You'll either re-write them, or they will work forever (by some miracle) without maintenance, or most likely end up in the big bit bucket in /dev/null

jroseattle 15y ago

I call this the not-invented-here (NIH) syndrome. Where a seemingly rational developer runs off into esoteric land to add this, that and the other to a system that is used to replace functionality already provided in other well-known applications/systems/constructs/etc. All because they don't know how something works, therefore it's being replaced because it's NIH. Big tech companies are famous for doing this. One of my favorite uses of NIH is to replace something like, oh I don't know -- SQL -- with another query language "to make it easier to write queries". Right. Because SQL is so baffling, that we need to replace it with another syntax. And what will that syntax do? Convert a statement to SQL. I use NIH as a filter in interviewing. If someone cannot appreciate NIH as a productivity killer, I know they generally won't be a good fit for my team.

kaeluka 15y ago
one colleague has been renaming my functions recently: she created new functions that did nothing except calling my implementation. The reason was probably that the name of mine was too general..

bballbackus 15y ago

I think most programmers and engineers have personalities that constantly question their own competency. This is predominantly a good quality as it leads to much more rapid talent development, but it also leads to irrational actions like recreating libraries out of fear that you're "not a real programmer" if you use the work of others.

pragmatic 15y ago

I think this is more appropriate for reddit/r/programming. Nothing earth shattering or really related to go or c specifically...rather disappointing.

scott_s 15y ago

I think you should go one step further. Any time you are switching on a type, you're re-implementing virtual functions. I have never coded in Go, but I know it has interfaces and allows this kind of polymorphism. It looks like your type "sexpr" should really be an interface, and then you would have separate structs for a cons cell, a symbol, number and a string.

tree_of_item 15y ago

>And so we end up re-writing parsers where yacc would do, Had me going until there. Rolling your own parser to avoid yacc sounds like an absolutely splendid idea. Techniques like parsing expression grammars are worth some mild sense of "NIH", and in any case there are plenty of PEG libraries to take advantage of as well.