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 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.
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.
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.
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..
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? ...
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
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.
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.
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.
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.
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.
your code:
now without the redundant type assertions. 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.