Clojurians Log v2

That was a very good read! Thanks 🙏

Interesting piece and while I agree about the self-reinforcing conservative nature of software development, I was struck by how the weakest parts of the writing (to me) were the ones specifically about software development...that segment about React and Vue and how they marginalize and devalue certain skillsets came off as a little bit hokey to me unfortunately

It's not always easy to come up with a perfect illustrative example, but I thought it worked well enough. For something closer to home consider the difference between a static site generator written in Clojure that uses hiccup and garden, vs something like Jekyll that just uses HTML/CSS with some templating. I use something Clojure based if it's just me working on the thing, but e.g. for Heart of Clojure/HeartConf we use vanilla Jekyll, precisely because it's a better basis for collaboration. Similarly for Gaiwan at some point we switched from a custom site built in clojure to Ghost, so our CEO could publish her own posts.

I'm certainly not denying that some of these products have greater implicit barriers to entry/usage/understanding, but I thought the conclusion she drew from it ended by falling a little flat, because from my own experience and talking to a lot of other devs, UI/UX and design work is not devalued in their eyes, they simply don't want to do it because it's a pain in the butt to get right and do well.

As soon as I saw the Heidegger reference tho, I already knew where this was going. I think we really need to broaden our philosophical basis for thinking and writing about technology

An interesting thing she kinda glosses over (I understand why) is the distinction between "zuhandenheit" and "vorhandenheit". She is working with the former but for Clojurians the latter probably has more resonance because it is quite similar to Rich Hickey's ideas of what is "easy": https://philopedia.org/terms/vorhandenheit/

I enjoyed reading that article. it is well written and has a lot of examples of the arguments used. It makes a few sweeping statements. If I would have to try and summarise it in a single sentence then it basically lead to an argument that the use of LLM's as a tool results in carelessness and possibly slop (there is a lot more in the article of course). In my personal experience, the opposite can be true as well. The use of LLMs can support a willingness to explore alternatives, challenge assumptions, and explore reasoning. In my mind the framing that "tools are not neutral" isn't as scary as it sounds. In essence non-neutrality does not translate directly to harmful does it? There are so many non-neutral tools that software devs have developed that ended up being replaced again by something new, that I am not sure if that is a truly important issue. An example perhaps is garbage collection. It can make a dev more careless about memory usage. That isn't the issue of garbage collection, it is the developer not taking responsibility for it. As so often, the weak link in my opinion, lies in the human factor. If a user/software dev decides to abdicate his or her responsibility to an LLM then, yes, the article is right imo. If a software engineer takes responsibility, then the LLM becomes a tool. Not neutral but a tool nonetheless. Whether or not that is a good or bad thing will strongly depend on your own viewpoints and perhaps other factors. The most important thing imo remains that a dev needs to be and take responsibility for the things he produces, no matter what the toolset is he or she uses.

That makes some sense, I think the point the article makes is that a tool predisposes people in general for a certain attitude, a certain viewpoint, which leads to a certain way of using the tool. LLMs make it easy to write slop, if you do that you're going with the grain of the behaviour the tool encourages. It's not impossible to use an LLM without producing slop, but it takes more effort and presence of mind, making it the exception, and not the rule.

To put it more bluntly, I'm sure most gun owners think they're "the good guy with a gun", but we still end up with an excessive amount of gun deaths.

I agree and I think that is especially true for those companies that think they can replace (experienced) developers with LLMs. The companies that have the right (technical) leadership will value LLM usage differently. Another example is that LLM's basically have democratised software development by lowering the barrier to the level of being able to write prompts. That democratization correctly produces the most slop is my guess. LLMs can make software development look easier, but that doesn't make good software development simpler at all.

> A tool is thus any kind of thing that lets you do something you wouldn't otherwise have been able to. There are a lot of things in software development that do not fit that definition of tool: all the affordances of modern IDEs, for example, just make it easier to do what we could already do. I'd say the vast majority of software "tools" just improve the DX without actually letting us do something [we] wouldn't otherwise have been able to.

The bulk of the article seems to say that we should use our tools consciously, as every tool we use affects how we work; LLMs are a particularly powerful and imperfect tool, so we should be particularly careful of how we use them. It seems to me that reactions vary by the meaning attributed to "just", when someone says "it's just a tool". Is the "just" a negation of an attribution of inherent evilness of an LLM, or a negation of any responsibility for our use of an LLM? Does the tool control us, or do we have control over the tool?

Hugod, wrt to the "just" a tool, I think it is not necessarily ab bad thing to say. In essence, an LLM is code sitting in a data center, or on our computer. It doesn't do anything unless we ask it to do something. In that sense it is like a fork. if you leve it on the table, it won't do anything. How we use that tool makes all the difference. I could perhaps use a fork irresponsibly or with evil purpose, but in essence I ought to use it to eat food. My responsibility, not the tool I think.

