I am a big fan of learning LISP, at least once. Going through SICP after more than a decade of writing code for a living was probably the single best thing I did to deepen my understanding of a lot of compsci concepts, data structures, and how to think about software. For me, at least, it was very much a seeing the matrix for the first time kind of moment. My LISP use has quickly declined, but I've dabbled in dozens of programming languages since then, and I do attribute not feeling lost to that experience.
Indeed I have 3D assets in this case. Would this be done differently in an enterprise that has all kinds of tools to manage specialty workflows? Sure. Do I want to spend my days configuring and maintaining some binary blob / LFS storage system? No.
I’ve migrated a lot of projects from fossil to git eventually, but I dare say they never would have made it that far, had I started out with more friction, including fighting vcs tools.
I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab.
Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of not getting it to work, I just thought screw it, I'll drop everything into fossil, and that was it. I have my issue tracker and wiki and everything, though admittedly I'll have some friction later on if I want to share this project. Not having to deal with random git-lfs errors later on when trying to merge commits with these large files is a plus, and if I ever want to, I can fast-export the repo and ingest it into git.
This is probably a longer discussion, but PM0.3 (anything less than 0.3 microns) is quite difficult to measure, especially optically, as light scattering drops off very steeply once your particle sizes are around the wavelength of the light being used. Anything short of an SMPS class instrument that “grows” small particles through condensation so that they appear large enough to be counted, will not see much below 0.3 microns. Also, the total MASS of small particles might be low, but if you look at count, or lung-deposited surface area, we get a different picture. Especially around 0.3um, particulate matter is prone to get deep into the lungs, instead of being caught in the upper airways, and the small size means larger relative surface area, and thus higher reactivity. Even smaller nano particles might not go as deep, but are more likely to enter cells or the bloodstream due to their minuscule size.
While I admire the efforts of the SC-AQMD, and generally agree with the article, using R2 from a higher-end, but not quite perfect instrument, can be quite misleading, and is not a great indicator of actual sensor performance. Also, there are a lot of potential improvements in sensor tech, but instead almost everyone is relying on the same cheap sensor modules instead of innovating, which have have pretty bad deficiencies, especially in detecting particulates in the ultra-fine range, and don’t age very well. But, they are the cheapest.
I kind of went the other way as github/gitlab took off. I was using fossil for years because it was so self contained with issue tracking and everything, and it is great, but the lack of easy two-way interop with github had me gradually drop it for new projects, when I anticipate some level of other contributors. That being said, going from fossil->git via git-export is very simple and painless.
I'd claim things are more nuanced. There are many reasons why UIs in many places, not just cars, suck. In cars, wether warranted or not, there is also pressure from legal to err on the side of building a cludge that is unassailable vs. a smooth user experience that could be grounds for a class action because it doesn't make enough of an effort to discourage dangerous user behavior.
Wouldn't an open lamp severely degrade all kinds of paints and materials that aren't meant to be exposed to UV light? Or does the mechanism that supposedly makes the shorter wavelength safe for human skin cells apply to all materials?
I’ve just finished an rpi based device that would be going into mass production if it wasn’t for the parts shortage, with some digital IO and I2C. It took me about a year calendar time to convert the software stack to elixir+nerves as a side project, with many improvements just because of the good infrastructure support for remote deployment. Circuits wasn’t particularly weird, though it had only limited support for some advanced GPIO functions.
Io was fantastic as a personal learning vehicle, over ten years ago. I did have a game project that used it, right in the lull where Lua’s FFI was still a little rough and JS did not quite break out of the browser.
Its simplicity also made it great to write an interpreter for, including GC. However, nowadays the focus shifted to JIT, mostly via LLVM, which leaves such free-form languages unable to compete on performance, without significant effort.
I do fondly remember the endless explorative chats with Steve Dekorte and the other language geeks on IRC!
One can verify and sign off on computations that approximate the physics or chemistry that will occur in a structure or machine, as a well established chain of procedures exist to go from crude formulaic approximations to micro or, if necessary, nano-scale simulations of electrical, mechanical, and chemical processes, and we know what to look for.
I don't think the same is true for software "engineering," as it seems that all possible forms of process can be subverted and cargo-culted, from agile methods down to code checking. Certainly there is room to remedy some shortcomings, but SWE definitely is the engineering discipline least based in physical fact.
The physics behind simulating the buckling of a structure is always the same, we can just choose more or less crude approximations of it, but SWE in general seems a lot more diverse. I can implement that simulation in assembly or some scripting language, and attach various bits and pieces to it to manage users and data; deploy it across the cloud if need be. But, there isn't a singular, time-invariant optimal path to achieving that, and what is true today may not be true tomorrow. One can work off basic principles, like the Agile Manifesto, but how can you quantify or even certify this shifting landscape?
David Rosen pulled off quite a few little masterpieces -- his gamedev competition entries always had fantastically unique aspects. I cannot believe "Black Shades" was almost 20 years ago! (I have no affiliation, but I am glad to see https://www.wolfire.com/games is still alive and kicking!)
Lugaru and later Overgrowth have been the outcomes of what can only be called a decades long obsession with getting the player controls just right, allowing very natural and responsive control and movement, through creating emergent behaviors from first principles, resulting in a rich and natural interaction with the environment (and other characters, see the fighting mojo), in contrast to the many, many AAA titles that just constantly break the immersion through unnatural, jarring behaviors and frustrating limitations.