Hacker News new | ask | show | jobs
by alkonaut 2961 days ago
Every technology is designed through tradeoffs. Choosing a technology and the using it properly reqires understanding those tradeoffs. What they are, why they were made. I whine about the appetite for secret allocation that my C# program has. I whine about the mess that is writing the equivalent C++ or Go code, and the learning curve of doing it in Rust.

It’s whining on the surface but it’s really 90% tradeoffs and 10% badness.

Being able to critique design mistakes in eg. an API means you have a pretty deep knowledge on the domain (and/or API design in general). Being able to argue the downsides of a certain technological tradeoff (such as GC vs not, dynamic vs static) is also important. No one will be able to win an argument on tabs/spaces or dynamic vs static but everyone should be able to point out some drawbacks and benefits.

Describing the merits of a technology is just as good as describing the drawbacks. I chose drawbacks/whine because (unfortunately) I am myself much more enthusiastic when describing flaws than positive sides - itself a flaw, but a very common one.

1 comments

I see where you're coming from. I think I just don't like the "complain about it" angle.

I can't change the language itself. I feel like a lot of people stress about those issues and can talk about them at length. I'm usually like "This isn't optimal, here's the workaround, this other language does it better but it's got other issues that are even worse for what we're building. Problem solved, moving on." Like, it's just another problem to solve at my problem solving job. The answer is not elegant, but that's the case with so many things in the real world...but this is probably the stoic in me.