simplotek

> Yes, it's a separate little preprocessor binary instead of using C++'s built-in macro system, but the concept itself is not foreign to C++.

It does have it's drawbacks. The MOC heavily penalizes build times, and build caching tools like ccache don't work out of the box with it. So not only does the MOC worsens builds, it also prevents basic optimizations from mitigating it.

> Compared to the crazy stuff Microsoft has done over the years (...)

Microsoft did a fantastic job with it's GUI frameworks. WPF is a stellar example of getting most things right. It's astounding how views are so trivial with WPF. XAML voodoo has it's critics but no one praising Qt would ever dare point a finger at XAML.

> The scope of HTML/CSS shifted vastly.

No, not really. HTML was from the start and always has been designed to specify UIs. From the very start HTML had support for specifying UI element trees, including higher-level UI design patterns like buttons, combo boxes, radio buttons, etc, and also supported running scripts as part of events triggered from those UI elements.

> Most added features solve real problems.

That's debatable, both with regards to "solve", "real", and "problems".

CSS sounds like the poster child of feature creep. It started as the right way of specifying styling (colors, fonts, line weights, spacing, etc) and now it's so extensive it looks like it's competing with OpenGL.

> This process, while obviously is much slower on spinning HDD, it surprisingly isn't really that fast on NVME SSD, either.

Windows is renowned for having awful performance in usecases involving accessing many small files even for read-only applications. I know a team that even went as far as testing switching away from Windows to build Windows apps and instead switched to cross-builds on Linux just to avoid that performance sinkhole. Meanwhile I worked on a multiplatform project where macOS builds on a Mac mini for the exact same project took less than half the time to build than on a beefed up Windows workstation.

Here's an interesting discussion on HN from a couple of years ago on this topic.

https://news.ycombinator.com/item?id=18783525

> (...) they’re nearly equivalent if you have a good team that (...)

That's a lot of hand-waving weasel words to blame those experiencing problems for the naturally occurring problems.

If it was the same thing, we would not be having discussions on their pros and cons. This is not a team-specific issue.

> Note that MPAs can also opt-in to prerendering, where the browser spins up a hidden background tab (sort of) that renders the next page, and then gets activated when the user clicks a link. This gives truly instant-feeling navigations.

I recall Opera doing this sort of thing around two decades ago. It had a setting to aggressively cash all links, and navigating between those was instantaneously.

Is this what Chrome does?

> Almost any country does.

Spain provides 6 weeks of mandatory paid parental leave that come into effect once the child is born, and an additional 10 weeks to be used during the year.

> What everyday UI thing is better done with this than other methods?

All of them.

> Why is it better?

Because it specifies a workflow that actually matches what you want to do instead of employing a pile of ad-hoc rules that quickly become an unmaintainable mess.

If you have animations and async calls and multiple screens/pages, you have an application with application states which transition in response to inputs. That's what state machines are designed to handle.

Storyboards are state machines. Navigation components are state machines. UI binding layers like redux are state machines.

> Wow, being sarcastic about AI! (...)

OP presented a clear and insightful comment on these critiques of AI.

You, on the other hand, added zero to the discussion.

If you have nothing to add, add nothing.

> and then immediately scrapping and recycling it

You seem to be confused. Using steel as a raw material is not "scrapping and recycling". The value of steel in engineering applications is that you can trust that the properties of a particular alloy used to make a particular part will comply with the specs. Steel from China is renowned for being unreliable and failing to comply with standardized properties.

https://www.cdmg.com/building-faqs/why-using-cheap-steel-is-...

You avoid that risk by importing steel as a raw material and use that to actually produce reliable steel. If low-quality steel is cheap enough so that after recycling it you can still make a profit then it's a sound business decision and the whole economy benefits.

> Octopuses have demonstrated significantly more intelligence than cows.

I fail to see how this is has any relevance. The ethical or emotional argument of killing an animal does not depend on vague assertions over the problem-solving skills of said animal.

Meanwhile I feel your blend of arguments is terribly disingenuous for the way they avoid facing the fact that people eat animals in general and octopuses in particular.

> We should either require this for all buildings or for none.

You do understand that "requiring this for all buildings" has a name: urban planning. This sort of analysis is basically what engineers do when assessing the environmental impact.

> Just don’t eat octopuses, please.

I don't see any difference between this and, say, kill cows.

Also, the news piece sounds too desperate in it's attempt to appeal to an irrational emotional response. The author goes to the ridiculous extent of claiming that

"the operator intends to kill [octopuses] by submerging them, alive, in freezing water."

I mean, isn't "being alive" a key precondition to kill an animal?

> If you take "raw" steel and process it, you can look green from your operations...

