Interesting how often they use the word „craft“. For me, a sign that AI fatiguge is a real issue, not only among Windows users. Good, maybe a small, first step towards down-regulation of the hype.
An immense amount of time, dedication and talent must have went into all those achievements. This requires mastery of body and mind at an exceptional level. Putting aside all jokes and acting roles, the martials arts is where he earned my full respect and that will also stick in my memory about him.
I wouldn‘t say this is the core argument of No Silver Bullet. I wrote a short review of Brooks paper with respect to todays AI promises, to whoever is interested in more details:
I use Fossil for all of my long term projects. It can even import Git repositories if you want to try it out.
Today I was working on a semester paper for a non-technical class. It is versioned in fossil and I have all my miscellaneous ideas, initial outline, and the paper guidelines in the Wiki. The branching also makes much more sense, and I’ve used it for major revisions of the paper or its structure.
Fossil is legitimately awesome, and I lament the fact that Git gained popularity over it.
Fossil is great. Not only is it a full suite of tools associated with the repository (discussions, tickets, wiki) but the tool is a single >10mb binary and can run as a web server (or CGI-like interface) for remote hosting.
The web server that powers fossil was also written by its author! It’s nice that unlike git instaweb you don’t need to install an additional web server just to see a read only view of your commits.
Fossil itself is a C binary, not a database. Maybe they meant that Fossil’s source code is hosted in Fossil, or that Fossil repositories are SQLite files? I don’t exactly know either.
After quite some time, and actually after reading this post[0], I took another look at GNU Texmacs, this time with a little more depth and patience. And indeed, the program is an incredibly powerful tool for creating beautiful documents. I'm also currently on a roll where I'm reappreciating the philosophical advantages of WYSIWYG. Anyway, for me it's definitely an insider tip for anyone who is annoyed by LaTeX and is open enough to try WYSWYG.
To save people’s time: this thing is not LaTeX and you won’t be able to use any of the LaTeX packages that you need if you are preparing a manuscript for a journal (for example).
I am somewhat concerned about the volatility. All three languages have their merits and each has a stable foundation that has been developed and established over many years. The fact that the programming language has been “changed” within a short period of time, or rather that the direction has been altered, does not inspire confidence in the overall continuity of Ladybird's design decisions.
Not just volatility but also flip-flopping. Rust was explicitly a contender when they decided to go with Swift 18 months ago, and they've already done a 180 on it despite the language being more or less the same as it was.
they tried swift, it didn't work, and they figured rust was the best remaining option. that's not "flip-flopping" (by which I assume you mean random indecisiveness that leads to them changing their mind for no reason)
Yup, this was not flip-flopping, it was willingness to be open to options, even if it means going back on a decision branch made earlier in the process.
For the Ladybird project, now is the best time to be making a big decision like this, and it's commendable that the project lead was honest to recognize when an earlier attempt was not working, to be able to re-think and come to a better decision. I'm no fan of Rust, but for this project I think most of us would agree it's a better language than Swift for their purpose.
They made a very pragmatic and sensible decision after reviewing Swift that it wouldn't be suitable for their purposes, so they shifted to the next best alternative. I think they reasoned it very well and made a great decision.
There's been some fun volatility with the author over the years. I told him once that he might want to consider another language to which he replied slightly insultingly. Then he tried to write another language. Then he tried to switch from C++ to Swift, and now to Rust :P
Indeed, and as a school those 18 months are well worth it, but it is in many ways also 18 months wasted. There is a strong sense of NIH with the Ladybird dev(s), and I wonder if that isn't their whole reason for doing this.
I've seen another team doing something similar, they went through endless rewrite cycles of a major package but never shipped, and eventually the project was axed when they proposed to do it all over again, but this time even better.
> Indeed, and as a school those 18 months are well worth it, but it is in many ways also 18 months wasted.
the thing for me is (and maybe i've missed something?) but if after 18 months of struggle i'd really like to get a more insightful blog post* that goes into detail about what exactly failed and the process that lead to it... as a language enthusiast i think getting valuable lessons/reflections would be cool (was the cause swift c++ iterop progressing too slow? or some other technical hurdle? was there politics involved? etc etc)
* of course i'm just an internet person, i don't deserve anything from anybody ^^
The sense of NIH is from Serenity, and that was probably the reason for Jakt's existence too. Now it's spun off into its own project there is a lot more pragmatism.
Well, here's to hoping because we really need a stand-in for FF. I realize the irony here in terms of that being the ultimate 'NIH' project but that one I can get behind because the browser landscape is much too fragile. Of course they might end up taking users away from FF rather than from Chrome, Edge or Safari.
In case you didn't know they're using a lot of third-party libraries now for pretty major things: libcurl for http, Skia/Harfbuzz for rendering, libxml, OpenSSL, ffmpeg, etc:
> The role of the human engineer […] has been to reduce risk in the face of ambiguity, constraints, and change. That responsibility not only endures in a world of Write-Only Code, if anything it expands.
> The next generation of software engineering excellence will be defined not by how well we review the code we ship, but by how well we design systems that remain correct, resilient, and accountable even when no human ever reads the code that runs in production.
As a mechanical engineer, I have learned how to design systems that meet your needs. Many tools are used in this process that you cannot audit by yourself. The industry has evolved to the point that there are many checks at every level, backed by standards, governing bodies, third parties, and so on. Trust is a major ingredient, but it is institutionalized. Our entire profession relies on the laws of physics and mathematics. In other words, we have a deterministic system where every step is understood and cast into trust in one way or another. The journey began with the Industrial Revolution and is never-ending; we are always learning and improving.
Given what I have learned and read about LLM-based technology, I don't think it's fit for the purpose you describe as a future goal. Technology breakthroughs will be evaluated retrospectively, and we are in the very early stages right now. Let's evaluate again in 20 years, but I doubt that "write-only code" without human understanding is the way forward for our civilization.
If this worked, it’d have worked on low cost devs already. We’ve had the ability to produce large amounts of cheap code (more than any dev can review) for a long time.
The root issue is it’s much faster to do something yourself if you can’t trust the author to do it right. Especially since you can use an LLM to speed up your understanding.
reply