I admit I never agreed with the "just a tool" argument. Is a compiler "just a tool"? It completely changes the surface area that you work with, you no longer learn about or work with assembly (or even machine code). It has become the new material you operate on. If you use AI just to help you write code, minor auto-complete, help research/debug, bounce ideas, etc. I can see thinking it's just a tool. But AI can also become the new surface area of work. You can write an entire application just at the chat prompt, never looking at the actual code once. AI isn't the tool in that case, it's the material you work with, the tool is the harness, the model you're using, etc.

Separately, the article started with saying something important. Tools shape human history. Tools are not inconsequential, they are in fact, arguably, the most consequential things in impacting our evolutionary direction. I think that's very true. Humans are not much more than just the sum of their tools. AI is likely to reshape humanity, like the internet before it, the printing press, naval fleets, steam engine, agriculture, fire, etc. I don't think you can escape the destiny a tool brings. Once guns are created, there is no escaping their use for war and dominion. It's inevitable. Similarly, the lure of profits, ease and laziness that AI brings, its unavoidable, AI will reshape humanity to its image 😝

I hate the argument that "LLM democratized software dev". How? By putting a paywall on it? Sure, USD 20 might not seem much, but it's almost the minimum wage in my wife's country... and I am sure you can't make a full software with the basic Claude plan. In my own country, there are a lot of people that don't have USD 20 to spare. But contrasting how I'm interviewing companies right now, and how it feels a "pay to win" game - if you have multiple LLMs you can probably pass easier in the coding challenges that companies insist on doing; if you don't, then you're out because companies are asking full features to be implemented in 1 hour.

I think the "democratization" aspect comes from the fact that complete non-programmers—often managers—are now able to build things themselves without needing to involve IT.

They're not building "production" software. More often they're just little scripts or proof of concept stuff, utilities to make their life easier.

A friend gave this lightning talk on why we rejected a bunch of AI abstracts a few years ago: https://www.youtube.com/watch?v=XhKcelV7DBo and one thing that really stuck with me is what he called "The AI pipe dream": "Can I do the thing well without the skills to do the thing well". To me, the answer is obviously "no".

My boss's boss, for example: absolutely not a programmer at all, but was able to build a proof of concept web app that offered a chat-based interface based around our company's dating API. He didn't even know what language it had picked for the app (it was Python, he later discovered).

This is a very stretch of the word "democratization", in my opinion...

This is an insane stretch of the word "democratization", in my opinion...

Democratization doesn't really make sense. Software development was already democratized, free learning material, free courses, free source code examples, free libraries, free frameworks, anybody could learn and make the best software already. That it's easier, more accessible, doesn't require as much practice, that makes more sense.

Democratisation as I meant it in this context is that anyone can build something without knowing how it is built. Yes there are books, courses etc. But using natural language to get a piece of software to do something you want, that is about as easy as it can get to those that are not developers.

I do get that argument, but for me it's more a scathing indictment of the state of tech, and our utter failure to make general purpose computing accessible to the layperson. But it's also an area that has never received serious funding, because companies were more interested in creating walled garden apps and every conceivable way to get vendor lock-in. If we had had trillions of dollars invested into solving that problem we also could have democratised tech. But instead the solution is the most wasteful, brute-force, economically damaging, low fidelity one imaginable. For absolute shame.

I don't know tbh. As an n=1 observation, my wife is wel educated and as an artist loathes technology and its uses. She does not want to deal with computing, no matter how "easy" it becomes. I'm guessing she is not alone in this. Another way to look at it, every skill has its true masters. You get your mastery via hard work. We might be able to find a way to let anyone use that skill, but that doesn't turn everyone into a master of that skill. And that is fine I think. It isn't really about that type of democratisation. Perhaps it is more about the ability of technological development to help people express or build their ideas into working products. It isn't a solution for all, but it will help a lot of people without the necessary software engineering skills to create something that may useful to themselves.

Sorry but this is an age old pet peeve of mine. That someone doesn't want to engage with technology is one thing, but there are a lot of people who do want to engage, but don't have the decade it takes to learn all the weird ceremony and tribal knowledge. There is a ridiculoud amount of accidental complexity and accrued historical accidents that you need to know to do anything with computers that isn't "exact use case an app developer thought of". The only thing we have that comes close to broadly accessible open ended computing is spreadsheets. Computers were once billed as "bicycles of the mind", and we just never really delivered that. Especially in the age where everything is an app an all your data is stored on other people's computers, this starts with having accessible APIs (as a precondition, it doesn't actually solve any of the hard bits, but you can't do anything without this). All the companies that were loathe to open up APIs because it would lessen the lock-in are now adding MCP interfaces. We could have had the equivalent ten years ago, which would have allowed us to actually envision the UI/UX piece to go with it... Anyway, this is not a very useful rant, it's just me being angry to be living in the dumbest timeline, not much to do about it.

I think the essays main (simplified) philosophical point was that you cannot detach the ethical responsibility from the makers nor the users of "tools". Many do though, which is whole point of "it's just tool" argument but just saying it aloud does not make true, it is just evasion of the responsibility and consequences of your actions. (Note, those actions/consequences can be good or bad.) As an industry, we have to raise the bar. For LLM's it is trivial to show that they are not "just tools", you need to just look at the resource and energy consumption, for example. For other tools it may be more difficult but we should still try to figure out the consequences.

