Go Isn't C

http://iottmco.wordpress.com/2011/12/01/go-isnt-c/

by srl • 15 years ago

76 25 15 years ago

iottmco.wordpress.com

1010010101013• 15 years ago

An astounding conclusion!

(Sorry, couldn't resist.)

1010010101013• 15 years ago

There we go again. Sense of humour is penalised on HN.

srl2• 15 years ago

I'll give you a pity upvote.

It's not sense of humor that's penalized, though. It's comments without content. (Generally.)

rkalla• 15 years 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.

itmag2• 15 years 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=3299170

timtadh• 15 years 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.

srl2• 15 years 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• 15 years 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)

andrewflnr• 15 years ago

  Programmers not understanding their tools is a long
  studied problem with no good solution.

As is the problem of programmers not trusting their tools. I think they're both still worth writing about every now and then. In fact, that might be the closest thing to a solution we have. Hopefully every time you bring it up, a few more people get it.

joe_the_user2• 15 years 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• 15 years ago

That's annoyingly funny. Is there a way to change the limit?

joe_the_user2• 15 years ago

You can change the limit for qDebug() maximum message # but like a lot of defaults, it just tends to stay default...

wisty• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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_s2• 15 years 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• 15 years 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

Related Stories