To be honest, even this has plenty of room to go down. I get the feeling I could have squeezed a couple more MB off if I had actually cut things off of the default Nixpkgs busybox, and possibly also cut a couple of kernel drivers out.
Excel for Mac has gotten a lot better - but I'm not surprised if it is still its own thing - with edge cases in format, macros, visual basic, linking to databases and data sources etc.
I imagine excel under wine is better than the port to Mac in some respects.
Interesting article - but perhaps a bit light on details in some places, like:
> I generated a list of the most common interview tasks
How? I suppose they mean gathered, or searched for, not strictly generated?
Also a little light on details of the actual interview.
I'm also a little confused about the listing of "problems" - do they refer to some specific leet-code site's listing of problems?
It seems like half-way between naming an actual algorithm/problem and naming a concrete exercise.
As for:
> How is it that we do not use this "forgotten and forbidden" coding in our daily production code, even though all highly reusable, useful code is essentially an exploitation of the intersection between classical algorithmic thinking and real-world problems?
I'm not sure what to say - most of this stuff lives in library code and data structure implementations for any language in common use?
Indeed the one saving grace of leet code interview is arguably that it shows if the candidate can choose sane data structures (and algorithms) when implementing real-world code?
You are right, I missed some crucial details in the blog entry.
I will definitely take your feedback into account for Part 2, where I want to do a more detailed deep dive into the prompting protocols (with maybe some exact examples) and my learning strategy.
To answer your questions:
1. By "generated" I mean that I prompted the LLM incrementally to provide me the list of the next LeetCode problems to do (without the deep research/search function)
2. Yes, the problem names are the exact names from LeetCode.
Initially, the LLM suggested this format, and I later forced it to stick to real LeetCode problems.
This allowed me to verify some output independently of the LLM (avoiding hallucinations), cross-check solutions with other materials, and track my progress.
Interestingly, I realized later that the LLM was mostly pulling from the standard Blind 75 problem set, and almost all the problems are from that list.
3. About the "forgotten and forbidden" code: I probably phrased it poorly in the article. As you said, this algorithmic logic is abstracted away in standard libraries and data structures. The disconnect for me (and I suspect for many "business logic" developers too) is that our daily production code rarely requires writing these fundamental structures from scratch, so we do not see the patterns that can also be applied in more high-level business logic. But this is still an in-progress hypothesis in my mind, without detailed examples.
> Our proprietary AI systems have never seen the original source code.
For this to be plausible satire, they need to show how they've trained their models to code, without mit, apache, bsd or GPL/agpl code being in the training set...
Adonis is over 10 years old... that's like 3 generations in software years, and 20 generations in web/Javascript.
The reason it's lacking features is because it's not very popular and hasn't gotten much outside contribution... I seem to also recall something about the founder being too hostile to outside ideas/suggestions also, but I could be misremembering
Javascript handling in Rails was easy in the early versions, then became messy with the asset pipeline and webpacker, and is becoming simple again with the latest versions
Current racket is running on top of chez scheme - which is maintained by Cisco - and reportedly extensively used in commercial products (router firmware/os etc).
It was brought into Cisco to do that but the project was eventually shelved, which was a shame because the prototypes delivered some really interesting reliability features. Most Cisco hardware products run firmware written in C. Management systems are often Java and (increasingly) Go. Clojure is used for one of the security product lines, but that was developed as a startup that was later purchased by Cisco. One of the management systems, NSO, is written in Erlang (brought in through the tail-f acquisition). There are certainly a lot of people in Cisco that understand the power of Lisp (I was one), but they are spread out and surrounded by people that just want to push whatever the latest thing is (now Go). C.f. the blub paradox and “worse is better.” They have a lot of legacy code that was written over the last 30 years that powers their devices, and that’s all in C.
So ending up at:
> From a 292MB initramfs, we now have a 6.1MB initramfs, smaller than almost every other distro's initramfs and made entirely to run busybox wget dd.
Is pretty great achievement today - but way bigger than something that can fit on a floppy.
reply