kbuchanan

I agree this is a problem too, but I suspect mostly for novel(ish) software problems. For me, LLMs have expanded the solution space, because, while I used to be decent with SQL in Postgres, now I'm operating on a whole new level—the LLM's ability to make sense of Postgres' full suite of options, and the performance implications of the queries, is far beyond what I could have accomplished.

I think this list demonstrates the OP's point—entrenched, resource-heavy, and reputable firms have and will continue to capture most of the markets, not for lack of competition, but by ownership over the distribution channels.

Having said that, I don't think it's all AI (this trend's been going on for a while), nor do I think startups can't thrive—as the pie gets bigger, competitors can carve out yet smaller niches, as the OP points out.

For me, working mostly in Planning Mode skips much of the initial misfires, and often leads to correct outcomes for the first edit.

Thanks for this. I'd never heard of Chiang, and now I've bought my first book!

I've had the same experience, although I feel like Claude is far more than a junior to me. It's ability to propose options, make recommendations, and illustrate trade-offs is just unreal.

Supported by my experience too. My tinnitus is very real, but when I discovered just how much of a psychological component was there, it became more manageable. Little by little I thought I was losing my hearing until I had it checked—it was perfect. The audiologist helped me understand that my constant "tuning in" to the tinnitus was creating the perception that my hearing was being harmed by loud noises and leaving a high-frequency sound in its place. Which is there, but when ignored, it largely disappears.

I think the bottom line with Clojure is it's not an ecosystem well-suited for non-veteran programmers. For as simple as the language is, effectively using Paredit, navigating partially documented libraries, diving into source code to see how things interact—it's tough as a new developer. I don't believe Clojure is overtly hostile to newcomers; it's just crafted by veterans, for veterans. And this is the result.

We embraced Hotwire with a Clojure backend. Favorite things:

- One language model (i.e. no JS, just our favorite backend language)

- Extremely minimal front-end tooling

- All data is manipulated with the same tools

- No client-side routing, validation, or... really much at all

P.S. We even wrote our own import-maps solution to avoid needing a JS bundler for the small stuff you can't do without JS.

How do you prevent ⌘+Tab from automatically jumping you between desktops? At that point, the desktops feel like impediments, not boundaries.

Yeah, I see no reason a terminal should require an account. Turned me off too.

Folks will naturally ask, "How did you get to this point?"

One insight into successfully walking away from addictions is recognizing that this thing (e.g. alcohol, cigarettes) is unambiguously poisonous. "When I [take/do] this, it will take more than it gives."

Hard to articulate, but it happens when the scales that painted the substance with redeeming qualities falls from your eyes. Sorta like discovering you've entertained a damaging relationship for too long. However much worth this person has, being in a relationship with them is not good for you (or others, usually).

I offered a counter example to the comment author too (Clojure has been wonderful for us), but I do wonder if there is one area where OO languages excel above functional: the shape of the code hints at the shape of the data.

In Lisp, function names describe actions. In OO, classes, inheritance, static properties, and getters and setters give at-a-glance hints as to the shape of the application's data model. In Clojure, we compensate, as you pointed out, with forms of documentation. I'll take that trade-off any day—I never want to go back to classes! But it's perhaps one reason for which Clojure has a reputation of being hard to read by other devs.

Oh man, this is not my experience. We may be different because we are a small company, and Clojure is our main language. But, we have a Clojure codebase of 90K lines, and is 10 years old. It has its problems, and while your points about an opaque data model resonate, for us, tests, specs, and assertions provide enough hints to help newcomers. And... where I disagree the most: the quality and professionalism of the developers who work on it are unparalleled. New, senior-level developers, quickly catch on to the system. I am grateful to Clojure __because__ it attracts this caliber of developer.

He argued that if universities cared about diversity their positions on affirmative action would be more dynamic than is commonly accepted. e.g.:

Affirmative action would also apply more strongly to, say, immigrants from Iran, or Korea, or Israel, than to black people (or anyone else) from our own society.

The examples he uses demonstrate that, in his mind, caring about diversity requires measuring circumstance. You might argue that universities are not so shallow as he's claiming, but I don't believe the article is mere mudslinging.

I hated college. I never finished for the frogs. But I'm a lifelong reader. I don't regret failing to get a degree, but I regret that I wasn't in the right mindset and that I could have used the time to create meaning.

This sounds wonderful; I'm super supportive. But, is there anyone who can articulate the trade-offs without the snark? Are there research groups that benefited from the revenue who will now have to raise even more funds?

What's made it take so long? (Beyond just "entrenched interests...")

It also bends credulity. It suggests 7 of 10 developers work for companies (or know someone who has) that fail to prevent onslaughts of their developers from leaving over deployment problems.

This post reminded me a little of my real estate agent's newsletter:

2007: There's never been a better time to buy! 2008: There's never been a better time to buy! 2012: There's never been a better time to buy! 2020: There's never been a better time to buy! 2022: There's never been a better time to buy!

This is a great example of how on an individual level commentators want to bend democratic processes to achieve their own goals, but, without fail, they get caught in a tangle of contradictions. What is the Supreme Court's mandate? To stop climate change? To feel out the majority's opinion and make a legal path for it?

This is why democracy is so hard: it consistently yields outcomes that are disappointing to a large segment of the population. There is no "solution" to that problem, and shouldn't be. There are pathways to curbing carbon emissions, but the reality is that too few people, as a body, want to pay that price.

What is their next best alternative? Rescinding offers is a way to show loyalty to those who already work for you.

While I'm extremely sympathetic to this idea, one question nags at me: Long-tail code can also be long tail because _it was well-written from the beginning_. The author is arguing that long tail code lives in a stable, unchanging corner of the business. This can absolutely be true, but it can also be true that a well-written abstraction may service new needs without needing to be changed. (In practice, this is hard.)

It doesn't just keep on improving, but stays backwards compatible with every new release!

As a founder myself, I echo this sentiment, that building and selling are indeed not the same thing. They are both important, but having a mindset for marketing, selling, finding an audience, either yourself, or in a co-founder, is essential.

And it never stops being important.

It's a great example. This is the very reason I have scaled back the amount of time I rock climb as I've gotten older -- not because any individual outing is dangerous, but there's an element of Russian roulette wherein the mere act of doing it more often dramatically changes the risk.

It's true, the Clojure ecosystem is especially hostile to newcomers—in my view it's the principle reason the language has not grown more quickly. There are community members have made the documentation much more manageable, but beginners are still very much left to their own to discover solutions to pretty common problems.

But I disagree that it reflects poorly on the maintainers—rather, I think it illustrates that, for the most part, Clojure was created by experienced language pragmatists, for other experienced pragmatists. Clojure tends to be a refuge from other languages, not something a person is born into. The State of Clojure each year consistently shows how many other languages Clojure users already knew before coming to the language. I appreciate how the maintainers value backwards-compatibility (nothing ever breaks, it only gets better), that they are strongly committed to making the language great in the long run, and are unmoved from the language's founding values.

I do hope as a community we can do a better job for newcomers, for all our sakes—new blood brings new perspectives, but it's okay that "growing the community" isn't the Core team's top priority. (But hopefully becomes someone's priority in the community at some point...)

Inline evaluation is overwhelmingly what I miss from vim-fireplace when I moved to Cursive. Having said that, the code navigation tools are so much better.

Yeah, but it's unprofessional in just the right ways, which signals sophistication lol.

Learn Clojure. Then you can spend the rest of your life building with hand tools, lol: https://www.youtube.com/watch?v=ShEez0JkOFw

(Seriously, though, Clojure is awesome—but occasionally I miss the guardrails of a framework.)

Wholeheartedly agree. I can't help but feel with each new article like this that many journalists are watching _their own WFH opportunities_ slip from their fingers.

(FWIW, I'm a fan of fully remote companies; this article just doesn't pass as anything but opinion.)

I just wanna give a shoutout to Facebook for finding a balance between rapid, innovative development on a major library without constantly introducing breaking changes. On the backend I'm a Clojure dev, and this approach has long been a standard in clojure.core which has earned my loyalty for many years. Wish more projects could be like this.