71–80 of 85 posts
> we talk about programming like it is about writing code, but the code ends up being less important than the architecture, and the architecture ends up being less important than social issues. A thousand times this! This puts into words something that's been lurking in the back of my mind for a very long time.
Earlier quoted context omitted.
Every time somebody puts "Visual Studio" on the same sentence as "good" I get that strange feeling the Universe is a simulation and other people are interacting here, but do come from a different one. I can't make for any other explanation. I can't think on any interaction with it that I would describe as "good". I can think of a few "minimally ok", but debugging isn't one of them. (But at least on the 2022 the debug…
I don’t like working in Visual Studio much, and I am a big fan of gdb too (and of Chrome’s debugger when working in JavaScript), but for C++ debugging, the Visual Studio debugger is excellent, and has been near the top of the class for a long time, compared to other debuggers. That is the explanation. I don’t doubt there are warts, but for you what’s missing or sub-par from VS that is better elsewhere? What debuggers…
Also, it can fail loudly if it loses the control of the target process or if the target process fails before it finishes connecting. Also, it should not run after the UI reports that it finished.
I had my stint with build systems. Nx, Bazel to name a few. In the past I was always the go to guy to configure these stuffs. OP said that ninja is small enough to be implemented in your favorite programming language. I wonder if there is step by step tutorial to create your own build system?
> ... Where other build systems are high-level languages, Ninja aims to be an assembler.
> ... Ninja is intended to be used with a separate program generating its input files.
> ... Ninja is pretty easy to implement for the fun 20% of it and the remaining 80% is "just" some fiddly details.
There are many ninja generators out there already [1] but writing a simple, custom one shouldn't be too hard [2] and could make sense for some projects.
BTW, ninja is great but I wish the configuration file had used a more standard format, easier to parse and generate from any language. JSON would have been a better option I think, given the abundance of tooling around it.
--
1: https://github.com/ninja-build/ninja/wiki/List-of-generators...
Earlier quoted context omitted.
I don’t like working in Visual Studio much, and I am a big fan of gdb too (and of Chrome’s debugger when working in JavaScript), but for C++ debugging, the Visual Studio debugger is excellent, and has been near the top of the class for a long time, compared to other debuggers. That is the explanation. I don’t doubt there are warts, but for you what’s missing or sub-par from VS that is better elsewhere? What debuggers…
For a start, more speed would be great. It's slow to start, end, and slows down the code so much that it has semantic implications. Also, it can fail loudly if it loses the control of the target process or if the target process fails before it finishes connecting. Also, it should not run after the UI reports that it finished.
What do you mean about so slow there are semantic implications? How does execution speed change meaning? Can you give an example? And are you talking about VS specifically, or just debugging in general? Gdb can be extremely slow when debugging too, and besides that, simply turning on symbols and turning off optimizations can be a major reason for slowdowns.
For the connection issues, I rarely if ever see that with VS. Usually I’m launching my executable from the debugger. I’m not generally doing remote debugging, or attach-to-process debugging — is that what you’re talking about? Certainly all debuggers have those kinds of issues with remote debugging or attaching to processes. Are these issues better in some other debugger you use? If so, I’m certainly curious to hear about it, I would love to learn & use something that’s superior.
This is hilarious to me: Android, which uses it for some large component of the system that I've never quite understood Ninja is really a huge part of AOSP, the build system initially used makefiles. Things got complex really fast with a custom declarative build system (soong) and a failed/aborted migration to bazel. Google developed kati ( https://github.com/google/kati ) which converts Makefiles to ninja build file…
As someone, who has not used Ninja, what advantage is there, compared to Makefiles? And is it worth introducing yet another tool, to translate one to the other? Especially, when the Ninja files are that huge, possibly human-unreadable.
Earlier quoted context omitted.
Source code repos could have USER.md and DEVELOPER.md files to record social context.
But again, that is at best infrastructure documentation, not code. Unless you dilute the term "code" until it loses nearly all utility.
Earlier quoted context omitted.
Not sure if it's the exact research that the author is referring to, but it could be this one: https://www.computer.org/csdl/magazine/so/2023/04/10176199/1...
I don't think anybody talking about "latency" without a qualifier is thinking about build latency. But it's a nice article. The idea that giving-up on waiting for a delay has a simple exponential distribution is something that I never thought. (And now I'm fixed on understanding why... Something must have biased me against it.)
> I also believe that programmers feel latency and it affects their mood even if they don't notice it. (Google has recently done some research in this area that kinda confirmed my belief, here's hoping they'll publish it publicly!) Anyone knows if it happened? Has the google research on latency been published?
This is hilarious to me: Android, which uses it for some large component of the system that I've never quite understood Ninja is really a huge part of AOSP, the build system initially used makefiles. Things got complex really fast with a custom declarative build system (soong) and a failed/aborted migration to bazel. Google developed kati ( https://github.com/google/kati ) which converts Makefiles to ninja build file…
As someone, who has not used Ninja, what advantage is there, compared to Makefiles? And is it worth introducing yet another tool, to translate one to the other? Especially, when the Ninja files are that huge, possibly human-unreadable.
The advantage in android is that the different build systems will generate ninja, so they can interoperate.
Earlier quoted context omitted.
I *really* wanted basically "google class without the frigging camera." Being able to overlay an 80x24 terminal over one of my eyes (and drive it with a bluetooth keyboard or whatever) would've been fantastic for me. Unfortunately for me, this is enough of an outlier desire that it doesn't seem likely anybody will ever want to sell me that at a price point I can convince myself of.
Even Realities is approaching that now: https://www.youtube.com/watch?v=bckifBIPlHI&t=136s
Not sure I can convince myself to spend the money to find out, but they're definitely going in the direction I was thinking of.
Ta.