Chabs

The Something Awful forums is the obvious candidate here. It costs a flat 10$ to create an account. This generally makes trolling, spamming and scamming a losing proposition and broadly helps with the signal to noise ratio.

It traditionally leads to bigger executables and longer compile times. With modern compilers, both of these are non-issues for "most" reasonably-sized projects.

Welp, I was not expecting this to show up on Hacker News so early in the project's life cycle.

This is still fairly early work, so I apologize if the API is not quite as neat as it could be yet.

Still, author here, I'll gladly accept any comments/criticisms.

Unfortunately, you can't leverage template substitution rules with the lambda approach. And that's really necessary if you want to have actual powerful match expressions.

std::visit mostly allows you to do that already:

https://coliru.stacked-crooked.com/a/be5c44281eea8bc4

Then only unfortunate missing piece of the puzzle is that there's no trivial way to create a closure out of this, so it requires a bit more manual work to propagate local state to the visitor.

My gut feeling is that yes, this is pretty much self evident.

However, the interesting part of the paper is that they use that equivalency to propose that properties of polynomial regression are applicable to Neural networks, and draw some conclusions from that.

If I'm reading this right, the core of the argument is that since any continuous function is can be approximated via a taylor series expansion, then activation functions can be seen, in-effect, as polynomial in nature, and since a neuron layer is a linear transformation followed by an activation function, the the whole system is polynomial.

That's "technically" correct, but it feels like an academic cop-out. Interesting/useful transfer functions tend to be functions that take very large expansions to be approximated with any accuracy.

We are talking about a language that goes so far as to make sure it functions on systems where the size of a byte is not 8, or where memory is not necessarily linearly addressed. People tend to forget how shockingly flexible standard-compliant C++ code actually is.

That's handled by the preprocessor. It's literally just a "insert the contents of that file here" copy-paste.

C++, as a language, has never cared about the notion of "files". The entire standard is defined as a function of a "Translation Unit", which is an abstract notion that we tend to associate with "a single .cpp file" by nothing but convention.

Since modules operate at the language level, they need to operate on this notion, which precludes importing by file.

Hot take: success is almost always accompanied by a healthy dose of survivor bias. For each of these success stories, there are a lot of good people who did the exact same thing, but it didn't pan out because of timing, location, or other similar factors.

constexpr variables must have a literal type, which requires a trivial destructor.

The most egregious thing for me is:

> in other words, the reader is expected to understand the semantics of an unknown function without consulting the declaration (or documentation).

The idea that the author considers making code as self-documenting as possible at the call site a conceptual mistake is just weird to me.

Speculation: GPU-based text rendering is typically going to be done using two triangles per glyph. So what they are seeing is probably not the allocation of the underlying texture storage, but the transient vertex buffer that contains the information of which glyph to render and where to render them.

> All in all, OOP is a toolkit for building bad abstractions: abstractions that do not easily model computation, that hide data.

That's a fundamental property of type erasure, which is not exclusive to OOP, and far from the extent of what modern OOP is about

I didn't mean rust was fundamentally OOP, but that rust implements, through runtime traits, exactly the behavior you are criticizing OOP for. Sorry about that

I think you are conflating OOP with type erasure. Most OOP languages support type erasure (including rust!), but that's far from all there is to it.

Frankly, having User inherit from DBMapper is way more egregious in my eyes than Sword inheriting from Weapon.

It doesn't really matter because both of these things can be better solved using composition + traits/interfaces anyways.

But that's the whole point of JAVA. It's an opinionated platform with a hyper-standardized workflow. Sure, that limits creativity, but in many business contexts, the last thing you want is your programmers getting "cute".

There's a straight line from requirements to implementation; no meandering involved. At least that's the theory. In practice...

One thing that I'm surprised this doesn't cover, especially since it's so C++-centric, is that modern C++ OOP is much more defined by lifetime/scope management than anything else. What defines something as an object is the fact that it doesn't exist until it is constructed, and doesn't exist after it gets destructed (which is the case even for fundamental types, with the exception of char/std::byte, btw).

Hot take: RAII has basically taken over everything else as far as structural design foundation goes. Type erasure and encapsulation still play a role, but it's not nearly as fundamental anymore.

Information as actual physical property (as opposed to a human construct) is basically the only way we found to solve Maxwell's demon seemingly reducing entropy.

Specifically, the entropy within the box gets converted into information inside the demon's "head", which eventually gets radiated away as entropy outside the box. This way, the box's entropy falls, but the entropy of universe as a whole is raised (or at least maintained).

Long answer short: Information has to be a fundamental conserved property of the universe for the second law of thermodynamics to work under some thought experiments.

Outside observers never see the material cross the horizon, ever. That's why it's called a horizon, you'll never reach it (from the pov of an outside observer).

Growth-wise, you have to keep in mind that the black hole doesn't grow when matter crosses the horizon, but when the matter gets close enough to the horizon that mass of black hole + mass of new matter creates a blackhole of a larger radius that encompasses that matter.

To elaborate, ASIO is arguably the de-facto standard way to do low-level networking in C++, to the point where it forms the basis for the standard library's upcoming networking library.

I think you are misunderstanding my question. I am not suggesting that ASIO fills the role your library does. All it is, really, is just fancied-up cross-patform select().

What I'm wondering is: Is there's a specific reason you chose to reinvent that specific wheel?

What is the rationale behind going for from-full-scratch instead of packaging a copy of ASIO with the library? Beating properly-used ASIO performance is going to be a massive uphill battle, especially in multithreaded scenarios.

On that note, benchmarks against a simple ASIO http server are a must if performance is your #1 stated goal.

Expression templates (ala boost::spirit) definitely come to mind. The callstack in a -O0 build can get very, very deep.

Heck just using std::numeric_limits<int>::min() will incur a function call in -O0, but nobody cares since it gets optimized in -O1 and up. The same thing applies more and more as you invoke templates from templates, but, again, nobody cares since we are confident it'll get optimized/inlined easily.

It's not nearly as prevalent in modern code since constexpr static variables are now a thing, but relying on these optimizations has historically been super important.

I'd like to introduce you to the wonderful world of templates.

OP's point is the other way around. They are wondering if Mozilla can afford the financial hit of not getting that money from Google anymore. If Google leaves that space, then Bing won't have real competition here, and will pay substantially less.

I'm mildly surprised to see the NSA using malloc instead of calloc, especially for allocating what seems to be a partially initialized struct.