This reveals a staggering level of incompetence, if that’s really all it is, and lack of transparency.
They don’t have ANY product-level quality tests that picked this up? Many users did their own tests and published them. It’s not hard. And these users’ complaints were initially dismissed.
I don’t think the high vs medium change is really on par with the others. That’s a setting you change in the UI, and depending on what you are doing, both effort levels are pretty capable, they just operate a bit differently. Unless I’m missing something and they are saying they were doing some kind of routing behind the scenes.
If they are constantly pushing major changes to the prompts and workings of the tool, without communicating about it, and without testing, it’s likely there are other bugs and quality-degrading changes beyond the ones in this article, which would make a lot of sense.
I came to Deno because I needed a break from Node/NPM. I don’t agree with all of Node’s decisions (particularly the ES module debacle), but Node/NPM have improved over the years.
A big problem with JSR was no private packages. All your code has to be open source. But JSR is the only way to get constraint solving in Deno, besides using NPM.
I find the irreverent tone refreshing, personally.
As a founder who built all my prototypes and side projects on Deno for two years, I personally think Deno’s execution was just horrible, and avoidably so. Head-scratchingly, bafflingly bad decision-making.
I was the first engineering hire at Meteor (2012-2016), and we made the mistake of thinking we could reinvent the whole app development ecosystem, and make money at it, so I have the benefit of that experience, but it is not really rocket science or some insight that I wouldn’t expect Ryan Dahl and team to have, in the 2020s.
They were stretched thin with too many projects, which they were always neglecting or rewriting, without a solid business case. They coupled together runtime, framework, linting, docs, hosting, and packaging, with almost all of these components being inferior to the usual tools. The package system became an absolute nightmare.
If the goal was to eventually replace Node and NPM with something where TypeScript was first-class, there was better security, etc, they could have done a classic “embrace and extend.”
This piece starts off making it sound like the computer is pretty much doing all the work, while the human maybe weighs in on a matter of taste once in a while, if they like, but by the end, the list of what the LLM can actually do is really short. Implementing a sorting algorithm for you, perhaps, but not necessarily one without “egregious flaws,” and really you should still use a library for that. Replacing high-quality libraries of mature software, that have tests, etc, is obviously one of the poorer uses of vibe-slop coding.
It comes down to “adding code” that attempts to, or seems to, achieve something.
I always interpreted cathedral vs bazaar as being about the architecture of large things. Do you build to a master plan? Or does everyone do whatever they want? (Within some kind of framework, of course.) Like the cathedral of the Java SDKs vs the flea market of NPM.
This author seems to have some kind of attitude about organization in general—anything with people and process, that happens to exist around some project, that might require at least a small commitment to be a part of. Like complaining that a flea market has a form to sign.
The ability for people to functionally collaborate, with some kind of structure, is the key thing that enables building large things together.
A curly brace is multiple tokens? Even in models trained to read and write code? Even if true, I’m not sure how much that matters, but if it does, it can be fixed.
Imagine saying existing human languages like English are “inefficient” for LLMs so we need to invent a new language. The whole thing LLMs are good at is producing output that resembles their training data, right?
Upvoted because educational, despite the AI-ness and clickbait.
I’ve worked at orgs that used Postgres in production, but I’ve never been the one responsible for tuning/maintenance. I never knew that Postgres doesn’t merge pages or have a minimum page occupancy. I would have thought it’s
not technically a B-tree if it doesn’t.
I would be really interested in Fly if it abstracted persistent storage. An exciting use case to me would be something that doesn’t with “...for caching.”
Wow, I wasn't expecting my email to Jeff to end up as a front-page blog post!
The point here is that Markdown doesn't have a spec, nor do any of its variants to my knowledge, so I was proposing to come up with some Markdown-like language that does have a spec. Under discussion here is the more ambitious (but also appealing) plan of writing an official spec for Markdown, the same way JavaScript got a spec in the form of ECMAScript that we now identify with JavaScript itself.
A spec is a long, tedious, human-readable document that explains the behavior of a system in unambiguous terms. Specs are important because they allow us to reason about a language like Markdown without reference to any particular implementation, and they allow people to write implementations (Markdown processors) independently that behave identically. The Markdown Syntax Documentation is not a spec (it's highly ambiguous), nor is any implementation (not human-readable; some behaviors are probably accidental or incidental and difficult to port perfectly). The hard part of writing a spec is codifying the details in English, and secondarily making decisions about what should happen in otherwise ambiguous or undefined cases.
My motivation for working on a Markdown spec is first and foremost avoiding "bit rot" of content, which happens when we write content against one Markdown implementation and then later process it with another. We don't have this concern with HTML, JSON, or JavaScript, or at least we know what bounds to stay within to write code that will work on any implementation. This is achieved through specs, even if only implementers ever read them.
I would love pointers to Markdown processors that are implemented in a more principled way than the original code, for example using standard-looking lexing and parsing passes, but that still handle nested blockquotes and bullet lists together with hard-wrapped paragraphs.