> No one has ever made a purchasing decision based on how good your code is.
absolutely false.
> The general public does not care about anything other than the capabilities and limitations of your product.
also false.
People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly).
The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.
You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.
> You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.
Exactly, thank you for putting it like that.
So far it’s been my observation that it’s only the people who think like the OP who put the situation in the terms they did. It’s a false dichotomy which has become a talking point. By framing it as “there are two camps, it’s just different, none of them is better”, it lends legitimacy to their position.
For an exaggerated, non-comparable example meant only to illustrate the power of such framing devices, one could say: “there are people who think guns should be regulated, and there are people who like freedom”. It puts the matter into an either/or situation. It’s a strategy to frame the conversation on one’s terms.
I agree with OP's distinction. However just because you see software as a means to an ends, doesn't mean that you don't feel that quality and craft are unimportant. You can see the "craft" oriented folks as being obsessed with the form of their software. A "craft" oriented engineer might rewrite a perfectly functioning piece of software to make it what they perceive to be "easier to reason about". I consider most software rewrites to be borderline malpractice.
I think the kind of surface level rewrites that people rag on are pretty rare, at least in my experience. Realistically code that's impossible to understand, underdocumented, and lacking in proper abstractions is also deficient code. If you've ensured that the code is "good enough", you will likely hit a bug or feature request that is hindered by the poor structure and understanding of the code.
It's totally fine to say "the code works, that area is stable, let's not mess with that code". I make those kinds of tradeoffs on a near daily basis. But let's be real, "perfectly functioning code" is an ill defined, moving target. What looks like perfectly functioning code to a sibling team or a PM, could be a massive liability to someone who actually knows the code.
But then again I'm writing OS and performance critical code. A 1 in 1 million bug is easier to ignore in a throwaway log viewer website.
The most productive teams I've seen (eg at Jane Street) rewrite things all the time, and still move faster than any "normal" teams I've seen. I remember when I interned there over a decade ago, they were already on like the seventh? version of their incremental computing framework, and were building a new build system. But they were also incredibly effective at getting things done both on a per-engineer basis and in terms of making money.
With bad code it’s often almost impossible to improve the functionality or correctness or performance of the code, without first rewriting parts of it.
That example doesn't work well. All regulations come at the cost of freedom, and every freedom comes at the cost of regulations. While it isn't a strict binary (either 100% freedom or 100% regulation), enacting regulations do interfere with freedom. So this isn't just framing, it demonstrates a relationship between the two concepts, which may become relevant down in the discussion, if it already hasn't.
Regulation can cause freedom to be balanced differently between parties. For example, regulating smartphone manufacturers can result in more freedom for users. It’s not true that regulation necessarily reduces freedom overall (to the extent that that can even be graded). Just like rights, freedoms aren’t absolute, and one’s freedom often impinges on someone else’s freedom.
The increase of freedom of the users is an indirect side effect, intentional or not, which, as you put it, can happen, or not. But a direct effect, which is guaranteed to happen, is the loss of freedom of the manufacturer. Whether that's a good thing, that's another topic.
The increase of freedom of the slaves is an indirect side effect. But a direct effect, which is guaranteed to happen is the loss of freedom of the slaveholder.
That's certainly a perspective, specially given how slavery is often regulated into law.
But I digress, there's a plentiful discussion to be had about the ethics and morality of freedom/regulations, but my point is how there is, in fact, a dichotomy between both and it isn't just framing. Which, in a sense, you just corroborated.
> People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly).
I would classify all of those as "capabilities and limitations of your product"
I read OPs "good code" to mean "highly aesthetic code" (well laid out, good abstractions, good comments, etc. etc.), and in that sense I agree no customer who's just using the product actually cares about that.
Another definition of "good code" is probably "code that meets the requirements without unexpected behavior" and in that sense of course end users care about good code, but you could give me two black boxes that act the same externally, one written as a single line , single character variables, etc. etc. etc. and another written to be readable, and I wouldn't care so long as I wasn't expected to maintain it.
>but you could give me two black boxes that act the same externally, one written as a single line , single character variables, etc. etc. etc. and another written to be readable, and I wouldn't care so long as I wasn't expected to maintain it.
The reality of software products is that they are in nearly in all cases developed/maintained over time, though--and whenever that's the case, the black box metaphor fails. It's an idealization that only works for single moments of time, and yet software development typically extends through the entire period during which a product has users.
> I read OPs "good code" to mean "highly aesthetic code" (well laid out, good abstractions, good comments, etc. etc.)
The above is also why these properties you've mentioned shouldn't be considered aesthetic only: the software's likelihood of having tractable bugs, manageable performance concerns, or to adapt quickly to the demands of its users and the changing ecosystem it's embedded in are all affected by matters of abstraction selection, code organization, and documentation.
But those aesthetics stem from that need for fewer bugs, performance, maintainability. Identifying/defining code smell comes from experience of what does and doesn’t work.
> I wouldn't care so long as I wasn't expected to maintain it.
But, if you’re the one putting out that software, of course you will have to maintain it! When your users come back with a bug or a “this flow is too slow,” you will have to wade into the innards (at least until AI can do that without mistakes).
But the thing is that someone has to maintain it. And while beautiful code is not the same as correct code, the first is impactful in getting the second and keeping it.
And most users are not consuming your code. They’re consuming some compiled, transpiled, or minified version of it. But they do have expectations and it’s easier to amend the product if the source code is maintainable.
> obviously created by people the care deeply about the quality of the product they produce
This obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product. They get real nice paychecks, benefits and put dinner on the table for their families. That's the market.
> There is no substitute for high quality work.
You're right because there really isn't a consistent definition of what "high quality" software work looks like.
> This obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product. They get real nice paychecks, benefits and put dinner on the table for their families. That's the market.
Those first three are "enterprise" or B2B applications, where the person buying the software is almost never one of the people actually using the software. This disconnect means that the person making the buying decision cannot meaningfully judge the quality of any given piece of software they are evaluating beyond a surface level (where slick demos can paper over huge quality issues) since they do not know how it is actually used or what problems the actual users regularly encounter.
Users care about quality, even if the people buying the software do not. You can't just say "well the market doesn't care about quality" when the market incentives are broken for a paricular type of software. When the market incentives are aligned between users and purchasers (such as when they are the same person) quality tends to become very important for the market viability of software (see Windows in the consumer OS market, which is perceptibly losing share to MacOS and Linux following a sustained decline in quality over the last several years).
You literally just told me the market doesn't care about quality. I don't get what point you're trying to make?
> When the market incentives are aligned between users and purchasers (such as when they are the same person) quality tends to become very important for the market viability of software
Right, but this magical market you're talking about doesn't exist. That's my point.
Have you seen Facebook's code quality? Have you seen any-big Chinese corpo code? There are a lot of very profitable businesses in the world with endless amount of tech debt. But tech debt is not necessarily a big deal in most scenarios. Obviously I'm not talking about mission critical software, but for general consumer/business software, it's fine. The hard part is understanding where you can cut the costs / add debt, and that comes from requirement gathering.
> You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product.
What about caring and being depressed because quality comes from systems rather than (just) individuals?
I couldn't book travel at a previous company because my address included a `.`, which passed their validation. Awful, awful software. I wouldn't expect slop code to improve it.
Now imagine how much they would make if their software was good.
Google, Facebook, Apple clearly care deeply about the quality of their code. They have to because bugs, bad performance, outages, vulnerabilities have very direct and immediate costs for them. I know Amazon and Microsoft have their critics but I bet they are also better than we give them credit for.
There are factors besides software quality that affect their success. But running bad software certainly isn’t going to help.
>Google, Facebook, Apple clearly care deeply about the quality of their code.
Yea, idk about that one.
They definitely did care in the past. They had to if they wanted to get users. But they've stopped caring a good while ago. Especially Microsoft. The costs that bad code would bring them is lower than the cost of developping good code, because they can mostly rely on monopolies and anti-competitive practices for user retention. Their users are more like hostages than anything else.
Is Google much better? I don't see, for example, the care that used to go into the quality of organic search results.
They seem fine with the output of the current hodge-podge of the original algorithm results plus massaging by many downstream ML pipelines that run one after the other without context of how each stop might affect the next.
> You're right because there really isn't a consistent definition of what "high quality" software work looks like.
And if you can deterministically define "high quality software" with linters, analysers etc - then an AI Agent can also create high quality software within those limits.
Thank you for putting out a clear message. I completely agree.
> parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.
and of course, this isn't even the worst. A lot worse can happen, such as data loss and corruption. Things that can directly affect people's lives in real life.
As a developer, these things are constantly on my mind, and I believe this is the case for people who do care about the quality.
As has been said elsewhere many times, AI producing code is not the same as say, a compiler producing machine code. It is not such a well-defined strong abstraction, hence why code quality still is highly relevant.
It is also easily forgotten that code is as much a social construct (e.g. things that have to be done in certain ways due to real life restrictions, that you wouldn't have to do in an ideal world).
Sometimes I feel very powerless though.
It feels as if some of us are talking past each other, even if we seemingly are using the same words like "quality".
Or in a way, that is what makes this more futile-- that we are using the same words and hence seemingly talking about the same thing, when we are referring to completely different things.
It is difficult to have a conversation about a problem when some of us don't even see it as a problem to begin with-- until it reaches a point when it starts affecting their lives as well, whether it be directly or indirectly.
But that takes time.
Garbage software that is slow as a dog has been winning. While we’ve been obsessing over our craft and arguing about what makes software beautiful, slow crappy software has taken over the world.
Quality of code is just not that important of a concept anymore for the average web developer building some saas tool. React code was always crap anyways. Unless you are building critical systems like software that powers a plane or medical equipment, then code quality just doesn’t really matter so much in the age of AI. That may be a hard pill to swallow for some.
I believe a lot if large software companies like Google, Facebook, Apple, Netflix, Microsoft have very high quality code. Past a certain level of complexity, bad code will just collapse under the weight of its low quality.
I don't think complexity is the right metric. The listed companies still do write a lot of shit software, but mostly smaller things you don't see much. Anything in the 'fast path' of these companies is getting executed trillions or quadrillions of times and because of that any bugs will become shallow.
I think you can scrap Microsoft there when it comes to their pc stuff and their mainly B2B stuff (dynamics and the like)
As for the rest other than apple I think pageloads are an obvious metric to track and there's always going to be a contingent of their programmers incentivized to care about their code quality because slow code and the like runs on their machines at such scale that it often costs them a lot of money, same with uptimes of various services. Their amount spent on wages is comparatively very low.
There's a lot of space between web dev and medical equipment. I've never met a user that loved how often their work was lost or how long it took to implement feature requests amid all the ship-it-quick duct tape.
> then code quality just doesn’t really matter so much in the age of AI
Except at scale it really does, because garbage in garbage out. The crappier the code you feed the current models, the worse and more confusing the broken leaky abstractions, the more bugs the AI will generate.
The question is whether it has to be that way. Developers who are against slop don’t believe that the current state of software is the best possible world.
> The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.
Exactly. A lot of devs optimizing for whether the feature is going to take a day or an hour, but not contemplating that it's going to be out in the wild for 10 years either way. Maybe do it well once.
> but not contemplating that it's going to be out in the wild for 10 years either way
I think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.
>I think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.
And in almost all of those cases, they'd be wrong.
I think I calculated the half-life of my code written at my first stint of Google (15 years ago) as 1 year. Within 1 year, half of the code I'd written was deprecated, deleted, or replaced, and it continued to decay exponentially like that throughout my 6-year tenure there.
Interestingly, I still have some code in the codebase, which I guess makes sense because I submitted about 680K LOC (note: not all hand-authored, there was a lot of output from automated tools in that) and 2^15 is 32768, so I'd expect to have about 20 lines left, which is actually surprisingly close to accurate (I didn't precisely count, but a quick glance at what I recognized suggested about 200 non-deprecated lines remain in prod). It is not at all the code that I thought would still be there 15 years later, or that I was most proud of. The most durable change appears to be renaming some attributes in a custom templating language that is now deeply embedded in the Search stack, as well as some C++ code that handles how various search options are selected and persisted between queries.
I think this both proves and disproves the original point. Most of your code is temporary. You have no idea which parts of your code is temporary. It's probably not the parts that you wish were temporary, which will almost certainly be made permanent.
In my experience the code will, but by year 5 nobody is left who worked on it from inception, and by year 10 nobody knows anybody who did, and during that time it reaches a stage where nobody will ever feel any sense of ownership or care about the code in its entirety again.
I come into work and work on a 20 year old codebase every day, working on slowly modernizing it while preserving the good parts. In my experience, and I've been experimenting with both a lot, LLM-based tools are far worse at this than they are at starting new greenfield projects.
When it comes to professional development, I've almost never worked on a codebase less than 10 years old, and it was always [either silently or overtly] understood that the software we are writing is a project that's going to effectively live forever. Or at least until the company is no longer recognizable from what it is today. It just seems wild and unbelievable to me, to go to work at a company and know that your code is going to be compiled, sent off to customers, and then nobody is ever going to touch it again. Where the product is so throwaway that you're going to work on it for about a year and then start another greenfield codebase. Yet there are companies that operate that way!
How can you possibly know which type of repo you're in ahead of time? My experience is that "temporary" code frequently becomes permanent and I've also been on the other side of those decisions 40 years later.
Unless you’re producing demos for sales presentation (internally or externally), it’s always worth it to produce something good. Bad code will quickly slow you down and it will be a never ending parade of bug tickets.
That depends on how quick the feedback loop is for your decisions. If it takes weeks or months to find the impact of your changes, or worse, if you're insulated somehow from those changes, you may not be pushed toward improving the quality of your code.
That's where you get it wrong. The world is full of mediocre and low quality work in many, many fields. We all, in fact, depend on mediocre work in many ways.
Many, many people would prefer a solution with mediocre or even bad code than no solution at all while they wait for "high quality work" that never appears.
The magic of LLMs, especially as the technolgy improves, is that a truly mind boggling number of solutions to problems will be created with thoroughly mediocre (or worse!) LLM generated code. And the people benefitting from those solutions won't care! They'll be happy their problems are being solved.
No, you see, this is impossible, as I've been taught here on HN by the wise elders over and over. As soon as a pristine codebase is tainted by even 1% of LLM-generated code, any chance at potential user value instantly disintegrates. Especially if it claims to do anything remotely novel!
But seriously, the denial is incredible to watch. Our product wouldn't exist without LLMs, and our users are vocally thankful that it does, saving them time and money and helping them reach their offline goals.
If a product looks pretty and seems to work great at first experience, but is really an unmaintainable mess under the hood, has an unvetted dependency graph, has a poorly thought through architecture that no one understands, perhaps is unsustainable due to a flawed business model, etc., to me it simply suffers from bad design[0], which will be felt sooner or later. If I know this—which is, admittedly, sometimes hard to know (especially in case of software products compared to physical artifacts)—I would, given alternatives, make the choice to not be a customer.
In other words, I would, when possible, absolutely make a purchasing decision based on how good the code is (or based on how good I estimate the code to be), among other things.
[0] The concept of design is often misunderstood. First, obviously, when it’s classified as “how the thing looks”; then, perhaps less obviously, when it’s classified as “how the thing works”. A classification I am arriving at is, roughly, “how the thing works over time”.
Demos might ne nice an flashy. But eventually you actually have to have generally working product. Too many issues with too many annoyances and eventually users of even enterprise software will be heard. Especially so if there is some actual loss of money or data that is not corrected very fast.
In the end software is means to the end. And if you do not get to end because software is crap it will be replaced, hopefully by someone else.
Have you taken a look at the world in the past… I dunno, at least several decades. That ceased to be true somewhere around the time I was in high school, maybe before.
I would add to that for software that has scaled to the point that it needs to run in a distributed fashion, code quality will show up very quickly in dollars and sense.
High latencies, outages, memory leaks, security vulnerabilities, will be seen in your AWS bill or whatever hardware or service you deploy your software to. If your code isn’t clear enough to understand what it’s really doing, you have no chance at preventing or addressing the above.
This is provable false. First in B2B software the user is not the buyer. The reasons the buyer buys software is usually big because how well it performs but for a lot of other reasons.
It is a spectrum and the perspectives of people change based on where they are on the spectrum. It is genuinely hard to keep up with things and also keep my emotions in check to stay objective
I treat the code I produce as my craft and I appreciate I can afford it and enjoy the output.
I know engineers who aren't that lucky and struggle in "enterprise" software development, where slop was a feature for decades - people making decisions won't use the software (their low paid employees will) and software monstrosities need a hell a lot of support which sometimes brings more revenue than the original purchase.
Is it really? I disagree strongly on all points, but know where you are coming from by an intuitive sense. I am a dev since the 80th and know how to make 64kb do wonders. It just took us years to find out.
You present no proof only touchy feely it must be so otherwise pseudo proof like software longevity is on the line.
Please first define software longevity quality in detailed terms: what is it exactly and how to you assess it regarsing quality and quantity?
Doom is judged by myself and by its versatility a masterpiece however, we all know and the Black Book is quite open about it the code itself is arguably not hitting modern standards as of today and there is a infamous WTF hardcoded value used to do speed code. So what? It inspired a whole generation. Second reality? A mindbender demo that accelerated quite a few finish developer careers has sadly forgotten after it was once considered for decades to be for the demo scene on PC what Doom was for the underground gamer scene. A nice match anyway.
Is Windows a masterpiece or not? Judging by its UX/UI definitely not, by its versatility and transposable potential I would rate it a masterpiece.
1000th of developers work on some code basis which change chipsets and compiler settings quite significantly - so there are ups and downs even in domains where a simple deadline and a requirement change suddenly makes technological prowess useless trash.
And the most heretical question ever: what if your so called number one quality software product might fool you and - could be way better done? You didn’t even consider that option which makes your point shaky to say the least.
And yet somehow the shittiest buggiest software ends up being the most popular.
Look through the list of top apps in mobile app stores, most used desktop apps, websites, SaaS, and all other popular/profitable software in general and tell me where you see users rewarding quality over features and speed of execution.
You have it backwards. Excellent software becomes popular, and then becomes enshittified later once it already has users. Often there is a monopoly/network effect that allows them to degrade the quality of their software once they already have users, because the value in their offering becomes tied to how many people are using it, so even a technically superior newcomer won't be able to displace it (eg. Youtube is dogshit now but all of the content creators are there, and all of the viewers are there, so content creators won't create content for a better platform with no viewers and viewers won't visit a better platform with no content).
If your goal is to break into the market with software that is dogshit from day 1, you're just going to be ones of millions of people failing their get-rich-quick scheme.
That is easy. Those top apps in mobile stores are constructed in part with compilers which are under great pressure from developers to generate good code as quickly as possible. There is often bloat at the level of the development environment or some critical library, but core developer tools are a big part of the software space and are made and sold with very different criteria from the most popular apps vended from walled gardens.
The history of technology is filled with examples where between two competing analogous products, the inferior always wins. It does not matter if it is only slightly inferior or extraordinarily inferior, both win out. It's often difficult to come up with counter-examples. Why is this? Economic pressure. "Inferior" costs less. Sometimes the savings are passed on to the customer... they choose the inferior. Other times the greedy corporate types keep all of it (and win simply because they outmarket the competitor). It does not matter.
If there are people who, on principle, demand the superior product then those people simply aren't numerous enough to matter in the long run. I might be one of those people myself, I think.
You're responding quite harshly to a pretty reasonable take. I think he means "for the most part" for those statements.
I mean Jira is probably one of the most purchased software packages in the world that is specifically used by developers that care about their craft - you don't want to look at the code, trust me.
> The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.
For now. We only call it slop when we notice it. Majority of AI text, music, images, videos and code is indistinguishable and you use it every day.
This whole "treat your code as craft" reminds me of organic farming, zero waste, etc movements. Cute movements that only minority of people care about.
> Majority of AI text, music, images, videos and code is indistinguishable and you use it every day.
I really don't think this is true. If it was, we'd be able to point to countless examples of things assumed not to be AI that actually were, but there's a dearth of such examples.
Examples _are_ countless. Look around yourself - it's simply indistinguishable. Videos are still not quite there, the biggest telltale is how short they are, but we are very very close.
> People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly
The assumption that people CARE about your product is the most Silicon Valley, Hacker News, forgot what the world out side of tech looks like thing ever.
People CARE about their software as much as the CARE about their bank, or a new finance product... People excited over software is more of a historic footnote than any thing real people think in 2026.
The vast majority of Software is one of two things:
A) a tool
B) a source of entertainment
As a tool it either needs to provide value or it's something that is shoved on you by work.
The user experience of your average mobile game today is fucking awful. People put up with a massive amount of garbage for a trickle of fun. So much of the web looks like a mid 90's Hong Kong back alleyway --- biking ads, videos screaming at you, and someone trying to steal your wallet. And the majority of things people are forced to use for work... well... Show me someone who is excited about their ERP or CMS or Network drive... Show me someone who thinks that anything to do with Salesforce is something to be excited over.
> The general public does not care about anything other than the capabilities and limitations of your product.
A segment of our industry is screaming about the security of open claw. People dont care (because we have also made a mockery of security as well) - they are using it as a tool that will deliver them a solution. It strips away all the arcanea that made people think we were wizards and writes the dam spells for them. It's a dumpster fire, and people are thrilled about it and what its delivering them. And thats software not made by you or I.
> People dont care (because we have also made a mockery of security as well) -
They will start caring when a security bug on one of their phone's apps (or on the phone's software itself) empties their savings accounts. At that point the law officials/the Government might also start to care.
Mt. Gox, FTX, and an ocean of crypto wallet exploits.
This has already happened, and unlike traditional banks, there is no "customer service" to call with a shot at reversing a transaction.
It already happens to regular businesses, and on a regular basis: from credit card skimmers to major hacks, Home Depot springs to mind, along with numerous other ones that just dont even warrant the attention.
Meanwhile, yet another supply chain attack yesterday.
Security exists in most companies to protect management and give them a head to hang when the shit hits the fan (not IF, when). It's a cost center and is getting butchered right now in many orgs (we haven't had a problem why bother).
If code is craft and minimalism is hip then why ruby, and python, and go and... when it's electrical state in machines?
That's the minimalism that's been lost.
That's why I find the group 2 arguments disingenuous. Emotional appeal to conservatism, which conveniently also props up their career.
Why all those parsers and package systems when what's really needed is dials min-max geometric functions from grand theft auto geometry to tax returns?
Optimization can be (and will be) engineered into the machine through power regulation.
There's way too many appeals to nostalgia emanating from the high tech crowd. Laundering economic anxiety through appeals to conservatism.
Give me an etch a sketch to shape the geometry of. Not another syntax art parser.
That's a name i've not heard in ages. That project was abandoned back in 2012 or so for lack of interest on all sides. The domain and site were sold back in 2014-ish to someone who blatantly misrepresented themselves as wanting to keep that piece of internet history online, but turned out to be a SEO operation which only wanted it because the domain had a decent reputation with Google. Lesson learned.
> Glad to see you're still alive and kickin' -- hope you are doing well, despite life's challenges.
Yeah, I've never really been at all offended by the "eating your own dogfood" phrase, because I always saw that as being the point also.
I must admit, however, that the title of this article was too crass for me. I came very close to not reading it at all just because of the title. In my opinion, the article would be better served by something else, but I'm just not a big fan of bathroom humor in general.
There's absolutely nothing wrong with the word picture that was used. I'd advise against assuming the worst possible interpretation of someone else's words (especially online). Most of us probably do that at least sometimes (present company included), but it would be much better to give people the benefit of the doubt. In this case, I think it is fair to assume that the original poster was just saying that he wouldn't let them try to get away and not actually deal with the problem -- much as a border collie prevents other animals from straying from the group, keeping them where they need to be.
There is no need to assume that they meant that the others in the meeting were less important or less intelligent, or whatever. They were, perhaps, just less interested in dealing with the problem.
> they bother to have a Klingon language consultant on staff
I realize there's a fair bit of money to be made, and also that many people are super invested in their favorite science fiction series, but the fact that "a Klingon language consultant" is a real thing still makes me think "wow!".
I'm currently reading a book written by the guy who created the Dothraki and High Valerian languages for Game of Thrones. He had to make what already existed in the books for, so there were a few things already set.
He was a consultant in the show as well as he was the one who had to get the actors to speak it well.
The book is called The Art of Language, and if you have an interest in conlangs, you should give it a try.
I think it is worth noting that Richard P. Gabriel wrote the forward to the book in question, and he quotes Guy L. Steele in that forward -- from the paper that you are suggesting the author might like.
Or you mean he'll probably already know about the paper? Yes, I guess that's probably the case...
I did not think about it too much to be honest, I just knew that article and thought that he would really like it if he had not read it. But I can imagine somebody writing a book on the history of Lisp has already read probably all articles around on the topic.
Yup, I know of that paper. The amount of (not or partly acknowledged) reading I've done for the book borders on the insane so I do welcome these suggestions, I've forgotten 80% of what I read and learning what others value helps me put together a "you really should revisit this" list :)
> - Every day that passes, the gulf between Lisp's tooling and what a typical user expects grows wider. It needs to escape Emacs and SLIME to something that feels complete and polished.
Can you give specific examples of "what a typical user expects" that are missing from Emacs-based programming environments (SLIME, and/or others)? I'm not suggesting there aren't any, I'd just like to know your list.
Lisp does not have that much syntax for highlighting to be a problem.
Lisp is also a symbolic language. Meaning the code work on symbols, not data, only at evaluation the value of the symbol is known. There’s a lot of symbols manipulation routines like macros, intern, package loading,… that prevent to statically know the code.
The problem is not a lack of syntax highlighting per se, but the inconsistency of existing syntax highlighting. This is especially annoying in Common Lisp due to the existence of symbol macros, where syntax highlighting would be immensely helpful.
I get that there are issues with symbol manipulation, but AFAIK language servers already evaluate code, even if not for syntax highlighting. I view this whole thing as an issue caused by the REPL workflow, not the inverse. Not to say that I would be willing to give up said workflow but it could certainly use improvements.
- Ease of setup and install. Turnkey. Good defaults.
- Non-buffer based workflows.
- Easy access to settings.
- Easy ways to change or switch my compiler.
- Integrated with typical lisp tooling for library, system, and package management. (For example, what Emacs button do I press to set or clear my ASDF compile cache?)
- Better integration of the profiler and debugger. When a Lisp error happens, yet another buffer pops up (breaking the arrangement of all your code windows you set up), this buffer may not even be the only one (but the others are hidden somewhere), and it's not clear what you can even click or expand to see more information (there's a tremendous amount, extremely non-discoverable).
- Good getting started: built in guide for structural editing, REPL workflow, etc.
...and much much more. I say all of this as someone who basically has only used and invested in Emacs for 20 years. I love sharing Emacs with people who like weird technologies and rabbit holes, the real "hacker"-type people. I hate sharing Emacs with people who want to be productive in an hour or so with a Lisp project, because I know within 5 minutes they'll be disappointed, and never get the best of the experience because it's too much uninteresting investment.
I prefer writing Lisp with Emacs+SLIME over anything else. It's extraordinarily powerful, and with enough grit, you can get it to do almost anything you want. But I'm also jealous of people who get to use, say, polished JetBrains products whose goal is to try to give you the best experience possible for your specific programming language.
JetBrains IDE plugin for Common Lisp: https://github.com/Enerccio/SLT (I'm sure you saw it before and I don't know how polish it is, and I'm pretty sure it has less features than Emacs&SLIME, yet, but I must link it for reference. Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.)
I mean the following with all due respect—and I have a lot of respect for your many efforts and contributions—but it will sound a little blunt, especially as a written comment.
"We have one," no, this is a consistent problem with people who evangelize Lisp. We have had "IDEs" for decades. Most of them, except the couple commercially supported ones, were "experimental", "incomplete", "buggy", etc. This includes the one you link here.
Are these projects valuable as a starting point for other hackers to join in and help? Sure, maybe. Are they helpful for a new programmer? Almost always the answer has been "no". I have first-hand experience subjecting a programmer to one of these tools, and I myself getting incredibly frustrated at how broken it is. Imagine somebody completely new.
You in particular love to advertise these different projects as a form of Lisp evangelism. Advertising the projects is great—I hope they attract helpers—but I think your language around them is deceiving.
> Because yes, before 2023 we could complain there were no JetBrains IDE plugin for Common Lisp, since 2023, we have one.
"We have one" in the absolutely most rudimentary interpretation of that phrase. What we don't have is a working JetBrains Common Lisp IDE suitable for production use.
In order to try to promote a realistic view as to why Lisp doesn't attract more programmers in 2026, I myself will continue to point out Lisp's highly substandard tooling offering until there's an actual product that works. Any Joe can spend a weekend making a 1/2 baked, proof of concept IDE. Even more so now with all the AI vibecoding tools we have at our disposal. It takes much more to make something that checks all the boxes.
ACK, allright. I just want to point people to stuff. Create emulation. Show that the ecosystem is evolving -in the right direction even, maybe. That we are not doomed to stay with Emacs&SLIME. A few years ago, we didn't have SLIMA, the VSCode plugin, Jupyter and JupyterLite kernels, the very useful ICL, nor CLOG, nor these incomplete IDE attempts (Intellij, Sublime…). How good is the new Zed plugin BTW? https://github.com/etyurkin/zed-cl
(I'm not even evangelizing in these comments so thanks for the feedback I guess!)
We all can google. Have you tried to install the plugin? It doesn't support the current version of the IDE and as the last commit was 8 months ago there is no hope it will get such a support soon.
TBH no people don't google (what they don't expect to see), repetition and showing links is necessary. I hadn't followed along. Hope it will get contributors.
absolutely false.
> The general public does not care about anything other than the capabilities and limitations of your product.
also false.
People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly).
The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.
You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.
reply