1,581 karma · joined October 22, 2022
This. PRC's talk of "reunification" reads like a trojan horse played with a long hand which was what happened in HK.
I'm not sure your false dichotomy holds. The definition of resume driven development is not whether there's a business case of not for a change, and the definition of legacy system is not the cost of upgrading it.
> Why are we switching to JS-Framework-De-Jour? Why are we using this graphdocumentjsondistibutedimmutablelog database all of a sudden? How does this improve the business? How do see a path to a positive ROI from this decision?
False dichotomies. You're assuming that not maintaining your software is free from cost or business impact, and you're assuming that switching to the latest and greatest does not bring any operational advantage.
OP is not the exception. I have at least two playgrounds in a 300m radius. Perhaps I'm lucky but I don't recall ever living in a place that didn't had at least a playground in walking distance.
In your opinion, what's so wrong in prefering to just run your JS/TS code without having to maintain a build/bundling step?
To me, Deno's approach is undoubtedly a killer feature with regards to the status quo of the whole nodejs ecosystem. Don't you agree?
What do you have to say about the fact that apartments are the only option?
It feels to me that you're trying to depict not living in a nice suburban villa as subjecting children to abuse, as if this was a whimsical decision of egotistical parents.
Meanwhile, moving to the suburbs is a luxury that's way out of the reach of working class families, not to mention the fact that outside of the US it's outright unthinkable.
And all the time wasted commuting is not considered abuse why?
To me it reads you're claiming "let them eat cake", followed up by "not letting children eat cake is anti-children."
If you're really interested in the impact of performance issues on everyday life, you need to provide concrete examples instead of putting up unverifiable strawmen.
The truth of the matter is that 99% of real world applications run just fine, and it doesn't pay off to invest in shaving milliseconds here or there. Would it be desirable to have a magic wand to improve some edge cases? Yeah, why not? Is it worth to pay people to spend time with a stopwatch at hand to shave off these milliseconds? Not really. It's all about tradeoffs, and there is no real world payoff in wasting developers' time to shave off that millisecond here or there.
If you can't recognize the percent where it matters a lot, clearly that percent does not exist and you're bothering about nothing.
I see a lot of talk about the importance of tuning Formula 1 cars in a world where everyone drives ford fiestas.
I feel you're missing the whole point.
It's immaterial whether anyone can get to optimizations that compound multiplicatively. The whole point is that halving something that costs nothing earns you nothing. That's the whole point. Go ahead and shave off that millisecond. Will anyone actually notice whether you add or remove that penalty? Odds are, not at all.
You attempted to present an argument that's a textbook example of an hyperbolic fallacy.
There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time".
This blend of specious reasoning is the reason why the first rule of software optimization is "don't". Proponents of mindlessly going about the 1% edge cases fail to understand that the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing, with a tradeoff of producing unmaintainable code.
The truth of the matter is that in 99% of the cases there is absolutely no good reason to run after these relatively large performance improvements if in the end the user notices absolutely nothing. Moreso if you're writing async code that stays far away from any sort of hot path.
What are you talking about? I use Clion just fine regardless of compiler.
> GUI frameworks, hot code reloading, among lots of other goodies.
Do you understand that those features have absolutely zero to do with compilers?
To me that means absolutely nothing, as visual studio and msbuild fails to support basic features like compiler launchers, which enable using compiler cache tools like ccache or sscache.
While you're benchmarking compilers, I plug ccache and build projects with dozen of subpackages in under a minute with build servers maxing out on IO.
I feel this is a red herring.
People use AppleClang because it ships with Xcode and is integrated with it. Those who are stuck with Xcode will not choose msvc's support for C++20 as a good enough reason to drop everything.
With Clang, the main differences with MSVC boil down to a couple of minor features that are hardly showstoppers, such as simplifying implicit lambda captures.
Between being able to use clang and all it's tooling and being stuck with msvc, using clang is far above in importance.
I dare say that one can go through a whole career as a software engineer without spending a single semester learning about algorithms, in the sense that you just start learning about them in a JIT fashion if/when they become an issue, which is rarely.
Some of the O(X) trivia so much sought after in some interviewing circles is even fundamentally wrong when real world aspects such as problem size or CPU architecture come into play.
I mean, he might still have been extremely racist, but it's strange how he recently came off the hinge and out of the blue decided to just spew all kinds of extremely racist statements and conspiracy theories.
Irrelevant. The whole point is that cmake 3.0, which was released in 2014, is an entirely different beast. See "modern cmake".
It makes no sense at all to argue thing about stuff just because you used something two decades ago. Totally irrational.
Does this feel even remotely reasonable to you?
This take sounds ridiculous. It's ok if you want to use the project to try to drive up the adoption of a build system, but it's absurd to argue against the adoption of a widely established build system by stating that people should instead use other IDEs.
Unless you have any data supporting your personal belief, it hardly sounds rational to try to reject objective data just because you don't like it.
Your statement makes no sense and reads like you have an irrational axe to grind regarding cmake.
CMake is just a way t provide high level descriptions of your project and from that generate a build system of your choosing. It does its job well and better than any alternative. Making random claims like "outdated" is meaningless, specially as you can use cmake to generate Ninja or visual studio projects.
This statement alone automatically eliminates any credibility from what you said. CMake was revolutionized with CMake 3.0, which was released in 2014. Since then CMake became a radically different build system, and got so many things right it became the de facto standard.
Also, CMake is a build system generator. It's just a high level specification that generates build systems that you pick, like make, ninja, even visual studio and Xcode.
They have. You'll be hard pressed to find anything other than CMake on any professional project.
Even Qt has migrated to CMake in spire of having developed make.
This was the very first time I ever heard of BUSY, quite frankly.
If you bitch about how "this food is terrible" but you do nothing to make it more palatable or order something else and instead just stand there eating while complaining and reordering and asking for seconds... The food is not terrible, and you just enjoy bitching.
Talk is cheap. If even that same critic feels that his solution to his problem is not worth pursuing, the criticism adds nothing and creates no value. At best it's nitpicking about stuff that falls in Eisenhower's "not important"/"not urgent" box.
Who are they, exactly, and why haven't anyone from that mountain thought it would be a worthy investment of their time to pull it off?
I see you complaining that people have to implement things, but why has no one ever implemented the thing you perceive to be so invaluable?
I don't simply due to the fact that no one ever bothered to put something together on UNIX-like systems that resembles any of those options.
If anyone felt that those were worthy ventures, in these last few years we would already have seen something resembling that effort. But we haven't.
Opinions don't really matter. Solutions to real-world problems do.
To me, the fact that no one up to this day felt that the issues in this area was significant enough to warrant a fix or an alternative tells me that it's noise about nothing.
This opinion piece is the epitome of a negative impact work. It's easy to accuse random things of being all wrong, but it's far harder to actually present something you feel is right.
You're telling me you don't see "why not rewrite it in Rust" posts in a forum dominated by people who are enthusiastically working on Rust codebases?
In the meantime, you did noticed that RiiR is already a meme, didn't you?
The issue is not verbosity. It's the needless addition of nesting levels and independent expressions in a non-idiomatic way, which greatly increase the cognitive load of checking a single row of chained predicates. It's bad code.