Posted by dmitrybrant 5 days ago
> Use these tools as a massive force multiplier of your own skills.
Claude definitely makes me more productive in frameworks I know well, where I can scan and pattern-match quickly on the boilerplate parts.
> Use these tools for rapid onboarding onto new frameworks.
I’m also more productive here, this is an enabler to explore new areas, and is also a boon at big tech companies where there are just lots of tech stacks and frameworks in use.
I feel there is an interesting split forming in ability to gauge AI capabilities - it kinda requires you to be on top of a rapidly-changing firehose of techniques and frameworks. If you haven’t spent 100 hours with Claude Code / Claude 4.0 you likely don’t have an accurate picture of its capabilities.
“Enables non-coders to vibe code their way into trouble” might be the median scenario on X, but it’s not so relevant to what expert coders will experience if they put the time in.
One thing I love doing is developing a strong underlying data structure, schema, and internal API, then essentially having CC often one-shot a great UI for internal tools.
Being able to think at a higher level beyond grunt work and framework nuances is a game-changer for my career of 16 years.
Some amount of boilerplate probably needs to exist, but in general it would be better off minimized. For a decade or so there's sadly been a trend of deliberately increasing it.
It's rather saying that we should have parts that join without nailing by now, especially for things we do again and again and again and again.
Reason Japanese carpenters do or did that is that sea air + high humidity would absolutely rot anything with nail and screw.
No furniture is really designed from a single tree, though. They aren't massive enough.
I agree with overall sentiment. But the analogy is higly flawed. You can't compare physical things with software. Physical things are way more constrained while software is super abstract.
The other reason was that iron was very expensive in Japan as they had only low quality iron ore.
LLMs allow us to do large but cheap experiments that we would never attempt otherwise. That includes new architectures. Automation in the traditional sense is opposite of plasticity (because it's optimizing and crystalizing around a very specific process), but what we're doing with LLMs isn't that. Every new request can be different. Experiments are more possible, not less. We don't have to tear down years of scaffolding like old automated systems. We just nudge it in a new direction.
Eventually, prog-lang designers will figure out how to get llms to create new prog-langs.
A few days ago I lost some data including recent code changes. Today I'm trying to recreate the same code changes - i.e. work I've just recently worked through - and for the life of me I can't get it to work the same way again. Even though "just" that is what I set out to do in the first place - no improvements, just to do the same thing over again.
Throwing a dart could not be further away from programming a computer. It's one of the most deterministic things we can do. If I write if(n>0) then the computer will execute my intent with 100% accuracy. It won't compare n to 0.005.
You see arguments like yours a lot. It seems to be a way of saying "let's lower the bar for AI". But suppose I have a laser guided rifle that I rely on for my food and someone comes along with a bow and arrow and says "give it a chance, after all lots of things we do are inaccurate, like throwing darts for example". What would you answer?
Actually no wait let’s expand it. Why not go say this to Ronnie O’Sullivan too!
The way you’re describing is such that there is no determinism behind what is being done. Simply not true.
Something so complex that we cannot model it as deterministic is hence stochastic. We can just as easily model a stochastic thing by ignoring the stochastic parts.
separating subjective appearance of things from how we can conceptualise them as models begs a deeper philosophical question of how you can talk about the nature of things you cannot perceive.
It’s undeniable that humans exhibit stochastic traits, but we’re obviously not stochastic processes in the same sense as LLMs and the like. We have agency, error-correction, and learning mechanisms that make us far more reliable.
In practice, humans (especially experts) have an apparent determinism despite all of the randomness involved (both internally and externally) in many of our actions.
It feels like toil because it's not the interesting or engaging part of the work.
If you're going to build a piece of furniture. The cutting, nailing, gluing are the "boiler plate" that you have to do around the act of creation.
LLM's are just nail guns.
I actually think I like the idea that, maybe by handling my boilerplate over to AI we can be more comfortable with having boilerplate to begin with.
It is possible to get much higher quality with not just oversight, but creating the alignment from the stochastic agents to have no choice but to converge towards the desired vector of work reliably.
Human in the loop AI is fine, I'm not sure that everything doesn't to be automated, it's entirely possible to get further and more reps in on a problem with the tool as long as the human is the driver and using the stochastic agent as a thinking partner and not the other way around.
And then… that just kind of dropped out of the discussion. Throw things at the wall as fast as possible and see what stuck, deal with the consequences later. And to be fair, there were studies showing that choice of language didn’t actually make as big of difference as found in the emotions behind the debates. And then the web… committee designed over years and years, with the neve the ability to start over. And lots of money meant that we needed lots of manager roles too. And managers elevate their status by having more people. And more people means more opportunity for specializations. It all becomes an unabated positive feedback loop.
I love that it’s meant my salary has steadily climbed over the years, but I’ve actually secretly thought it would be nice if there was bit of a collapse in the field, just so we could get back to solid basics again. But… not if I have to take a big pay cut. :)
Here’s an incomplete list for those traits. For unusual, there’s many of the FP languages, Ada, APL, Delphi/Object Pascal, JS, and Perl. For duck typing, there’s Ruby, Python, PHP, JS, and Perl. For only interpreted, there are Ruby, PHP, and Perl (and formerly for some time Python and JS). For syntax that’s not necessarily odd (but may be) but lots of people find distasteful there’s Perl, any form of Lisp, APL, Haskell, the ML family, Fortran, JS, and in some camps Python, PHP, Ruby, Go, or anything from the Pascal family. For big languages with lots of interacting parts there’s Perl, Ada, PHP, Lisp with CLOS, Julia, and PHP. For slowdowns, there’s Julia, Python, PHP, and Ruby. The runtime for Perl is actually pretty fast once it’s up and running, but having to build the app before running it on every invocation makes for a slow start time.
All that said, certain orgs do impressive projects pretty quickly with some of these languages. Some do impressively quick work with even less popular languages like Pike, Ponie, Elixir, Vala, AppScript, Forth, IPL, Factor, Raku, or Haxe. Notice some of those are very targeted, which is another reason boilerplate is minimal. It’s built into the language or environment. That makes development fast, but general reuse of the code pretty low.
Python’s subprocess for example has a lot of args and that reflects the reality that creating processes is finicky and there a lot of subtly different ways to do it. Getting an llm to understand your use case and create a subprocess call for you is much more realistic than imagining some future version of subprocess where the options are just magically gone and it knows what to do or we’ve standardized on only one way to do it and one thing that happens with the pipes and one thing for the return code and all the rest of it.
Because everyone needs a boilerplate but it's a different boilerplate for everyone unless you're doing the most basic toy apps
These days, people mostly use things like GHC.Generics (generic programming for stuff like serialization that typically ends up being free performance-wise), newtypes and DerivingVia, the powerful and very generalized type system, and so on.
If you've ever run into a problem and thought "this seems tedious and repetitive", the probability that you could straightforwardly fix that is probably higher in Haskell than in any other language except maybe a Lisp.
i think it has. How much easier is it today than yester-decade to write, and deploy an application to multiple platforms (and have it look/run similarly)?
How little knowledge it requires now than before?
There are? For example, rails has had boilerplate generation commands for a couple of decades.
There is no software you could possibly write that works for everything thatd be as good as "Give me an internal dashboard with these features"
In fact, collectively created 1000s of them and all of them a various flavor of mid.
They weren’t just saying ‘AI writes the boilerplate for me.’ They were saying: once you’ve written the same glue the 3rd, 4th, 5th time, you can start folding that pattern into your own custom dev tooling.
AI not as a boilerplate writer but as an assistant to build out personal scaffolding toolset quickly and organically. Or maybe you think that should be more systemized and less personal?
Lisp completely eliminates boilerplate and has been around for decades, but hardly anyone uses it because programs that use macros to eliminate boilerplate aren't easy to read.
You dont understand how things evolve.
There have been plenty of platforms that got rid of boilerplate - e.g. ruby on rails about 20 years ago
But once they become the mainstream, people can get a competitive edge by re-adding loads of complexity and boilerplate again. E.g. complex front end frameworks like react.
If you want your startup to look good you've got to use the latest trendy front end thingummy
Also to be fair, its not just fashion. Features that would have been advanced 20 years ago become taken for granted as time goes on, hence we are always working at the current limit of complexity (and thats why we're always overrun with bugs and always coming up with new platforms to solve all the problems and get rid of all thr boilerplate so that we can invent new boilerplate)
You’re asking to shift this job from the editor (you) to the viewer (the browser).
Document/template inclusion model should be OK now in modern era thanks to HTTP/3. Not really sure how that should ideally look like though.
Haskell mostly solves boilerplate in a typed way and Lisp mostly solves it in an untyped way (I know, I know, roughly speaking).
To put it bluntly, there's an intellectual difficulty barrier associated with understanding problems well enough to systematize away boilerplate and use these languages effectively.
The difficulty gap between writing a ton of boilerplate in Java and completely eliminating that boilerplate in Haskell is roughly analogous to the difficulty gap between bolting on the wheels at a car factory and programming a robot to bolt on the wheels for you. (The GHC compiler devs might be the robot manufacturers in this analogy.) The latter is obviously harder, and despite the labor savings, sometimes the economics of hiring a guy to sit there bolting on wheels still works out.
Now we have a way we can get computers to do it!
"Use these tools as a massive force multiplier of your own skills" is a great way to formulate it. If your own skills in the area are near-zero, multiplying them by a large factor may still yield a near-zero result. (And negative productivity.)
It seems to me that LLMs help the most at the initial step of getting into some rabbit hole - when you're getting familiar with the jargon, so you can start reading some proper resources without being confused too much. The sooner you manage to move there, the better.
Then I need to expend extra time following everything it did so I can "fix" the problem.
A lot of people have the try and see if it works approach. That can be insanely wasteful in any moderately complex system. The scientist way is to have a model that reduce the system to a few parameters. Then you’ll see that a lot of libraries are mostly surface works and slighlty modified version of the same thing.
It seems to me that if you have been pattern matching the majority of your coding career, then you have a LLM agent pattern match on top of that, it results in a lot of headaches for people who haven't been doing that on a team.
I think LLM agents are supremely faster at pattern matching than humans, but are not as good at it in general.
just points to the fact that they've no idea what they're doing and would produce different, pointless code by hand, though much slower. this is the paradigm shift - you need a much bigger sieve to filter out the many more orders of magnitude of crap that inexperienced operators of LLMs create.
You cannot outsource thinking to LLMs, at least not yet, if ever. You have to be part of the whole process. You need to have knowledge. If you have no idea what it is doing or what you want it to do, you are going to have a difficult time.
The programming language eliminates some (incorrect syntax) while the type system get rid of others (contract error). We also have linter that helps us with harmful patterns. But the range of errors is still enormous. So what’s the probability of having the LLMs be error free or as close as possible to the intended result?
We as humans have reduced the probability of error by having libraries of correct code (or outsourcing the correction of code), thus having a firmer and cognitively manageable foundation to create new code. As well as not having to rely on language to solve problems.
In my case it is not slower, so it works for me. I cannot speak for others.
I just don’t see it like this; code is craft, and there are ten ways to solve any given problem. Reasonable people can select different tradeoffs, and taste is also a big factor.
Maybe if you are working in very low-level algorithmic, compiler, or protocol development it’s less ambiguous. But almost all software is written many layers above that.
I’m sure if you already sat down and thought through every detail, you might find LLMs slow you down vs typing. Many people use the process of writing, or the process of iterating with customers, to flesh out the ambiguous detail; in which case improving cycle time can improve your time to PMF.
Maybe if all you do is code, but that’s not how most people work. Being able write I need these things done in this way and then attend a meeting or start researching the next thing is valuable. And because of my other obligations there’s no way I could do more without Claude.
I've felt this learning just this week - it's taken me having to create a small project with 10 clear repetitions, messily made from AI input. But then the magic is making 'consolidation' tasks where you can just guide it into unifying markup, styles/JS, whatever you may have on your hands.
I think it was less obvious to me in my day job because in a startup with a lack of strong coding conventions, it's harder to apply these pattern-matching requests since there are fewer patterns. I can imagine in a strict, mature codebase this would be way more effective.
Piling shit on top of shit only pays off on very short time scales - like a month or two. Because once you revisit that shit code all your time savings are out the window. If you have to revisit it more than once you probably slowed yourself down already.
Also new languages - our team uses Ruby, and Ruby is easy to read, so I can skip learning the syntax and get the LLM to write the code. I have to make all the decisions, and guide it, but I don't need to learn Ruby to write acceptable-level code [0]. I get to be immediately productive in an unfamiliar environment, which is great.
[0] acceptable-level as defined by the rest of the team - they're checking my PRs.
> Also new languages - our team uses Ruby, and Ruby is easy to read, so I can skip learning the syntax and get the LLM to write the code.
If Ruby is "easy to read" and assuming you know a similar programming language (such as Perl or Python), how difficult is it to learn Ruby and be able to write the code yourself?
> ... but I don't need to learn Ruby to write acceptable-level code [0].
Since the team you work with uses Ruby, why do you not need to learn it?
> [0] acceptable-level as defined by the rest of the team - they're checking my PRs.
Ah. Now I get it.
Instead of learning the lingua franca and being able to verify your own work, "the rest of the team" has to make sure your PR's will not obviously fail.
Here's a thought - has it crossed your mind that team members needing to determine if your PR's are acceptable is "a bad thing", in that it may indicate a lack of trust of the changes you have been introducing?
Furthermore, does this situation qualify as "immediately productive" for the team or only yourself?
EDIT:
If you are not a software engineer by trade and instead a stakeholder wanting to formally specify desired system changes to the engineering team, an approach to consider is authoring RSpec[0] specs to define feature/integration specifications instead of PR's.
This would enable you to codify functional requirements such that their satisfaction is provable, assist the engineering team's understanding of what must be done in the context of existing behavior, identify conflicting system requirements (if any) before engineering effort is expended, provide a suite of functional regression tests, and serve as executable documentation for team members.
0 - https://rspec.info/features/6-1/rspec-rails/feature-specs/fe...
I lead the engineering team at my org and we hire almost exclusively for c++ engineers (we make games). Our build system by happenstance is written in c#, as are all the automation scripts. Out of our control to change. Should we require every engineer to be competent and write fluent c# or should we let them just get on with their value adds?
I would expect every engineer to be able to read C#. It’s not that hard.
Reading code doesn't mean you can write it, as any programmer will tell you.
If I want to know if a string in ruby begins with another string, is the method starts_with or start_with or startwith like python or is it like perl where I have to use some completely different method? I don't know, better google it.
But if I'm reading and see `str.start_with?("https://")` I know instantly what it's doing.
Great skill multiplier, right?
No, not at all.
What I was speaking about was if the person to whom I replied is not a s/w engineer, then perhaps a better contribution to their project would be to define requirements in the form of RSpec specifications (since Ruby is in use) and allow the engineering team to satisfy them as they determine appropriate.
I have seen product/project managers attempt to "contribute" to a development effort much like what was described. Usually there is a power dynamic such that engineers cannot overtly tell the manager(s), "you define the 'what' and we will define the 'how'." Instead, something like the PR flow described is grudgingly accepted and then worked around.
To address your comments about PRs: without the LLM I would be submitting shitty PRs with lots of basic Ruby mistakes. With the LLM I am submitting PRs that are on a par with everyone else's PRs (Ruby has many ways of doing the same thing, so most suggested changes to my PRs are the usual "or you could do it this way and that might be more elegant" discussions). It's not that the rest of the team are picking up my slack, it's actually better this way.
I was a bit sceptical when I started, and like you I assumed that I would end up having to learn Ruby, but in fact it's working well.
This reminds of some of the comments made by reviewers during the infamous Schön scientific fraud case. The scientific review process is designed to catch mistakes and honest flaws in research. It is not designed to catch fraud, and the evidence shows that it is bad at it.
Another applicable example would be the bad patches fiasco with the Linux kernel. (And there is going to be a session at the upcoming maintainers' summit about LLM-generated kernel patches.)
One thing where it hasn't shone is configuring my production deployment. I had set this project up with a docker-compose, but my selected CI/CD (Gitlab) and my selected hosting provider (DigitalOcean) seemed to steer me more towards Kubernetes, which I don't know anything about. Gitlab's documentation wanted me to setup Flux (?) and at some point referred to a Helm chart (?)... All words I've heard but their documentation is useless to newcomers ("manage containers in production!": yes, that's obviously what I'm trying to do... "Getting started: run this obscure command with 5 arguments": wth is this path I need to provide? what's this parameter? etc.) I honestly can't believe how complex the recommended setup is, to ultimately run 2 containers that I already have defined in ~20 lines of docker-compose...
Claude got me through it. Took it about 5-6 hours of trying stuff, build failing, trying again. And even then, it still doesn't deploy when I push. It builds, pushes the new container images, and spins up a new pod... which it then immediately kills because my older one is still running and I only want one pod running... Oh well, I'll just keep killing the old pod until I have some more energy to throw at it to try and fix it.
TL;DR: it's much better at some things than others.
Some folks seem to like Docker Swarm before kubernetes as well and I've found it's not bad for personal projects for sure.
AI will always return the average of it's corpus given the chance (or not clear direction in the prompt). I usually let my opinions rip and say to avoid building myself a stack temple to my greatness. It often comes back with a nice lean stack.
I usually avoid or minimize Javascript libraries for their brittleness, and the complexity can eat up more of the AI's context and awareness to map the abstractions vs something it knows incredibly well.
Python is great, but web stuff is still emerging, FastAPI is handy though, and putting something like Pico/HTMX/alpine.js on the front seems reasonable.
Laravel is also really hard to overlook sometimes when working with LLMs on quick things, there's so much working code out there that it can really get a ton done for an entire production environment with all of the built in tools.
Happy to learn about what other folks are using and liking.
It took a few prompts but I know enough about FFS (the Amiga filesystem) to guide it, and it created exactly the tool I wanted.
"force multiplier of your own skills" is a great description.
There are currently multiple posts per day on HN that escalate into debates on LLMs being useful or not. I think this is a clear example that it can be. And results count. Porting and modernizing some ancient driver is not that easy. There's all sorts of stuff that gets dropped from the kernel because it's just too old to bother maintaining it and when nobody does, deleting code becomes the only option. This is a good example. I imagine, there are enough crusty corners in the kernel that could benefit from a similar treatment.
I've had similar mixed results with agentic coding sometimes impressing me and other times disappointing me. But if you can adapt to some of these limitations it's alright. And this seems to be a bit of a moving goalpost thing as well. Things that were hard a few months ago are now more doable.
My main worry is whether they will be useful when priced above actual cost. I worry about becoming depending on these tools only for them to get prohibitively expensive.
These studies keep popping up where they randomly decide whether someone will use AI to assist in a feature or not and it's hard for me to explain just how stupid that is. And how it's a fundamental misunderstanding of when and how you'd want to use these tools.
It's like being a person who hangs up drywall with screws and your boss going "Hey, I'm gonna flip a coin and if it's heads you'll have to use the hammer instead of a screwdriver" and that being the method in which the hammer is judged.
I don't wake and go "I'm going to use AI today". I don't use it to create entire features. I use it like a dumb assistant.
> I've had similar mixed results with agentic coding sometimes impressing me and other times disappointing me. But if you can adapt to some of these limitations it's alright. And this seems to be a bit of a moving goalpost thing as well. Things that were hard a few months ago are now more doable.
Exactly my experience too.
I actually do this now. That's one of those things that went from impossible to doable under some circumstances. Still a bit of a coin flip but it can work well in some code bases. I still have a mental block even asking for these things under the assumption it would not work anyway. But I've been pleasantly surprised a few times where this actually works.
Honestly amazed at how good it is getting something going. I always had issues extrapolating on existing designs, so the ability to get EXACT screens built without having a designer yell at me for being stupid has been a godsend.
I've been able to do things that I would not have the competence for otherwise, as I do not have a formal software engineering background and my main expertise is writing python data processing scripts.
E.g., yesterday I fixed a bug [2] by having Claude compare the CarPlay and iOS search implementations. It did at first suggest another code change than the one that fixed it, but that felt just like a normal part of debugging (you may need to try different things)
Most of my contributions [3] have been enabled by Claude, and it's also been critical to identify where the code for certain things are located - it's a very powerful search in the code base
And it is just amazing if you need to write a simple python script to do something, e.g., in [4]
Now this would obviously not be possible if everyone used AI tools and no one knew the existing code base, so the future for real engineers and architects is bright!
[1] https://codeberg.org/comaps/comaps [2] https://codeberg.org/comaps/comaps/pulls/1792 [3] https://codeberg.org/comaps/comaps/pulls?state=all&type=all&... [4] https://codeberg.org/comaps/comaps/pulls/1782
Hope to make the bridge soon with i18n of cartes.app.
I also use LLMs to work on it. Mistral, mostly.
It's very useful when you get the answer in several minutes rather than half a hour.
Maybe it is because they generate the code in one pass and cannot return back and fix the issues. LLM makers, you should allow LLMs to review and edit the generated code.
Also I wanted to add that LLMs (at least free ones) are pretty dumb sometimes and do not notice obvious thing. For example, when writing tests they generate lot of duplicated code and do not move it into a helper function, or do not combine tests using parametrization. I have to do it manually every time.
You can tell it to move it and they'll move it and use this shared code from now on.
For example, imagine if you test a vector-like collection. In every test case dumb LLM creates vector manually and makes inserts/deletes. It could be replaced by adding a helper function that accepts a sequence of operations and returns the processed vector. Furthermore, once you have that function, you can merge multiple tests with parametrization, by having a test function accept a sequence of operation and expected result:
parametrize('actions, result', (
# Test that remove removes items from vector
([Ins(1, 2, 3, 4), Remove(4)], [1, 2, 3]),
...
)
"Don't create vector manually inline in every test case, make a helper function for that."
and see what agent does. It might do something smart. It might do something a bit dumb but by understanding why exactly it's dumb, you can communicate what correction is needed pretty smoothly.
Even before tools like CC it was the case that LLMs enabled venturing into projects/areas that would be intimidating otherwise. But Claude-Code (and codex-cli as of late) has made this massively more true.
For example I recently used CC to do a significant upgrade of the Langroid LLM-Agent framework from Pydantic V1 to V2, something I would not have dared to attempt before CC:
https://github.com/langroid/langroid/releases/tag/0.59.0
I also created nice collapsible html logs [2] for agent interactions and tool-calls, inspired by @badlogic/Zechner’s Claude-trace [3] (which incidentally is a fantastic tool!).
[2] https://github.com/langroid/langroid/releases/tag/0.57.0
[3] https://github.com/badlogic/lemmy/tree/main/apps/claude-trac...
And added a DSL to specify agentic task termination conditions based on event-sequence patterns:
https://langroid.github.io/langroid/notes/task-termination/
Needless to say, the docs are also made with significant CC assistance.
If you don't have the technical understanding of a language or framework, there is going to be a lot of ambiguity in your prompts.
This specificity gap leads the LLM to fill in those gaps for you, which may not be what you intended. And that's usually where bugs hide.
I think this is the flip side to being a "force multiplier"
I would hope Claude would be like “Hold on man…”
This implementation provides:
Generic Tuple Structure: A flexible tuple that can hold different types of elements (int, double, string, float)
Constructor Function: tuple_create() initializes a new tuple with specified size
Type-Safe Setters:
tuple_set_int(), tuple_set_double(), tuple_set_string(), tuple_set_float()
Type-Safe Getters:
tuple_get_int(), tuple_get_double(), tuple_get_string(), tuple_get_float()
Memory Management: Automatic memory allocation and deallocation
Utility Functions:
tuple_print() for displaying tuple contents
tuple_destroy() for cleanup
If you have access to state-of-art coding assistants, try asking this. You can additionally add a requirement to generate a destructor function (that would free dynamically-allocated fields).
| I'll create a simple C++ class with a constructor that takes a tuple. Here's an example...
> nah C
| C doesn't have classes or constructors - those are C++ features. In C, you would use a struct and create an initialization function. Here's how you'd handle a tuple-like structure:
I've done _so_ many of these where I go "hmm, this might be useful", planned the project with gemini/chatgpt free versions to a markdown project file and then sic Claude on it while I catch up on my shows.
Within a few prompts I've got something workable and I can determine if it was a good idea or not.
Without an LLM I never would've even tried it, I have better and more urgent things to do than code a price-watcher for very niche Blu-ray seller =)
There is a good discussion/interview¹ between Alan Kay & Joe Armstrong about how most code is developed backwards b/c none of the code has a formal specification that can be "compiled" into different targets. If there was a specification other than the old driver code then the process of porting over the driver would be a matter of recompiling the specification for a new kernel target. In absence of such specification you have to substitute human expertise to make sure the invariants in the old code are maintained in the new one b/c the LLMs has no understanding of any of it other than pattern matching to other drivers w/ similar code.
1. The original hardware spec is usually proprietary, and
2. The spec is often what the hardware was supposed to do. But hardware prototype revisions are expensive. So at some point, the company accepts a bunch of hardware bugs, patches around them in software, ships the hardware, and reassigns the teams to a newer product. The hardware documentation won't always be updated.
This is obviously an awful process, but I've seen and heard of versions of it for over 20 years. The underlying factors driving this can be fixed, if you really want to, but it will make your product totally uncompetitive.
It wouldn't surprise me if the drive and the tapes are still somewhere in my parents storage. Could be a fun weekend project to try it out, though I'm not sure I have any computer with a floppy interface anymore. And I don't think there's anything particularly interesting on those tapes either.
In any case, cool project! Kudos to the author!
> As a giant caveat, I should note that I have a small bit of prior experience working with kernel modules, and a good amount of experience with C in general
But yeah, the dream of new OSes is sweet...
We're talking about an order of magnitude quicker onboarding. This is absolutely massive.
Just like security holes generated by those LLMs. /s
What's wrong with exist one?
For example, FreeRTOS doesn't support 64-bit intel arch. And you don't "ship an app on FreeRTOS", it's more of an API and framework you use, and you sort of write a module in C and compile one big app. Quite different from non-embedded app design/shipping. You won't be able to run an Android app on an ESP32, but it should be possible to write apps for ESP32 and run them on Android-compatible hardware. But FreeRTOS would need optional MMU support, and you'd need extra components to load the app, in addition to hardware support.
If you're asking "why would you do that", it's because I want to write simple purpose-built apps without all the trappings of a larger OS and run them on all types of hardware. You could technically build a 'smart watch' that isn't so smart but runs on a single battery charge for 1 year. But not if you use a power-hungry SoC. Want a more efficient SoC? Good luck figuring that out. Making that whole process easier unlocks more technical solutions and products.
Also am i correctly assume you want an OS that's truly "cross-platform", that can run on every architecture ? Or you just want to "have an app on ESP32 to run on Android" ? Because the latter can be done with proper abstraction layer.