enhray

No piece of art exists without context. With AI there is no context, no meaning, no relevance. A pretty image by itself is just that - a bunch of bytes displayed on device of your choice.

There are also such things as art direction, vision, and style. Even if AI can mimic style with style transfer, it will never achieve greatness this way.

You can apply an AI-powered “Starry Night” filter to any picture, but do you really think Van Gogh would draw something like that?

There's nothing "on par" when it comes to C/C++/C#, and these three languages are still quite big in non-web world.

For C/C++ on Windows and Linux. CMake build support and cross-platform builds and debugging are available out of the box with Community version of VS.

Native macros were never supposed to be used that way. If anything goes wrong, you still have to deal with that, and no IDE will save you from having to invoke your compiler with “preprocess-only” flag to see what you’re dealing with. Been there, done that, don’t want to do that ever again.

Compared to that, debugging generated code is a breeze.

Also, there’s no “third-party” generators - everything just lives in your own source tree. If I ever need to go meta, it’s just a printf away; I can even commit the generated files to my VCS and be able to see what had changed in them between commits in a simple and understandable diff.

Regarding the integration, I’ll take setting up an additional build phase (once) over having to debug C macros any day.

The C preprocessor is definitely ill-suited for metaprogramming, but it was never the C way, was it?

The traditional way to do any kind of meaningful metaprogramming in C is just a printf() to a .h or .c file which then is included to your build.

There are a lot of projects doing that. Bison is supposed to be used this way, other projects are doing build configuration like that - by emitting a header with a ton of #define’s, and there’s a ton of languages which use C as a compilation target - and you can see what they are doing and get inspiration from that.

In my opinion it’s an extremely powerful model, much better than anything you can do with the preprocessor.

This is a great idea! However, I highly doubt that they will disclose this information.

Switching to a personal email domain and another credit card did the trick, at least with the DigitalOcean.

Theoretically, someone could exploit a vulnerability in the SS7 [0]. I’m not sure how common these are in the wild, but it had happened before.

[0] https://en.m.wikipedia.org/wiki/Signalling_System_No._7

Ruby? Of all of the scripting languages out there, I find most suitable to write small scripts to transform complex text to something more suitable.

An example to prove your point: Flipboard determined that our current rendering engine was too slow for their needs and implemented their own rendering engine on top of ours while retaining the rest of the browser infrastructure.

[0] https://engineering.flipboard.com/2015/02/mobile-web

Beware the m_pszSlipperySlope [0].

[0] https://en.wikipedia.org/wiki/Hungarian_notation

I think it’s the other way around. Instead of redefining operator new() to allocate from an arena, user allocates memory from the arena and then constructs instance there using placement new.

SQLite has “virtual tables” feature [0] which was designed exactly for this use-case.

Edit: and that Facebook project is called OsQuery [1]. It was built on top of SQLite virtual tables and is listed in their implementations list.

[0] https://www.sqlite.org/vtab.html

[1] https://osquery.readthedocs.io/en/stable/

Why do you want it in C? What are your use cases?

I’ve always thought that idiomatic C for constexpr would be to write the code you want to be executed at compile-time in a separate file(s), build it, execute and then #include the result in your program before building the final executable, adding a build step but keeping overall complexity minimal.

This is different from C++ approach, where everything and the kitchen sink is added to the standard and then you have to issue errata for errata for the standard and hope that the compiler you have to use for your current platform is keeping up for the last changes.

I don’t think that this bugginess is an inherent property of these languages, because there are other practices that could lead to reduction in total bug count and severity, apart from integrating additional tooling.

Out of curiosity, how many bugs you found by using these tools could have been avoided by using a “watertight” memory management system [0], with strong decoupling of pointer and object lifetimes?

[0] https://floooh.github.io/2018/06/17/handles-vs-pointers.html

I’ve heard horror stories about reference counting performance cliffs caused by avalanche deallocations, which are hard to predict.

This is a very good intro to K-D trees, big thank you to the author. However, I think that a three-dimensional lookup table would be more performant in this case. 16M (256^3) of entries are needed to cover RGB color space with 8 bits per channel, that's a lot, but lookup time is O(1) with a very small constant.

When I started dabbling in programming languages design, Parsing Techniques - A Practical Guide was invaluable for me. I cannot recommend this book enough. First edition is available for free from one of co-authors site [0].

[0] https://dickgrune.com/Books/PTAPG_1st_Edition/

Edit: minor clarification.