Go Isn't C

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.

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.

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? ...

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.

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.

>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.

I think this is more appropriate for reddit/r/programming.

Nothing earth shattering or really related to go or c specifically...rather disappointing.

An astounding conclusion!

(Sorry, couldn't resist.)