I read both, but I feel like they both miss what it was like to work with APIs back in the bad old XML days.
Yes, XML is more descriptive. It's also much harder for programmers to work with. Every client or server speaking an XML-based protocol had to have their own encoder/decoder that could map XML strings into in-memory data structures (dicts, objects, arrays, etc) that made sense in that language. These were often large and non-trivial to maintain. There were magic libraries in languages like Java and C# that let you map XML to objects using a million annotations, but they only supported a subset of XML and if your XML didn't fit that shoe you'd get 95% of the way and then realize that there was no way you'd get the last 5% in, and had to rewrite the whole thing with some awful streaming XML parser like SAX.
JSON, while not perfect, maps neatly onto data structures that nearly every language has: arrays, objects and dictionaries. That it why it got popular, and no other reason. Definitely not "fashion" or something as silly as that. Hundreds of thousands of developers had simply gotten extremely tired of spending 20% of their working lives producing and then parsing XML streams. It was terrible.
And don't even get me started on the endless meetings of people trying to design their XML schemas. Should this here thing be an attribute or a child element? Will we allow mixing different child elements in a list or will we add a level of indirection so the parser can be simpler? Everybody had a different idea about what was the most elegant and none of it mattered. JSON did for API design what Prettier did for the tabs vs spaces debate.
Since you explicitly mentioned fashion, I assume you read this:
> There is a distinction that the industry refuses to acknowledge: developer convenience and correctness are different concerns. They are not opposed, necessarily, but they are not the same thing.
…
The rationalization is remarkable. "JSON is simpler", they say, while maintaining thousands of lines of validation code. "JSON is more readable", they claim, while debugging subtle bugs caused by typos in key names that a schema would have caught immediately. "JSON is lightweight", they insist, while transmitting megabytes of redundant field names that binary XML would have compressed away. This is not engineering. This is fashion masquerading as technical judgment.
I feel the same way about RDBMS. Every single time I have found a data integrity issue - which is nearly daily - the fix that is chosen is yet another validation check. When I propose actually creating a proper relational schema, or leaning on guarantees an RDBMS can provide (such as making columns that shouldn’t be NULL non-NULLable, or using foreign key constraints), I’m told that it would “break the developer mental model.”
Apparently, the desired mental model is “make it as simple as possible, but then slowly add layer upon layer of complex logic to handle all of the bugs.”
My zod schemas are 100x simpler than all those SAX parsers I maintained back in the day. Honestly I kinda doubt you've worked with XML a lot. The XML data model is wildly different than that of pretty much every programming language's builtin data structure, and it's a lot of work to cross that bridge.
The article posted here makes a good point actually. XML is a DSL. So working with XML is a bit like working with a custom designed language (just one that's got particularly good tooling). That's where XML shines, but it's also where so much pain comes from. All that effort to design the language, and then to interpret the language, it's much more work than just deserializing and validating a chunk of JSON. So XML is great when you need a cheap DSL. But otherwise it isn't.
But the article you quoted makes the case that XML was good at more stuff than "lightweight DSL", that JSON was somehow a step back. And believe me, it really wasn't. Most APIs are just that.. APIs. Data interchange. JSON is great for this, and for all its warts, it's a vast, vast improvement over XML.
You’re correct that I haven’t worked much with XML. Some light parsing, mostly. When I was a kid in the early 00s, I rewrote my personal website (which wasn’t anything terribly complex, maybe 10-20 pages) into XHTML. I remember thinking that it seemed overly complicated for no clear benefit.
The article resonated with me because it was addressing a fundamental challenge I deal with constantly: watching people make decisions that allow them to ship quickly, at the expense of future problems.
The 'much harder for programmers to work with' was that the official way of doing a lot of programming related to XML was to do it in... XML. E.g. transformations were done with XSLT, query processing with XQuery. There were even XML databases that you had to query with XML (typically XQuery).
All these XML DSLs were so dreadful to write and maintain for humans that most people despised them. I worked in a department where semantic web and all this stuff was fairly popular and I still remember remember one colleague, after another annoying XML programming session, saying fuck this, I'll rip out all the XSLT and XQuery and will just write a Python script (without the swearing, but that was certainly his sentiment). First it felt a bit like an offense for ditching the 'correct' way, but in the end everyone sympathized.
As someone who has lived through the whole XML mania: good riddance (mostly).
And don't even get me started on the endless meetings of people trying to design their XML schemas.
I have found that this attracts certain type of people who like to travel to meetings and talk about schemas and ontologies for days. I had to sit through some presentations, and I had no idea what they presented had to do anything, they were so detached from reality that they built a little world on their own. Sui generis.
This is because Carmack doesn't really do OSS, he just does code dumps and tacks on a license ("a gift"). That's of course great and awesome and super nice, but he's not been painstakingly and thanklessly maintaining some key linux component for the last 20 years or something like that. It's an entirely different thing; he made a thing, sold it, and then when he couldn't sell more of it, gave it away. That's nice! But it's not what most people who are deep into open source mean by the term.
That’s just incorrect. “Open source” can mean the licensing as well as the development model [0]. It certainly has been associated with the development model since The Cathedral and the Bazaar [1].
The Wikipedia page you linked to refers to "Open-source software development (OSSD)" which implies that it's a different concept than "open source" by itself
You and Bigstrat2003 are arguing a technicality, and you're technically correct, but in context I think that's somewhat beside the point. Skrebbel and Layer8 are focused on the cultural associations of "open source" development, and this mismatch is causing everyone to talk past each other.
The original post in this thread was:
> This is because Carmack doesn't really do OSS, he just does code dumps and tacks on a license ("a gift"). That's of course great and awesome and super nice, but he's not been painstakingly and thanklessly maintaining some key linux component for the last 20 years or something like that. It's an entirely different thing; he made a thing, sold it, and then when he couldn't sell more of it, gave it away. That's nice! But it's not what most people who are deep into open source mean by the term.
Skrebbel probably shouldn't have said that Carmack "doesn't really do OSS", but what they clearly meant was, Carmack doesn't participate in the sort of community development as the Linux kernel or Apache or whatever.
More succinctly, Carmack only contributes his code to OSS, but not his time, and shouldn't impose his values on the wider community that contribute both.
> technically correct, but in context I think that's somewhat beside the point
Talking past people to argue on semantics and pedantry is a HN pastime. It may even be it's primary function.
As pointed out in the OP comment, it's basically 'money for jam' by the point he releases the source code:
> It's an entirely different thing; he made a thing, sold it, and then when he couldn't sell more of it, gave it away. That's nice!
Carmack has extracted as much profit as he could care for from the source code. The releasing of the code is warm fuzzy feelings for zero cost, while keeping it closed source renders zero benefit to him.
If that was the intent don’t you think it would be stated somewhere, or in the faq?
>“Talking” past
It’s only text, there’s no talking past. You can’t talk past someone when the conversation isn’t spoken. At best, you might ignore what they write and go on and on and on at some length on your own point instead, ever meandering further from the words you didn’t read, widening the scope of the original point to include the closest topic that isn’t completely orthogonal to the one at hand, like the current tendency to look for the newest pattern of LLM output in everyone’s’ comments in an attempt to root out all potential AI generated responses. And eventually exhaust all of their rhetoric and perhaps, just maybe, in the very end, get to the
I’m saying that “open source” can mean both things. The parent was arguing that it only means the licensing. I’m not arguing that it always means the development model.
> The Wikipedia page you linked to refers to "Open-source software development (OSSD)" which implies that it's a different concept than "open source" by itself
By that logic, “open source licensing” would also imply a different concept than “open source” by itself.
Note that the Wikipedia page for “open-source software” [2] states: “Open-source software is a prominent example of open collaboration, meaning any capable user is able to participate online in development, making the number of possible contributors indefinite”. That would really only be the case in the context of open-source development.
Appending ‘development’ seems like a significant departure from ‘vanilla’ “Open Source” to me, and wouldn’t all development be ‘closed-source’ at least between commits, if not between pull requests?
The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label “free software.”
From the beginning it was about promoting the model of developing software in an open community. The licensing is a means to that, but the motivating idea is to have open-source development.
And Netscape’s release of the source code, what lead to Mozilla, was prompted by the “bazaar” ideas presented by RMS.
I think you have confused RMS (Richard Stallman) and ESR (Eric S. Raymond). It was ESR that coined and popularized the cathedral and bazaar development analogy and terminology. It was also ESR who was at the conference your comment is discussing. RMS is “free software”, copyleft, and GNU. ESR is “open source” and the author of ‘The Cathedral and the Bazaar”.
Of course, I could have misunderstood your comment, if so, mea culpa and feel free to ignore.
I was arguing against this statement: "Open source does not mean, and has never meant, ongoing development nor development with the community." It is simply false that it has never meant that.
While you can have a cathedral-like development and publish it under an open-source license, that's not what RMS was talking about in his essay.
I'm also not arguing about what is good or bad, but about what was meant by the term "open source" when it was introduced, and how it is still understood by many people since then.
> In closed-source software development, the programmers are often spending a lot of time dealing with and creating bug reports, as well as handling feature requests. This time is spent on creating and prioritizing further development plans. This leads to part of the development team spending a lot of time on these issues, and not on the actual development.
So, in closed source you work on bug reports and feature requests. In open source you work on development. But it's the closed source people working on building a cathedral.
I understand what they're driving at, but this is still the stupidest description of the analogy that I've ever seen.
The "development model" of open source is that one person code dumps, another takes, changes it then dumps it, another picks up the copy with the changes, changes it again, and so on. Sometimes it finds it's way back.
A bazaar is a chaotic market with a million vendors, not anything remotely cooperative. The Cathedral and the Bazaar is meant to convey the idea that OSS code develops without central organization, through endless forking and cloning.
The bazaar model definitely isn't the cooperation and vibes model that the HN crowd thinks it is...
> No quiet, reverent cathedral-building
here — rather, the Linux community seemed to resemble a great
babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, which would take submissions from anyone) out of which a coherent and stable system could
seemingly emerge only by a succession of miracles.
The fact that this bazaar style seemed to work, and work well,
came as a distinct shock. As I learned my way around, I worked hard not just at individual projects, but also at trying to understand why the Linux world not only didn’t fly apart in confusion
but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders.
I always think about this section when I consider making my personal programming language public. I think if language development was, in 2026, happing the way ESR describes Linux here I might be more persuaded to release. But as it stands now, almost all modern language development is done in the rigid, semi-planned, hierarchical, and “cathedral”-esque development style.
The expectations for language developers is currently huge burden and a massive undertaking, even for small languages that look to publicize at nearly any level. The amount of users that seem to insist on participation in the language’s progress, semantics, or implementation is the vast majority of any online/vocal user base and those same voices seem to view languages with different development models as inherently toys.
I’m sure this is where I am expected to reference Rich Hickey’s comments/post about Clojure development, but I don’t have the link on mobile. But the discussions are legion and legendary at this point.
"Open source" means the source code is open to the public for reading and copying. Licenses have complicated the idealistic definition to restrict copying, but that is only within the context of taking credit (ie implicit relicensure). The only winning move is not to play the game at all.
It's been a conflation issue (and major point of contention) since the 90s. "Free Software" and "Open Source Software" are two different things that have traditionally been used together to promote the rights of the user and the dissemination of knowledge in software development.
I agree but he's arguing with people who's personal attachment to their OSS work goes a lot deeper than "I did a few code dumps back in the day".
It was stupid of me to say that he does "not really do OSS" because that opened the door for all kinds of definition arguments. That's a super tired discussion and it wasn't really my point. I can't edit anymore but I meant to say something like "doesn't do OSS in the same way as a large % of the OSS community".
It is open source, there are just many different ways to do open source code. One example is Lua, which is released as open source but the project is not open - they will not accept contributions from others.
I have the same attitude as Carmack. I have several libraries and sites I maintain as well as contributing to several popular open source projects. I still have his attitude about this. Both my open source and my ongoing maintenance are gifts. I'm also free to stop giving when I don't feel like it.
There's more to open source than just the code or output, it is also the community. There's apparenticeship, sharing of knowledge, sense of comradery, supporting each other, etc.
My day job uses a lot of open source libraries and projects, and do you know what we do when we fix things? We fork internally and don't upstream any patches.
Do you not see a loss here?
With LLMs, there's even LESS reason to keep up with upstream. We would probably just ask LLM to keep up with the changes commit by commit.
I think your idealized list of attributes of “open source” is admirable. However, the apprenticeship, comradery, and support are a specific and often sought out feature of some development ‘communities’ for specific software. I’d also say that the ‘loss’ when fixes, updates, optimizations of open source software is not up-streamed is real, but this has very little to do with adopting or promoting the externalities (no matter how laudable) you want to see in certain software’s development.
I personally don’t care about the community, its composition, or its internal structure for a lot of software I use. Even when I’m compiling from source and customizing smaller applications for personal efficiency, I’m not usually interested in being a part of some distributed community centered on that software. Some times I am engaged in the community and appreciate it and the work required to maintain that community. But in either case, the software is “open source”.
> There's more to open source than just the code or output, it is also the community. There's apparenticeship, sharing of knowledge, sense of comradery, supporting each other, etc.
No there is not. That’s what you impose on it. My code is open, free, and unencumbered. If I don’t want you using it you don’t see it at all. The licenses are there to make people happy.
That's all great, but to me the primary point is rms' original grievance with that printer driver. If the source is open, anyone can improve it. Multiple anyones can improve it! They can even collaborate on message boards and make a nice community, but this is certainly not a requirement.
> It's an entirely different thing; he made a thing, sold it, and then when he couldn't sell more of it, gave it away.
You're right and it's worth pointing out that a lot of open source has the opposite lifecycle: the authors make a thing, aren't sure how to sell it, so they open source it and hope to eventually sell something peripheral, i.e. "open core" with paid plugins or enterprise support.
In these cases, open source isn't a gift so much as a marketing strategy. So it makes sense the maintainers wouldn't see LLM training on their code as a good thing; it was never a "gift", it was a loss leader.
There's been something lost over time about the philosophy of open source. It appeared at a time when it was becoming apparent that computers represented a new type of technology where you couldn't just "look under the hood". An independent mechanic or machinist could repair a car to spec. A carpenter didn't need original blueprints of the house to create an addition. You could disassemble a typewriter or a sewing machine and with some ordinary skill actually manage to figure out how it worked. With compiled software the bar to understanding by the owner or operator was raised significantly. Open source was about being able to actually work on the thing you owned.
Edit: Note that the original term was Free Software, but there's a long history of politics about why the two are different.
Indeed. Maybe it's just a function of passed time, but it feels like people surrounded by hustlers - including themselves - look at this and think "what's the hustle behind this?" because they can't imagine anyone doing this for any other reason. I get it, but it's quite sad.
It's a function of the economy going in the shitter, with food and housing prices tripling or quadrupling while wages go up 5 or 10%. People want to be paid for their work because they can't afford to pay rent giving gifts away, and hustling is the way to survive because there aren't enough jobs or even if they have a job it's not enough.
Of course now everything is like that. Partially that's because of computers and software, but there's lots of other technologies that have contributed too.
There's an old tweet I can't find that was something like "We turned away from God when we invented the integrated circuit" that's always really spoken to the luddite in me.
the authors make a thing, aren't sure how to sell it, so they open source it and hope to eventually sell something peripheral
I know it sucks but we need to admit that this doesn't work and we need to beat the hope out of people. You aren't going to make money later. The very few cases where it worked were flukes or fake.
I think your comment leads to discussing a distinct third ‘cause’ for open source development: where a developer realizes their ambition is greater than their abilities, either in the technical sense or (more likely) in the sense that a single developer stands no realistic chance of ever completing an implementation of the idea alone.
For this class of open source development the authors essentially require the contributions and gifts of others for the project to even be realizable. I think this is the underlying basis for open source’s move toward a more “community” development model. It has led to open source being viewed by many as requiring a community and a “managed” community at that, to be open source. I think this class of open source is going to be impacted the most by LLM ‘assisted’ development (no matter how much distaste it generates for me and many others), where the hurdles of large scale development are more in reach (seemingly) for solo or very small groups of developers.
The really interesting thing is going to be to see how many of these projects move toward the Carmack ‘gift’ model and look to leave the community-centric model behind as an unnecessary externality.
He also (presumably) doesn't have to worry as much about money as many OSS folks might, so dual licensing (as a means to keep working on the OSS version while also making ends meet) is likely not something he would consider.
Yes, but IIRC it's different than the current "download the internet" large language model approach. More like learning to play video games or something.
The assumption here is that the people who maintain something in a painstaking manner did not intend people to take it and do whatever they want with it in accordance with its license?
Where and when? In cases where LLM coding assistants reproduce copyleft code in someone's work assignment? The responsibility in those would be on the user, not on AI.
Are you doing a full search of every GPL licensed repository every time you use an LLM to ensure that it isn't giving you GPL licensed code? That doesn't seem reasonable
It seems to be a common view on HN that licenses and conditional access to websites should be ignored (i.e. WRT ad-blockers), but also that licenses on Open-Source Software repositories should be respected (i.e. WRT LLM training). I believe that holding these contradictory views is common, but the conflict would need to be resolved to come to a conclusion on how to proceed with LLM training.
Replication is not the same as reproduction; I can replicate an API without violating someone's license or copyright (which I would by reproducing their work).
Developers are permitted to learn from open source code with restrictive copyrights, and apply those lessons to developing other software which does not comply with the copyright of their 'example'.
As an aside, I do believe that LLM trainers are ignoring and violating many licenses, but open-source software is not a clear example of a violation.
Depends on how you define "learn": usually, a company wanting to rebuild and publish something under a different license prohibits their developers from having ever looked at original code, to avoid the risk of copying over exact snippets out of their memory accidentally.
Copyright protects only arbitrarily non-trivial parts of the original being reproduced, but that means that you have to be careful with learning from copyrighted material. Programming books will have direct clauses allowing snippet reuse, but not for teaching purposes.
> Sure, but developers are permitted to learn from open source code with restrictive copyrights, and apply those lessons to developing other software which does not comply with the copyright of their 'example'.
This was a different argument. And there is no contradiction to separate LLMs and people.
> As an aside, I do believe that LLM trainers are ignoring and violating many licenses, but open-source software is not a clear example of a violation.
You seem to be conflating copyright with access rights. Two very different things. Regardless of your feelings on either, there is no contradiction in holding different views on them.
Well no, it’s about legally gating the ability to copy so the original author doesn’t have to compete in the same market to sell his own book with every other bloke with a printing press and a copy of the book. Everything else is an addendum.
Don’t confuse the social justification with the actual purpose of copyright law just because it’s written into the US Constitution that way. America didn’t invent copyright law.
That's because licenses are an abstract complexity tacked on to a simple material reality in order "to promote the progress of science and the useful arts".
Just like many cultural rules, they keep growing in complexity until they reach a phase change where they become ignored because they have become too complicated.
OSS licenses haven't grown in complexity all that much in the past forty or so years. They're being ignored more now because it's become easier to ignore them, not because it's become harder to abide by them.
The community is not the license. The “open source” development community is a user of that kind of licensing.
You might better describe them as the open source maintainer community. I do see how ai impacts maintainers. But I’ve dumped hundreds of thousands of loc into the bucket with no hope that anyone would really maintain it. With AI it might become part of something useful. The license has many uses.
Then by your definition, SQLite isn't open-source because it's a code dump with a license, but outsiders are not allowed to participate in shaping (the official copy of) the code.
Not sure if this was your intent, but what WOULD the result be of an AI reimplemented SQLite? They've got some of the best technical documentation in the game; there are lots of directions this could go...
It can generate plausible code because the examples are already in the training set, the documentation, the how-to-write-a-database, other databases, etc.
But unless you could write SQLite yourself it will be hard to specify a good one and to get the generator to produce a correct implementation.
I mean back in the day licensing Quake from iD was like that too. It was basically "hey, thanks for the $2 million, here's your cdr and never contact us again."
It was night and day between them and Epic back then, which I think is entirely why Unreal Engine grew to be such a juggernaut, and iD tech stagnated.
OSS is a big umbrella. At the end of the day, if you are not hurting for money, you might be okay donating your work for AI training. Meanwhile if you’re working hard on projects while sacrificing a lot (including money) you are very much allowed to not want AI use it for training if it means financial gain for a select few at the top.
It has the same undertones as how rich people talk about philanthropy. “Look I donated a portion of my wealth that barely affected my life, I must be better than all those poor people who never donate to chariTy”.
The point is not that it's not "real" open source, the point is that he has less interaction with the big part of the open source ecosystem which is feeling the brunt of the downsides of AI, namely, giant useless bug reports and PRs.
(I do agree that it's still OSS even if you never maintain it or anything.)
I agree there's a difference between publishing code under an OSS license and actively maintaining a project while fielding the flood of low-quality AI issues and PRs. Someone in the latter category is obviously closer to that pain.
I still wouldn't go so far as to dismiss Carmack's view on that basis alone, though. It just means his experience is less representative of maintainers dealing with that specific problem every day.
He only released his software as open source when there was no more money to be made with it. The idea being that even if it is of no use for him, is could be of use to someone else. In a sense, it is crazy to think of such actions as generous when it is what everyone should have done, but since being an asshole is the rule, then breaking that rule is indeed generous.
To me, working in open source means that your work goes to open source projects right now, not 10 years later when your software is obsolete and have been amortized. The difference matters because you are actually trying to make money here, and the protection offered by the licence you picked may be important to your business model.
John Carmack is making gifts, which is nice, but he wasn't paid to make gifts, he was paid to write proprietary software, so he worked in proprietary software, not open source. On one occasion, he gave away one of his Ferraris, which is, again, nice, but that doesn't make him a car dealer.
Well said. Some people are misparsing your core point here.
Skrebbel is largely referring to the OSS projects that need people to do consitent grunt work like shipping predictable releases, stable branch maintenance, backporting security fixes, etc. This is the kind of work maintains that the internet's infrastructure.
Though I agree that a healthy, vibrant, open source software project requires community and merge maintainer(s), open source "code dumps" (contributions of one's work for others to share) are open source.
There's no need to shame or diminish people into a different open source contribution pattern.
We can be grateful for open source code dumps with no express or implied commitment to future performance. We aren't entitled to ongoing support or ongoing development.
Furthermore, there are different types of contributors.
So often the people with divergent thinking and creative problem solving abilities aren't apt to stay focused on one thing for so long.
It's normal for more operations-focused folks to handle the day-to-day on things designed by sometimes flighty, absent-minded, distracted, and unreliable chief engineers such as the aforementioned.
Unless they want to stick with a project, you probably don't want to force those types to do the normal operations daily grind that's so normal to most people.
>This is because Carmack doesn't really do OSS, he just does code dumps
OSS wasn't always endless PRs and other git-specific related crap, and I think that line of logic is fucking ridiculous.
Open source when I started was a website or BBS where a tarball of code was there waiting for me to download it. It wasn't PRs/issues/CI/career-finagling/virtue-seeking/etc; it was just the tarballl full of source code.
I agree wholeheartedly with Carmack and I am glad to see people with that perspective. I think exactly the same with regards to all of the OSS projects and code that I put out for 20+ years before LLMs were a thing. nothing changes; i'd do it again.
I didn't do it to make a career, I did it because I believe in the greater ethos of OSS.
The article talks on and on about what document to craft to fool an AI, but how does he gain access to the target's database? How can he randomly inject data into some AI bots sources?
Like why does it even matter what kind of page to craft when some company's AI bot source database is wide open? I simply don't understand this kind of post, they do lots of effort to suggest that this is a super big scary vulnerability but actually the "vulnerability" is:
> Each [automated pipeline into your knowledge base] is a potential injection path.
Good question, the attack doesn't require direct DB access. Many RAG pipelines auto-ingest from web crawlers, RSS feeds, third-party docs, or user uploads. If an attacker can get a crafted document into any of those pipelines, they control what context gets retrieved. The threat is the ingestion surface, not the database itself.
Insider threat. Every fucking large business has disgruntled employees, like Meta right now after finding out about Zuck's plan to flatten all roles to ICs
How is that different from "People with access to your CMS can put terrible lies on your company website"? The vulnerability is still "people who have access to things have access to things" but written maximally sciencey to hide the fact that there's no vulnerability.
Not really. Even LEGO Classic has way too many different colors (and only a few bricks of each), and too many weird shapes. Even if you buy a lot of it, it's hard to make your own designs that actually look nice (as in, not having that one incorrectly-colored brick in that one place, and so on).
I for the love of God can't comprehend why LEGO Classic has 4 shades of blue. It makes everything worse.
Yeah it was pretty spectacular. The author was a bit paranoid, had never shared his sources with anyone or backed them up anywhere or version controlled them to a remote SVN server or anything like that. And then his hard drive failed and Buzz development was over. IIRC there even was a community-organized crowdfunding campaign to fund some fancy data recovery company to try and revive the hard drive so he could get the sources back (not sure if this ever turned out happening).
> That looks complicated, but remember how we built it: we looked at the hints and selected one option at a time. Now, if this is a log type we’ll use often, we are going to start to be able to write out that incantation without even looking at the hints. It’s both discoverable and efficient.
The important part is you don’t have to remember that gobbledygook. I don’t know why author posted that key stroke list as it seems to remove value from this post and make it look harder than it is.
Magit surfaces all available commands and options for you, along with key shortcuts as well as the actual git cli counterparts if you want to learn the raw command, too.
These are indicated through context menus throughout specifying what the responses should be. It's a minimal UI though, and where `git rebase` is confusing magit rebase is confusing.
Yes, XML is more descriptive. It's also much harder for programmers to work with. Every client or server speaking an XML-based protocol had to have their own encoder/decoder that could map XML strings into in-memory data structures (dicts, objects, arrays, etc) that made sense in that language. These were often large and non-trivial to maintain. There were magic libraries in languages like Java and C# that let you map XML to objects using a million annotations, but they only supported a subset of XML and if your XML didn't fit that shoe you'd get 95% of the way and then realize that there was no way you'd get the last 5% in, and had to rewrite the whole thing with some awful streaming XML parser like SAX.
JSON, while not perfect, maps neatly onto data structures that nearly every language has: arrays, objects and dictionaries. That it why it got popular, and no other reason. Definitely not "fashion" or something as silly as that. Hundreds of thousands of developers had simply gotten extremely tired of spending 20% of their working lives producing and then parsing XML streams. It was terrible.
And don't even get me started on the endless meetings of people trying to design their XML schemas. Should this here thing be an attribute or a child element? Will we allow mixing different child elements in a list or will we add a level of indirection so the parser can be simpler? Everybody had a different idea about what was the most elegant and none of it mattered. JSON did for API design what Prettier did for the tabs vs spaces debate.
reply