The word democratized might be a bit fuzzy in this context. But I normally take it to mean that it's available to all to learn and do, so there's an equal playing field. For example cheap high quality cameras and editing software democratized filmmaking and video production. But it didn't make it any easier. Soccer is a very democratized sport compared to say Formula 1 racing, because anyone can pick up a ball and practice anywhere. AI has lowered the talent required to produce something decent, so I can now write books, make music, video, art, without having any talent in any of them. But it's not like I didn't have access to these things before. Anyways, I'm arguing semantics haha.

I think it's a fair point, someone on mastodon pointed out that it's not so much democratised as commoditised... I guess they're making a similar point.

This "democratization" still feels like more of a buzzword than anything else. If you use a black box (an LLM) to produce another black box (a code artifact that people, for want of a better term, call software), then what is precisely democratic about that process?

My grandmother can do it. That makes it accessible for her. And she knows nothing about development

democratization in this case is not directly linked to democracy, it just means something is widely/easily accessible

> The broadening of access to something, especially for the sake of egalitarianism. • wiktionary

right, but that's just what I'm trying to point out: how accessible is it really if it's just something opaque that you don't understand at all? I'm aware that this is one of those slippery slopes that leads nowhere, just wanted to put it out there

Big tech has always been trumpeting the virtues of decentralization and open access while seemingly engaging in exactly the opposite

I think decentralisation and open access are different from anyone being able to use it to do something..natural language is something anyone can understand. What an LLM produces is something quite different of course. That will be a black box for most. But let's face it, hardly anyone understands how electronic payments work but hey, anyone can use his mobile phone to do something that ends up paying for something they want.

Yeah, as with any democratized system or process (in the many senses of that term), I don't care to moralize about whether or not someone should be able to do something, but why in many cases they should want to do something that was previously totally inaccessible to them and now, as if by magic, becomes trivial. I wonder if the degree of our specialization has become so intensely artificial that people just get fidgety and start grasping for other things to do

The vast majority of people out there have no idea what software developers do. They just think we're substantially overpaid for an "office job". Especially since "software" these days is in absolutely everything so they view it as a commodity of sorts.

Voice control of "everything" in your home, of your car. I know lots of non-technical folks who happily say "Hey Siri..." or "Hey Google..." and just ask their watch to look things up or do stuff for them. "Hey Google, remind me to put some steak out to thaw for dinner when I get home". And sure enough, they get home and their watch says "You asked me to remind you to put some steak out to thaw"

well I'm sure they have no idea about the nitty gritty details of software engineering, but I would hazard that their degree of unfamiliarity is no greater than, say, the average person's understanding of what a car mechanic does. They care about the saleable end result

I guess it's important to not use the word democratize in my view, because I agree with whoever previously said it's actually creating more gatekeeping than existed before. Making it easier/more-convenient is often the method to concentrated control and power. Take food delivery services, Uber, YouTube, social media, etc. it didn't democratize anything, it concentrated control and a few handful entities now hold the keys to access. It's similar in my view to how nothing can be repaired anymore. There's actually a loss of control and level playing field. We're lucky the Chinese models are open weights and show a lot of competition for now. Even them though, are pretty locked down, no open data, no open architecture, no open training pipeline. No one has access to any of this. And the cost of using AI is high, much higher than the cost of programming was prior AI.

I think we can start to use "oligarchize" instead of "democratized". As it was mentioned before, there's a wikitionary definition of "democratized", and there's this distinction at the end: especially for the sake of egalitarianism This isn't egalitarianism. People who have money can pay for a higher tier of Claude, Codex, etc and have a working software after a few prompts; lower tiers won't deliver the same because the token will probably be exhausted before things are stable-ish; there's no "egalitarianism" on that, there's only a "pay to win" approach - which, by the way, is how I'm feeling now that I'm looking for a job, interviews expect me to deliver full features in 30~45 minutes, and I gravitate between "do I write myself and show how much I know" vs "do I add more tokens to my Claude and let it vibe-code with Fable".

Are these take home tests? I'm surprised the interview process doesn't ask you to use their tools/models

No, these are live-coding tests. I always ask for the expectations before, and they usually say "it's to know how you think, what decisions you take, how you communicate your decisions" and then I fail because I didn't deliver 2 different UIs with React and 3 new APIs, together with one bugfix, in 40 minutes (yes, that is literally what happened in my last interview)

I fail to understand how they will know how I think, which decisions I take, and how I communicate these if I prompt for the answer...

But they say you can use AI? But they don't provide an environment?

I'm curious because I haven't interviewed since all this AI madness and I'm curious what's happening with interviews now

Yes, they said I could use AI, didn't provide an environment. It was all on my side only, my tools, my tokens, etc

I see, ya that is interesting, because if you don't pay for Fable and so on, weird