4 ms·

I appreciate the discussion, but I believe you're arguing in bad faith. > Yes, you can definitely do all of those. But almost no one does <shrug> That's what

I appreciate the discussion, but I believe you're arguing in bad faith. > Yes, you can definitely do all of those. But almost no one does <shrug> That's what you say. What is this based on, considering that until a few hours ago you didn't even know that Java has this built-in code generation facility? When I search for "entity component sytem java", the first hit is this project: https://github.com/Rubentxu/Entitas-Java https://github.com/Rubentxu/Entitas-Java which uses a "code generator [that] generates classes and methods for you, so you can focus on getting the job done. Radically reduce the amount of code you have to write and improve readability. It makes more of a sea code less prone to errors to ensure the best performance." Sure, it's probably not as widely used as other frameworks in other languages. Java isn't necessarily the first thing on people's mind when it comes to implementing AAA games. > and those that do, usually silo themselves from the ecosystem. You have not shown this. And if you mean that your C macro implementations do this -- fine. But you still seem to find them useful enough to keep using them? > Yes, if you like Java, you can definitely implement a Java compiler/interpreter in C and get everything you like about Java using C. That is a Turing equivalence argument. But using a very simple code generator for a very simple problem is not the same thing. Given that Java syntax is very similar to C, I wouldn't be surprised if your existing macros could be used 1:1, with the hardest part being getting a Java build system to call the C preprocessor on a Java file. Not quite the same thing as implementing an interpreter. (Also, as far as I'm concerned this was never about Java per se.)

beagle3 5y ago
I appreciate it too, and I don't believe I am. I wasn't aware it is now an integrated part of the JDK, but it doesn't change much; I've used ANTLR decades ago (and YACC even more decades ago) which is ... essentially the same thing, except Java has now standardized and simplified it so that you don't need to fiddle with your Ant or Maven or Makefile. > Sure, it's probably not as widely used as other frameworks in other languages. I've been doing professional work for over 30 years now, so I think I have some perspective, which may of course be different than yours. Code generators and processors have always had their niches, but that's what they are - niches - and they are quite small. People used to use YACC, or ANTLR or Bison or Lemon or whatever your favorite parsing tool is. That's because they save an enormous amount of work in most use cases where they are applied. But they also come with great costs: Hard to debug when things go wrong, but most importantly - inflexible. GCC and many, many other projects move off parser generators at some point in their life for flexibility reasons. Qt has MOC, which was essential in older C++ and is now IIRC optional because modern C++ has mostly caught up. It is widely hated among Qt users, though it did offer significant advantages. But I'm not aware of any project that used MOC except to interface with Qt - the boundary is always evident. > You have not shown this. And if you mean that your C macro implementations do this -- fine. But you still seem to find them useful enough to keep using them? How could I "show" this? It is obviously predicated on the projects I've been involved with, which - I noted - have not been Java in the last ten years. It's not like it's something that can be "shown", except in some statistical sense, the validity of which we will argue forever. And yes, people shy away from macro heavy C code (whenever J source code or A source code gets posted on HN, people are less than happy, e.g. https://news.ycombinator.com/item?id=8533843 https://news.ycombinator.com/item?id=8533843 ; the whole J system looks like that ). I use macro heavy code only when I don't have to share it with others, for that reason. > But using a very simple code generator for a very simple problem is not the same thing. Well, perhaps we're not thinking of the same level of simple - e.g. c++ template meta programming, which I first used in 1995 is built in, and (literally) turing complete, so it can do anything, but is far from "simple" - not to actually write, not to use, and definitely not to debug. What I had in mind was things like https://github.com/Hirrolot/poica https://github.com/Hirrolot/poica - It uses C macros to do incredible magic. All it needs is one #include and it gives C introspection, oop and a few other things. Is it simple? I wouldn't say that. But more importantly, is it C ? I wouldn't say that, and so does the guy who made it. It can be used in a C program, yes. It can e.g. go further and define comparators for you so you can use qsort() on the new types it helps you define. But it's not really C because when you try to integrate it with an existing C codebase, you'll find that you keep having to translate things at every boundary - which is quite likely to happen with a Java SoA library. I think my point is that languages in common use (Java, C, C#, ...), despite offering the facilities to locally solve the issues described in the original article (locality of reference mostly), they do not practically allow these solutions to become widespread or common because they are not part of the core, and as a result you lose all benefits on library boundaries.

beagle3 5y ago

I appreciate it too, and I don't believe I am. I wasn't aware it is now an integrated part of the JDK, but it doesn't change much; I've used ANTLR decades ago (and YACC even more decades ago) which is ... essentially the same thing, except Java has now standardized and simplified it so that you don't need to fiddle with your Ant or Maven or Makefile. > Sure, it's probably not as widely used as other frameworks in other languages. I've been doing professional work for over 30 years now, so I think I have some perspective, which may of course be different than yours. Code generators and processors have always had their niches, but that's what they are - niches - and they are quite small. People used to use YACC, or ANTLR or Bison or Lemon or whatever your favorite parsing tool is. That's because they save an enormous amount of work in most use cases where they are applied. But they also come with great costs: Hard to debug when things go wrong, but most importantly - inflexible. GCC and many, many other projects move off parser generators at some point in their life for flexibility reasons. Qt has MOC, which was essential in older C++ and is now IIRC optional because modern C++ has mostly caught up. It is widely hated among Qt users, though it did offer significant advantages. But I'm not aware of any project that used MOC except to interface with Qt - the boundary is always evident. > You have not shown this. And if you mean that your C macro implementations do this -- fine. But you still seem to find them useful enough to keep using them? How could I "show" this? It is obviously predicated on the projects I've been involved with, which - I noted - have not been Java in the last ten years. It's not like it's something that can be "shown", except in some statistical sense, the validity of which we will argue forever. And yes, people shy away from macro heavy C code (whenever J source code or A source code gets posted on HN, people are less than happy, e.g. https://news.ycombinator.com/item?id=8533843 https://news.ycombinator.com/item?id=8533843 ; the whole J system looks like that ). I use macro heavy code only when I don't have to share it with others, for that reason. > But using a very simple code generator for a very simple problem is not the same thing. Well, perhaps we're not thinking of the same level of simple - e.g. c++ template meta programming, which I first used in 1995 is built in, and (literally) turing complete, so it can do anything, but is far from "simple" - not to actually write, not to use, and definitely not to debug. What I had in mind was things like https://github.com/Hirrolot/poica https://github.com/Hirrolot/poica - It uses C macros to do incredible magic. All it needs is one #include and it gives C introspection, oop and a few other things. Is it simple? I wouldn't say that. But more importantly, is it C ? I wouldn't say that, and so does the guy who made it. It can be used in a C program, yes. It can e.g. go further and define comparators for you so you can use qsort() on the new types it helps you define. But it's not really C because when you try to integrate it with an existing C codebase, you'll find that you keep having to translate things at every boundary - which is quite likely to happen with a Java SoA library. I think my point is that languages in common use (Java, C, C#, ...), despite offering the facilities to locally solve the issues described in the original article (locality of reference mostly), they do not practically allow these solutions to become widespread or common because they are not part of the core, and as a result you lose all benefits on library boundaries.