If you have really done physics or engineering, you would never believe this. Simple and elegant formulas usually can only solve the "spherical chicken in a perfect vacuum" kind of problems. The real world is incredibly messy. Beneath those clean and beautiful-looking partial differential equations lies a mathematical nightmare. And these equations often only hold at certain scales or rely on extremely strict boundary conditions.
Template metaprogramming isn't really suited for this task, the prime sieve here serves only as a proof of concept, meant to show the capabilities of this style. But there are cases where `constexpr` is not applicable, especially when involving type manipulations.
On the other hand, C++ template metaprogramming, as an esolang, is fun to tame and experiment with.
Always has been (I'm over 40). It used to be a nightmare of a programming language, now with all the improvements over time it's merely quite bad. Its power to weight ratio is below any reasonable standard, but sometimes you need the power. Some lunatics like to play with it.
We have seen similar situations countless times before. Just as the Internet allowed people to bypass publishers to release text, and YouTube allowed creators to bypass TV stations and cinemas to release video, AI now allows people to bypass lawyers to read legal texts, which are often deliberately written to be indecipherable to an average person. AI will not destroy institutions, but it will pose challenges and lead to restructuring.
I don't want a Rust language without a borrow checker. I want a C language with a Borrow Checker. Rust's complexity is already approaching C++, and removing the Borrow Checker would turn it into a similar disaster. Austral looks like a good option to me, but it's not mature enough yet, and the Pascal-like syntax is also difficult to get used to.
Although it's a toy not for production, it's very interesting that the idea of traits/concept/typeclass just "emerge" out of the code, which made me suddenly understand why STL come into being.
It's very dangerous to write a http parser from scratch in C. This can be very vulnerable without rigorous testing. To get a useful web framework for production in C, I think it's a better idea to start from libmicrohttpd, libevent_http, or even fastcgi, which are battle-tested.
I hear this comment warnings, and can easily see this myself being true. But, how could one actually make a reasonably safe http server in C from scratch?
That would honestly sound like an amazing book, just walking through all the ways it's horrible chapter by chapter, and how to structure the code instead, slowly. Like an accelerated history to create such a matured http library.
If you have really done physics or engineering, you would never believe this. Simple and elegant formulas usually can only solve the "spherical chicken in a perfect vacuum" kind of problems. The real world is incredibly messy. Beneath those clean and beautiful-looking partial differential equations lies a mathematical nightmare. And these equations often only hold at certain scales or rely on extremely strict boundary conditions.
reply