HackerTrans
TopNewTrendsCommentsPastAskShowJobs

seti0Cha

no profile record

comments

seti0Cha
·2 ปีที่แล้ว·discuss
Also a slow thinker. I try to make everything asynchronous. In conversations, I let other people talk until my brain has had time to produce something worth communicating. If people ask my opinion before that, I say I'm still thinking about it or I ask questions to get more context and delay needing a decision. Sometimes I start by saying "let me restate what I think the issues are". Often by the time I've talked through the problem, the answer has become clear to me, or at the very least I know what more I need to figure out. I also actually tell people I'm a slow thinker and often say "I'll have to think on that and get back to you". Sometimes that's literally a minute or two later, which must seem strange to them, but that's how my brain works. The results are generally good enough that people think I'm smart regardless, so I try not to worry about it. Possibly there's some anxiety component to the whole thing because not worrying about having the answer in time itself makes it easier to reach an answer.
seti0Cha
·3 ปีที่แล้ว·discuss
Intellectual merit turns out not to have much merit when it comes to software ecosystems. "Worse is better" remains in effect.
seti0Cha
·3 ปีที่แล้ว·discuss
Perl programmers have been making that same argument for literally decades.
seti0Cha
·3 ปีที่แล้ว·discuss
Seems to me like it does work, based on many successful projects using it. There's nothing that forces you to handle the error at the place of origin, you can pass it on like you do with exceptions. You just can't bubble it up multiple levels.
seti0Cha
·3 ปีที่แล้ว·discuss
That's a feature not a bug. Go intentionally forgoes abstractions of that sort. I personally prefer well written Java exception handling, but often Java exception handling code is a bolted on afterthought. Go's approach is to make error handling something you have to think about for virtually every line of code, rather than a superstructure built around the code. This can feel slow and painful to write, but it guides the developer toward considering each error case individually, potentially resulting in more nuanced responses to errors. It also makes reading the code dead simple.
seti0Cha
·3 ปีที่แล้ว·discuss
The younger generations of coders are indeed more susceptible to hype, but if you go around dismissing things that are hyped, you're going to miss out on a lot of good things. I've got 15+ years of Java experience, and I think Go is a nice language and has some real strengths. From what I can see, the primary difference with Java isn't the build system or the binaries, it's the decision to strongly favor simplicity and readability over expressiveness. The payoff for this is that you can jump into any Go codebase and figure out what's going on fairly quickly. You don't need to pull down the source, fire up an IDE and start drawing object diagrams, you can figure out what it's doing by skimming the source on Github. I find this very useful.
seti0Cha
·3 ปีที่แล้ว·discuss
I dislike it because of the ultra-complex build system that over-ambitious devops engineers ended up building in my shop. Our build system was the hardest part of our code base to reason about, which is pretty screwed up.
seti0Cha
·4 ปีที่แล้ว·discuss
What do you think justice means in a "woke" context? My understanding that justice is equity, not equality, in the current jargon.
seti0Cha
·4 ปีที่แล้ว·discuss
Ensuring your charitable donations are actually doing the good you think it is, is difficult enough that there are organizations specifically created to rate them and verify what they say. When a charitable organization does a poor job of it, they rightly earn the scorn they receive, because they are betraying a trust. I donate to a number of charities (including Wikipedia) and if any one of them were found to be operating as it appears Wikipedia is, I would move my money elsewhere, which is what I intend to do in this case.