> The thesis is predicated on the idea that people claim this is the result of some study. I’ve never once heard it presented that way. It's a rule of thumb.
Code Complete cites eight sources to support the claim that the average cost to fix a defect introduced during requirements is 10-100x if it's not detected until after release. My qualm with Hillel's original assertion is that "They all use this chart from the 'IBM Systems Sciences Institute'" (emphasis added). I haven't personally vetted Steve McConnell's citations, but I am skeptical that they all share this common origin.
Laurent Bossavit’s The Leorechauns of Software Engineering looks into this claim (and several others) and finds that, yes, many of these studies do share a common origin, and often misquote/misrepresent it.
It's a land grab that, if GSAP becomes a standard, makes it that much harder to compete with Webflow.
For example GSAP will now never make its way into Figma or Framer which is a staple of the design workflows of many teams. This move by Webflow makes GSAP a line of demarkation between Figma-based workflows, Framer-based workflows, and Webflow-based workflows.
Any momentum the library might have had is now skewered by these limitations which will surely create demand for more different animation libraries to exist within other walled gardens.
The same happened to Vercel & Next.js which now seems to be powering the return of Vite & CSR.
Now that said, I'd never heard of this library until this announcement, and I don't know much about its role in the javascript ecosystem, but I can't say that the trend towards M&A kingdoms in the open source community delights me.
FWIW, sub-5kb banners were probably the only Flash projects that didn't include GSAP before we collectively jumped ships to JavaScript and CSS for animation on the web. It was everywhere.
Personally, I don't know what you mean about Rust being too massive. One thing I am wary of is using a truly massive language like C++ on a multi-programmer project without consensus on which features to use and how to use them. Maybe you have in mind something like that?
If you want the simplicity of C with more safety, maybe tooling like Frama-C, a MISRA C conformance checker, or just aggressive use of static and dynamic analysis tools like ASAN and UBSAN. You can also disable certain optimizations (e.g., strict aliasing) to steer away from some of the major pitfalls of UB.
When I read SQL for Dummies almost thirty years ago, it made a point of distinguishing "sequel" as a historical predecessor to standard "SQL." As I recall, the author even asserted that SQL is not an acronym/initialism for structured query language. I felt funny saying sequel for the next decade or so, because I wasn't an old timer experienced with this pre-SQL technology.
Now I usually say sequel because everyone else does. That and it rolls off the tongue better than S-Q-L.
For a while I used dired-sidebar-show-sidebar and dired-omit-mode to give me a list of files in a narrow window on the left. I kept messing it up with C-x 1, though.
I played around with the calculator source code from the Android Open Source Project after a previous submission[1]. I think Google moved it from AOSP to the Google Play Services several years ago, but the old source is still available.
It does solve some real problems that I'd love to have available in a library. The discussion on the previous article links to some libraries, but my recollection is that the calculator code is more accessible to an innumerate person like myself.
Edit: the previous article under discussion doesn't seem to be available, but it's on archive.org[2].
This is a long rant that covers a lot of ground, a lot of which will inevitably be ignored because the letters "C++" trigger people, myself included sometimes. (Skip ahead to "It's Not All Puppies and Butterflies" for some of the complaints.) The author is really impressed by C++11, as am I, after purposely ignoring C++ for the better part of twenty years.
I appreciate the shout outs to some packages and libraries to play with, although I still often find it a pain to incorporate other libraries into my projects. (Single-file headers, anyone?) I'm intrigued by FTXUI.
And boy, howdy, he's right: cppreference.com is amazing. Python's documentation is pretty good, but I've never seen anything as good as cppreference.com.
cppreference.com is very, very good at being reference, as in the name.
Python's documentation is scattershot and incomplete in many places, and lacks a consistent copy-editing style - but it offers good coverage of all kinds of documentation (per the Diataxis framework), not just reference. The people writing that documentation explicitly take that framework into consideration and use it to look for ways to improve. (But it's still a volunteer effort that works basically the same way the code development does, following open-source principles, so.)
The article filled me on a lot of things I didn't know about C++ because I learnt it at school and college, but soon moved to Python/JavaScript for day job. I have been itching to "get closer to the system" for a while now, and learning Rust on the side hasn't been easy. This article gave me hope that, I might be able to do that if I refreshed C++. Hello CMake… or I should probably say, Meson.
The picture shows a 2230-ish drive. I would be somewhat surprised if the 8TB option in the M4 Pro is on that module. The different chips may do storage differently.
Correct, it's not a 2230. Standard NVMe drives combine the NAND and controller onto a single module, but Apple Silicon machines have the SSD controller built into the main SOC, and the SSD module is just the raw NAND chips.
Code Complete cites eight sources to support the claim that the average cost to fix a defect introduced during requirements is 10-100x if it's not detected until after release. My qualm with Hillel's original assertion is that "They all use this chart from the 'IBM Systems Sciences Institute'" (emphasis added). I haven't personally vetted Steve McConnell's citations, but I am skeptical that they all share this common origin.