41–50 of 167 posts
Oh no... so far the most terrifying title I've seen in HN this year. By the way, it's impressive how they even managed to multithread this.
Someone might be working on an article even worse: list of things that raytracers haven't been written in (yet, regularly updated)
I remember writing a ray tracing in 1994 in Turbo Pascal 7.0 running on 286 under DOS 4.0 at the time. I did it with floating numbers, pure mathematical implementation. When it came to usability was something like 1 frame every 30 seconds for resolution of 640x480 with 256 colors only. The problem with ray tracing isn't writing one, the problem is its usability, to get the most realistic AND fast enough. Mine was ver…
Yeah that was a very long running joke about ray tracing: “real-time ray tracing is only five years away... and always will be”. ;)
> The problem with ray tracing isn’t writing one, the problem is its usability, to get the most realistic AND fast enough.
Times sure have changed eh? 640x480/30s is ~ 10k rays/sec. Now we have ray tracing GPUs that can do well over 10B rays/sec with full floating point. More than a million times faster, not even counting precision & scene size, crazy right?! I’m working in the field and still blown away by what people are doing in real time in the last few years, fully path traced scenes with global illumination that are hard to distinguish from photographs...
Earlier quoted context omitted.
What's wrong with CMake?
The language is extremely error prone. It's like they looked at Bash and thought "hmm, too safe". Everything is a string, even lists are just semicolon-separated lists. The argument expansions rules for calling functions are literally impossible to remember. All variables are implicitly defined as empty strings. Typos silently break things. `if` is completely broken. The separation of the configure step from the buil…
I'm confused. How do you propose CMake supports all those build generators without doing this?
(PS. I really don't think the syntax is that bad, aside that it is jarring for C programmers, most complaints are overblown and you get used to it once you learn the rules. It might be interesting if someone made a CMake variant with a less obscure syntax but I don't see much motivation for that to actually happen)
Well well well, we finally found something CMake can actually do. Please, everyone, stop using CMake. It doesn't do its one job.
The scripting language is bad, most cmake scripts are much more complex than they should be, but cmake does a lot of things under the hood that make multi- and cross-platform development easier (for example: being able to build with the Visual Studio compiler without running in the "Visual Studio Developer Command Prompt"). A lot of fancy new build tools don't even have proper Windows support.
Take autotools. You get EXACTLY what it did, and you see why it failed. With CMake it just goes "you don't have X installed". But I do. It's right there. CMake refuses to say under what cmdline or whatever it tried, and what the error was. Just "X IS NOT THERE!".
And then it depends on some version of cmake being installed, which it may not be.
I don't do windows coding, but shouldn't autotools be more viable now that Windows ships with bash?
But even if not, CMake stuff as a rule is not even portable between different flavors of Unix, so why even use CMake if it's only going to work on Ubuntu more recent than 18.04 or whatever? It's not a silly suggestion. OpenBSD generally just has raw Makefiles.
Well well well, we finally found something CMake can actually do. Please, everyone, stop using CMake. It doesn't do its one job.
If you’re going to tell us what not to use then at least suggest an alternative.
If you like CMake more, that would be a good argument if CMake worked. But it doesn't. So in the choice between the thing that works, and the thing you may like more, please do go with the one that works.
E.g. this comment I just wrote: https://news.ycombinator.com/item?id=25702345
Earlier quoted context omitted.
The scripting language is bad, most cmake scripts are much more complex than they should be, but cmake does a lot of things under the hood that make multi- and cross-platform development easier (for example: being able to build with the Visual Studio compiler without running in the "Visual Studio Developer Command Prompt"). A lot of fancy new build tools don't even have proper Windows support.
I keep running into CMake based things not being portable, and being broken. And pretty much every single time cmake fails, it does not have ANY log AT ALL of what it did, and why it thinks libfoo is not there. Take autotools. You get EXACTLY what it did, and you see why it failed. With CMake it just goes "you don't have X installed". But I do. It's right there. CMake refuses to say under what cmdline or whatever it…
Earlier quoted context omitted.
The scripting language is bad, most cmake scripts are much more complex than they should be, but cmake does a lot of things under the hood that make multi- and cross-platform development easier (for example: being able to build with the Visual Studio compiler without running in the "Visual Studio Developer Command Prompt"). A lot of fancy new build tools don't even have proper Windows support.
I keep running into CMake based things not being portable, and being broken. And pretty much every single time cmake fails, it does not have ANY log AT ALL of what it did, and why it thinks libfoo is not there. Take autotools. You get EXACTLY what it did, and you see why it failed. With CMake it just goes "you don't have X installed". But I do. It's right there. CMake refuses to say under what cmdline or whatever it…
I always end up vendoring the dependencies, because it's too tedious to find the correct installed libraries in a cross-platform way.
autotools are great, but at the same time it's a monstrosity, and easy to misuse (you should never commit the configure script, because it's the autotools that are supposed to generate it according to the platform it's running on).
For C++ dev, I did take a look at buck[1], but it doesn't really support Windows platforms.
I wish we had something like cargo (IMHO, the tooling is one of the top reasons of Rust's success), in the meantime simple Makefiles do the job perfectly.
Earlier quoted context omitted.
The language is extremely error prone. It's like they looked at Bash and thought "hmm, too safe". Everything is a string, even lists are just semicolon-separated lists. The argument expansions rules for calling functions are literally impossible to remember. All variables are implicitly defined as empty strings. Typos silently break things. `if` is completely broken. The separation of the configure step from the buil…
>The separation of the configure step from the build step is needlessly confusing and makes some things impossible. I'm confused. How do you propose CMake supports all those build generators without doing this? (PS. I really don't think the syntax is that bad, aside that it is jarring for C programmers, most complaints are overblown and you get used to it once you learn the rules. It might be interesting if someone m…
I do fantasize about a new Cmake frontend implemented with Tcl scripting. That would be far more consistent and flexible and you can disable much of the language by default to minimize footbullets then allow commands to be reenabled for times they're needed.
Earlier quoted context omitted.
Someone might be working on an article even worse: list of things that raytracers haven't been written in (yet, regularly updated)
There are even Excel ray tracers out there