I'm not sure the people complaining about Chinese steel imports are thinking about environmental footprint. It's all a chain of simplistic economic reasoning to complain that they import a product instead of producing it.

> It's just that I really really hate maintaining Makefiles and CMake configs.

CMake is a high level makefile/build system generator.

There is nothing to maintain in modern cmake. You just set what executables/libraries you want to build, set their dependencies, and you're done.

And of all alternatives you chose to push, you pick Bazel of all things? Feature-incomplete and requiring all sorts of low-level maintenance?

> such a build graph

Nonsense. All build systems implement a DAG of build targets.

> why caching tools can't be used effectively

Nonsense. There are a myriad of caching tools freely available, from ccache, sccache, build cache, etc. To get them to work, all you need to do is pass compiler launchers to them, which means setting a single env/build flag.

The author is either trying hard to make a mountain out of irrelevant molehills, or is outright being disingenuous.

Bazel is being sold as a solution desperately grasping at straw-like problems, while being feature incomplete.

> (...) brought to the USA, melted in an arc furnace, and suddenly it's "made in USA"!

I don't think this assertion makes sense. Making steel is way more than getting iron and mixing it up with some carbon. You need special manufacturing processes to get specific alloys and treatments to get the properties and reliability you expect. Recycling and importing steel is like importing a raw material.

Your comment reads like "This let's them do things like claim burger made in USA when in fact the burger buns were made with corn from Ukraine and meat from Argentina".

> In addition to the problems stated in the article that you're ignoring here

What problems, exactly? The author acknowledged cargo works but hand-waves over vague claims of "it does not track dependencies well or support arbitrary build graphs", followed by acknowledging those issues are either non-issues or solved problems whose solution was dismissed without any good reason (caching tools).

The author's claims boil down to "I wanted to shoehorn Bazel but had no good reason to, so I double-down on Bazel's only selling point while ignoring everything".

It's ok if anyone just wants to try stuff without having any rational or coherent argument to justify it, but let's not call that "problems".

> Code coverage is pretty well supported in the internal ecosystem (...)

What you're actually saying is that internally Google managed to get a single and very specific use case to work and forced all projects to either adopt it or have no code coverage.

> But the open source world has the resources to write new build systems (and ecosystems!) time and time again.

What leads you to believe that writing new build systems is a popular hobby?

I mean, cmake is the de facto standard for C++ projects and it has been for what? Over a decade? What does this tell you?

You have people in this discussion claiming otherwise, and I also know for a fact that in the past it did not supported either.

Can you actually provide a working example?

> I mean for C++ having the caching just work like you get with Bazel is a huge thing.

It's a good thing then that cmake+ccache work out of the box by passing the caching tool of your choice like ccache to the compiler launchers.

> Every time I have to learn a new build system in open source work I groan. Why are there so many systems for essentially the same thing?

I'd love to hear what leads you to believe that adding yet another build system in the form of Bazel would solve that problem for you.

> You can get coverage working for almost anything by having each test convert its coverage data to LCOV before stopping, in the same sandbox as the test.

I have to call bullshit on this. With C or C++ you need to build the whole project with specific compiler flags to be able to generate code coverage reports. This is not something you implement by tweaking a setting in unit tests.

> We had a googler at our company switch everything to bazel and it just slowed everyone down.

I'd love to hear if anyone can make a case for Bazel knowing that cmake+build cache tools like ccache buy far better performance improvements than any full or incremental build.

> No Make is not a replacement, or ninja.

Why?

The world has been running on make for decades, and it runs just fine. Meanwhile, does Bazel support basic stuff like shared libs or vended libs that are not deployed system-wide? Last time I checked, it didn't.

> its about ALL of your organizations languages being built with one tool,

Yeah, that's an effective way to sell someone's promotion, but it's always a promise that is never met and instead it's a constant source of problems.

Sometimes reinventing the wheel just buys you a wobbly, squeaky wheel.

> For the love of god, please Google what fizzbuzz is.

Yes, please do google what fizzbuzz is. You'll eventually stumble upon resources on how to memorize fizzbuzz, which is such a Hallmark of the test that it's even explicitly mentioned in the C2 wiki on fizzbuzz.

> For Christ sake. There was never any need to memorize fizz buzz,

Wrong. Fizzbuzz is the epitome of a hiring test that is gamed by rote learning and adds absolutely nothing in terms of decisive info on wether s candidate is competent or not.

Your argument is like arguing in favour of using hello word in as many languages as possible and then claim that there is no need to memorize them because that's the point of the question.

> Fizzbuzz basically just tests you know how to use a conditional, do division/mod, and print to console.

No, fizzbuzz test rote learning and it mainly serves to game the hiring system.