People underestimate how much of software engineering is subjective touchy feely decisions. But really it's just a nature of being in a field with so many possible options and so few hard constraints. You can write your web app/cli in Java, Go, Rust, JavaScript, Ruby, Python, etc, each of them with reasonable justifications. You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc. You can use Postgres, Mongo, SQLite, MySQL, etc. Is there any actual evidence that one stack is better than another? No, not really. It's ultimately up to what your brain decides it likes, and then it fills in the arguments post-facto.
It's just that software engineers like to pretend they're fully rational beings and don't go off of subjective reasons like the rest of society.
>It's just that software engineers like to pretend they're fully rational beings
So much this. There are some rational factors to consider, but in the end gut feeling and UX is a much bigger factor than what people like to admit.
IME the people that espouse "facts over feelings" often have a lot of badly expressed feelings disguised as rational opinion. I prefer discussing with people that are at least aware of their own feelings and can admit that.
> Is there any actual evidence that one stack is better than another? No, not really.
It is not controversial to say that any two stacks will have advantages and disadvantages over each other. There is absolutely evidence that Go compiles code faster than C++, or that C++ can call C code with less overhead, or that Rust eliminates certain classes of bugs, or that Postgres supports LISTEN/NOTIFY and SQLite doesn't, or that SQLite excels at storing a database in a single file.
Choosing a given stack means picking which particular advantages you want and/or need. I agree that there's no evidence that one stack is always "better", but this is like asking for evidence that a hacksaw is better than a table saw: they don't do the same thing! You can probably use either of them to cut through a skinny tree branch, though.
I think there are definitely objective reasons why you would pick certain stacks for specific projects. They all have strengths and weaknesses. You can technically achieve a lot of the same tasks regardless of your stack choice, but the timeframe, elegance, available ecosystem, cost, and ability to hire for your stack may vary quite a bit.
That said, if I’m not spending someone else’s money, I’ll pick the stack I enjoy or feel most productive in. I use Elixir for my own projects, but it’s generally a bad option for the startups I work for. Tough to hire for, limited ecosystem, unusual and sometimes polarizing concepts. It’s a business risk compared to, say, TypeScript or Go. Great concurrency model and cool pipeline capabilities though. :)
there are objective strengths and weaknesses. However for any set there is another option that has very similar pros and cons with just one - often minor point different.
I feel like Elixir has such a small amount of jobs that it would be a lightning rod for those who have skills in it. I appreciate Elixir, I like it. But it's weird to see an expectation of experience in it when the marketplace is so small.
You could always target scala/akka engineers with it. Theres a lot of crossover there.
there are definite differences but in most cases we do not have the ability to make an actual rational choice (verging between a lack of hard numbers and an inability to predict the future).
Software development is not engineering, but it's also not completely arbitrary. It's a craft, and like all other craftspeople, you build intuition through experience, which guides decision-making.
It's a little controversial to say that it isn't engineering, but compare what we do to things like building bridges or constructing dams. The level of rigor in those fields is galaxies apart from almost all of software development. You _could_ apply it, and some organizations do, especially when lives are on the line, but the cost/benefit ratio is impossible to justify in almost all software development.
This isn't to say that "real" engineers don't also build intuition, but they have enormously higher accountability requirements. In some areas I would argue that software development _should_ have much higher accountability, but this also means a significantly higher cost. I think governments around the world are coming to realize that the money would be well spent.
I think software engineers would benefit from talking a bit more with actual engineer peers at real companies and hear them vent and rant, to see that "real engineering" isn't the idealized utopia we imagine it to be either.
I've worked in backend infrastructure teams for ~6 years in a couple PHP shops, and you know what, dynamic languages absolutely suck when you want to do any kind of refactoring :). That made me really appreciate compiled languages like Go, since they don't feel too heavy and have a feeling close to a dynamic language, but do allow for painless refactoring.
Modern PHP shops don't really do dynamic PHP anymore. Ever since it got types and runtime type validation. Refactoring is also proven to be very easy as a result, and especially with something like Rector (https://github.com/rectorphp/rector).
Yes, you also know this in modern PHP. https://www.php.net/manual/en/language.types.declarations.ph.... You add type declarations just like any other statically typed language, and you can get your static analysis by your editor out of the box. But in addition to that, you ALSO get runtime type validation, something that most languages won't give you, and something that to me at least is amazing since code correctness is one thing, but data correctness is even more important in my opinion, and runtime type validation gives you data correctness, built in, no need to mess around with external libraries.
I wouldn't want to refactor anything other than Ruby. If you have the intuitive understanding about how its object model and scoping semantics works, refactoring is really fun.
The issue with dynamic languages mostly is that it's sometimes next to impossible to find all references to the code you're refactoring, so you can't just rely on a compiler & tests to ensure that nothing breaks after a change in some core library that everyone uses. Instead you almost have to add some logging into a function you're refactoring, make sure it's not used after you've made the change to a new API, and ideally do that a couple times. It's not too bad when you're the sole developer in a repository, but in the presence of hundreds of feature branches that sometimes can be weeks old, you can't be sure that nothing breaks after your change in the future too. So unless your code can be statically analysed reliably (like in compiled languages) large scale refactoring is a huge pain
> You can deploy to AWS, Vercel, GCP, Azure, Cloudflare, etc.
It's interesting that this is now and has been the default for quite sometime. I'm still waiting for the pinch to hit where people realize running on these platforms is either really expensive (EC2/RDS), or platform specific ("serverless", Cloudflare workers, lambda, etc).
TBF it's only expensive if you know how much the alternative costs, and have a reasonable path to switch to it. So for most small shops, it's just a cost of doing business, and they're small enough it doesn't cost astronomical sums yet.
Running an on-premise cluster requires enough expertise that it will mostly be for mature companies, and they'll have completely different priorities when choosing technologies.
Ultimately code is written for humans first, otherwise we’d all be using assembler. So how readable the code is written matters, and how frictionless it can be managed. A lot of opinions form around that. As Usually “it depends”.
Note I’m not disagreeing with the core of the comment but presenting this as pretence when this is simply the craft until we manage a layer that manages code for us and have opinions on that instead, seems harsh. My 2c anyway.
There are happy paths to follow for many projects. For instance if I was starting a macOS or iOS project I'd need a really good reason not to use Swift.
I agree with "choose tools that make you happy", I disagree with the implied premise that all "obscure" (not very popular would be a better description) tools have value purely because they make me happy.
I have used (and continue using) many tools and solutions that are not popular. Some of them make me happy, some do not. All of them bring practical advantages.
Not every good tool will become popular, and many popular tools are not good.
Yeah I agree with the positive part of the thesis; i.e., that it's alright to like things, and it's alright to pick things in part because you are a feeling sentient person and you should have nice things.
I think the corollary that people, when looking also at the data or at constraints, are acting irrationally or its sophistry or whatever is bunk, though. Plenty of people do actually engage in some amount of evaluation, and it's intellectually lazy to disregard that because they may have also made an aesthetic or otherwise personal decision on some level as well.
I use a bunch of niche software, and it's difficult or impossible to completely separate my aesthetic preferences from the concrete reasons I also have for doing so -- my aesthetic preferences and my joy in using certain things actually stem from those concrete benefits in some cases!
I believe you that there are practical advantages; often the more popular ones have several problems that are insufficient for what I am trying to do, but sometimes just that there are advantages and disadvantages of different ones and the ones that I like are different. This is true of file formats, character sets, protocols, etc as well as of programs.
> Not every good tool will become popular, and many popular tools are not good.
Yes. (In my opinion, there are also specific kind of features that it has or lacks, that I might think is good even if it is uncommon or bad even if it is common, but there are also features that are good as well as common, or that are bad as well as uncommon.) (However, there is also the consideration of: something might be good for some purpose but bad for others, and might be used for many of the purposes that it is bad for even though there is clearly something better.)
As with most things, there is a happy medium here. Ditching poetry for the new and shiny uv made my day-to-day experience an order of magnitude better, especially because I had to introduce Python to an existing monorepo. Being able to inline dependencies as Python comments made it possible for a completely non-technical person at my company to run an AI-generated script that used Pandas with just one CLI command. Had we picked poetry, I would have to spend half a day setting up a proper Python environment on his machine.
You can also go too far and pick a JS web framework with 17 users that hasn't been battle-tested in production. You'll then waste time solving problems that have already been solved by users of React/Vue/Svelte instead of shipping working code.
I keep using Emacs because without it I do feel like a William Gibson protagonist -- "trying to reach the console that wasn't there" (or M-x or Lisp repl in my case).
Emacs works the way I work, the way I need an editor to work. I recognize that it's a very personal thing and doesn't readily generalize, but it's a bit condescending to imply that all these personal choices are to forge some pretentious cosplay identity. Some of them are just a simple matter of: human need get work done, human brain work best this way, use tools that best support way brain works to get work done.
Thinking again about the essay in OP, for whomever is still reading this, I'm reminded of Patrick Farley's The Guy I Almost Was, in which the protagonist buys a Hermes 3000 manual typewriter instead of a computer to rebel against the self-serving consumerist futurism he used to embrace (and also, incidentally, because he cannot afford a computer). In short, the typewriter was a component of a form of cosplay, the garb of the sort of beat-generation intellectual with the sort of authenticity he aspired to have. (I'm convinced that fellow Hermes user William Gibson has spent a career cosplaying as a beat poet, which is why his fiction has an urticating effect on me.)
As it happens, I also own a Hermes 3000 typewriter. I bought it for a different reason: because it's really, really cool. Like all of the modern, sophisticated computers I own, it's a fascinating piece of information technology, precision engineered to do what it does very well. There's a minimalism about it I admire: it's a machine for augmenting the writing process that doesn't even need electricity.
So again, some people use certain tools because those tools are simply a joy to use. And that's fine too.
My first boss at the uni would tease me about my Emacs usage, saying, “It’s an operating system with a text editor tacked on.” I just smiled and loaded up a game of snakes within my Emacs buffer and carried on hacking.
He's not wrong though - Emacs was meant to replace the MIT lisp-machine/symbolics interface and it does a magnificent work of it.
The things that Emacs allows one to accomplish is quite insane, though, as with all lisp-projects, it also seems to suffer from the "Lisp curse" (which is fine IMO).
The standard "great OS, needs decent editor" quip is just that -- a quip. If you look at the actual history of Emacs, you will see that the it was originally a collection of TECO macros. The first Lisp version was written by Dick Greenblatt for Multics -- it was not intended to be an operating system in its own right. The Lisp machines had Emacs versions of their own -- called EINE, ZWEI, and Zmacs. So Emacs was well-established on multiple operating systems before GNU Emacs even came along. You could say that the GNU system as a whole is intended to be a successor to ITS and the Lisp machine OS, but Stallman deliberately chose Unix as a basis because he wanted GNU to be popular and Unix was already widespread in 1983-1984.
In fact, GNU Emacs didn't even get some of its more powerful UI features until the 90s, after Lucid Emacs/XEmacs was developed by Lucid Inc. as a component of their Energize IDE -- they found GNU Emacs at the time to be inadequate from a UI standpoint, so they forked it and added the bits they needed. Most of those were implemented back into GNU Emacs, despite that Stallman thought that, for the most part, they weren't needed.
So no, Emacs wasn't designed to be a software Lisp-machine workstation. It just sort of slowly morphed into one over time.
The author is very cleverly using unexamined motivations leading to incorrect conclusions to demonstrate that we shouldn’t allow our unexamined motivations to lead to incorrect conclusions.
But the whole "but actually you only like what you like for superficial reasons" thing lost me. I really dislike essays that create false dichotomies just so that they can purport to know why what you do is bad or wrong.
Can't someone choose a tool for _both_ rational and aesthetic reasons? In fact, isn't that basically the definition of "best?" And by "best" I (hopefully obviously) mean "best for me/you," not "objectively best."
I'm sure the author would take a dig at me: I have a love of Thinkpads of command lines. Regarding the CLI, I won't deny that I love the aesthetic. That's genuinely why I was originally drawn to them. Vain? Silly? Maybe. But I own it, won't deny it, and will never stop loving the aesthetic of a cool ass looking terminal.
However.
Seeing as the author chose to focus on editors, I'll do the same: I have never found an editor that is all together _better_ than neovim. Sure, this is probably still subjective, whatever, but putting aesthetics and feelings and whatever else aside, neovim still always wins for me and it's not even close. The speed, the stability, the power of a well-configured LSP, the navigation afforded by things like fzf and treesitter, the unbelievably rich and forward-thinking plugin community, and so on and so forth, make it come out on top time and time again for me. Many, if not most, of these reasons are rational.
I could say similar things about most of the other apps (cli-based and otherwise, though most are cli-based) that I use, as well.
The author also seems to misunderstand that the so-called "cult" of Emacs might exist for more than just superficial reasons. Perhaps a "cult" formed around it because it's actually really good, or at least addressed a lot of people's problems at a particular time, and groups of people tend to form their own aesthetic? I myself have never jived with Emacs, but I can certainly recognize the power of it -- and, yes, the aesthetic, community, etc -- and I certainly wouldn't dream of shitting on someone's joy of it, especially in a condescending "you actually only like this because you think it looks cool" or "it confirms some aspect of yourself" way.
It's simple: we can, and probably even should, choose tools for both rational and "superficial" reasons. It's perfectly fine, and one aspect does not negate the other.
I agree. I primarily use Emacs, because I think it’s just about the greatest program mankind’s ever developed. Anything you could ever possibly want it to do is already packaged for it. It supports all the features of newer editors (yes, I said all of them). It supports every language known to humanity, and it does it consistently so that if you use it to write Python, you know how to use it to write Rust or Prolog or C.
I don’t use Emacs to be contrary, just like you don’t use Neovim for that reason. We use them because they’re really good.
Some people can use Emacs for amazing productivity gains, and some just can't, no matter how much they try. The first ones are blessed, the seconds ones are inferior and better to stay away from.
It is Gnostic cult, even if it happens to be true.
> The general form being: why Obscure Thing is better than Popular Thing. And always the justification is purportedly rational and technical. And always, always, it is complete sophistry.
Is the author scoping the piece, to say that this piece is speaking only of the subset of posts claiming obscure-thing-better-than-popular-thing that are sophistry?
Or is the author asserting that all posts claiming obscure-thing-better-than-popular-thing are sophistry?
My interpretation is that as engineers, we attempt to justify all of our choices through purely rational means. However, as humans, we cannot really make said choices without also being at least somewhat influenced by our subjective affections.
Perhaps I'm stretching the author's message, but at least I believe that the argument extends to all engineering conclusions. The author's call is that we acknowledge this subjective side.
Essentially, true engineering is about tradeoffs, there is no X that is objectively better than Y in all circumstances and contexts.
> The author's call is that we acknowledge this subjective side.
I think that acknowledging the subjective side is a necessary step to making more rational choices. If you don't know your motivations, you will be a motivated reasoner.
When you can add "I like this tech because it helps me build an identity I aspire to" as an item in the pros column, you realize you no longer have to.
> When you can add "I like this tech because it helps me build an identity I aspire to" as an item in the pros column, you realize you no longer have to.
But, for many of the cases of using-obscure-thing-instead-of-popular-thing, that's not a factor.
Not everything divergent is hipster impulse. Nor is everything about slotting yourself into a clique category in high school.
Which is why I asked for clarification on what was being said.
FWIW, I use a vintage ThinkPad mainly because I can type all day on it without problem. The serviceability is also nice. I also own a sleek high-end last-year's P1 and an X1, both of which I think would look more attractive in cafes and in some ways fit my ideal self-image better than the T520 that I choose to use instead. Currently, due to the inferior keyboards, I might use the P1 or X1 only if I need to do a startup meeting with a 20-something who doesn't already know I'm good despite being over-30. That choice would be the image one, and it's not about validation or aspirational identity, but pragmatic gaining of acceptance despite prejudice.
Nine times out of ten, popular thing is going to be objectively better than obscure thing, because it's much easier to find people who know, and tools that work with, popular thing. All other things being equal, the person who launches a startup based on Go or JavaScript is going to have an easier time than the person who launches one based on Common Lisp or Haskell -- unless they do all the coding themself.
If you have some objective, measurable reason for choosing obscure thing over popular thing, by all means -- tell us why. But show receipts. Actual numbers and measurements.
I'm describing the set of posts that jointly satisfy:
- The thesis is "tool X is superior to (Y, Z, ...)" or "X is a modern/practical choice".
- The argument is purported to be technical and rational.
- The arguments are fallacious and do not stand to rational scrutiny.
Where you can reasonably think that the author's actual reasons are affective, and they are trying to make rational arguments by backward-chaining from the conclusion and failing.
If an article is (jointly) written in green font, uses the word "the", and is fallacious and does not stand to rational scrutiny; that article is fallacious and does not stand to rational scrutiny.
This is a disappointing article from an author who usually writes excellent works. The article touches on a seedling of truth, but then takes it in a misleading direction. Unfortunately, I don't think this article actually inspires anybody to inquire more carefully or rationally within, but instead provides great thought-terminating ammunition that can be fired at anybody doing something not perceived as popular, ordinary, or boring. (And it's entirely in vogue to do so, with all the Grug Programmer, Use Boring Technology, etc. haranguing these days.)
What I think is true: A person will often hide their true rationale and/or intent of a decision behind a facade of weak, ex post facto objective arguments.
I think the author is absolutely right that it's OK to use something just because it makes you happy. Especially for personal/hobby projects, you don't need to be disingenuous and attempt convince the world that SWI-Prolog was truly the optimal technical choice to build your CRUD web app. Saying "I like Prolog and I built a CRUD web app using it" is perfectly fine. I'm really on board with this intellectual honesty.
Where the author goes off the rails is how he ties this criticism specifically to people who make "obscure" decisions. He does so especially through alienating caricature. The subtext of the article is that if you're not doing something conventional, then avoid being a sophist from the get-go and just say how you really feel: it makes you happy. He doesn't lend any credence whatsoever to the idea that an obscure choice may actually be technically justified.
The reality is that people who choose popular technologies often do so without any good reason either, and they too provide a facade of objective justification. They may not be writing blog posts that offend the author ("Why I Chose Python to Build XYZ") that reach the top of Hacker News, but they are espousing their own weak, ex post facto justifications in settings when their decision is challenged—which is almost inevitable, as their choice of popular technology isn't the only popular technology. They'll manufacture the same load of baloney for their decision in the same way the author's Common Lisper boogeyman does.
I would even make a stronger claim: People decide to use popular technologies because it makes them happy, and this happens far more often in load-bearing situations than the Obscure Weekend Technologists do. Furthermore, popularity serves as a sort of immunity to further technical inquiry.
This has led to far more technical derangement and damage writ large to the field than the weekend APLer writing about why they chose APL for a project, and I think it demands scrutiny the author doesn't offer in the slightest, despite being entirely relevant to his broader criticism.
More subjectively, after reading the article, I just felt the author is sour about something or has some sort of ax to grind. He's no stranger to obscure technologies (ex-Common Lisper; now disavows it) and has even created his own obscure programming language with an obscure Wirthian syntax written in an obscure OCaml. Maybe this article represents an admission of sorts.
> I would even make a stronger claim: People decide to use popular technologies because it makes them happy, and this happens far more often in load-bearing situations than the Obscure Weekend Technologists do. Furthermore, popularity serves as a sort of immunity to further technical inquiry
Spot on. Could not have articulated it better if I tried.
From description AND observed results, this is a case where a team was successful in a challenging situation with lisp and then failed to deliver, first with c++, then java - the indistry-standard languages of the day.
I just like to use simple tools I understand where I can extend anytimes I like instead of tools that's complex and always morphing whether I like it to or not. Most tools brings in a new thing I may like, while reinventing 95% of things I already use. A truly lateral tool that just bring in something new and useful is rare (LSP in text editors). And most of these are protocol based instead of feature based.
Should we feel happy solving our problems with our fancy tools? Are our tools and in-depth knowledge a distraction to inflate our egos, or a sign of self-respect and passion?
I’m inclined to believe the latter. Our fancy tools provide so much more utility beyond keeping us happy. Our tools teach us new things and stretch our curiosity and creativity. Our happiness stretches us to solve more problems and ask better questions.
There's a major reason people seek to rationalize the tools they use and it's because we all have jobs, and we want to be allowed to use what we want at work. When some other tool comes out and is one that you find highly annoying, that tool is literally a threat to your own personal comfort, lest it become popular enough that your job is making you use it. Which is something that happens to all of us that have software oriented passions and dispassions all the time.
I've been feeling the pull to try Obsidian instead of org-mode with Emacs (which is what I've been using), and this article, somewhat ironically, makes me want to stick with the less popular Emacs rather than spending effort to learn a new ancillary technology.
I have and would, why bother with a tool that will get removed in N years when the maintainer is bored or nobody likes the flavor of the month language anymore.
I mostly agree and I think this is the reason why languages like Python or Ruby succeeded so much. People simply want to use a beautiful, easy to type, easy to read language. They don't care that it's slow and actually quite terrible at runtime and hard to test and so on. They want it anyway because it looks good and feels good. This is also why I've said from the start that I don't believe in ziglang despite all its features. It simply looks too ugly and you can't make that go away. One counter point could possibly be that golang code is also a bit ugly and it succeeded on its technical merits. But it's not quite as bad and the ugliness is voided by a lot of language simplicity.
Plenty of engineers prefer the appearance of code with heavy use of curly brackets. I thunk aesthetic tastes in the programming community are rather split and doubt there is a clear preference for Python style appearance over Zig style appearance.
The failure of Zig to catch on is simply because it’s in a harder space to catch on (low level / systems programming). Whereas new web languages frequently catch on, Rust and Go are the only ones that managed to break through against the C/C++ monopoly with Zig, Nim, D etc. failing. And Pascal and its derivatives also have fallen by the wayside so it’s not an appearance issue.
For any codebase destined for a team to develop, primary consideration goes to the technologies the team prefers, not my own preferences. Which makes for a fun guessing game when you’re green-fielding and before you’ve built the team.
The vast majority of the teams I worked in, I got forced to use shithole technologies, with shithole tools, and as a matter of fact, forced to work on legacy codebase. The part with legacy codebases is a fact of life when working in teams at companies though.
This is just my personal preference - but I tend to be affected by development workflows and developer experience profoundly and my output is directly proportional to that. I hate projects where testing workflows haven't been setup correctly or not set up at all. The last job I had was one where my team fucked itself up, along with our entire engineering org by setting up layers and layers of microservices and introducing unnecessary complexity hence making trivial changes hard to ship into production. What would take 30 minutes to debug ended taking days because abstractions between teams were not properly set up. Visibility into pipelines was severely lacking and it was all nothing but a circus shitshow.
I tend to have the greatest happiness working on personal projects where I get to choose everything, so I relate myself to the post very much
> that they are unfeeling Cartesian rationalist automata
And what, they aren't allowed to be happy with that identity? They need to feel the author's brand of happy only? Ick.
Not allowed to appreciate garbage collection in Lisp because Python has it? And the author feels the need to class such appreciation as a side effect of a neurological disorder?
- - -
> If you pursue things out of pure obsession, you might wake up and realize you’ve spent years labouring in obscurity on a dead-end
but
> You are allowed to use weird, obscure, inconvenient, obsolescent, undead things if it makes you happy.
[apparently not, considering the insistence of insulting anyone's reason for enjoying doing so]
I've chosen C# for projects because of fear of having to defend other options which I felt might've been better. I've chosen Angular because it seemed like it embodied the virtue of Enterprise and Enterprise was what the customer wanted (I now really hate my past self for that). So it goes both for standard and non-standard tech.
(OTOH, at some point in the past Python was the obscure thing. If everyone only sticks to the safe path we'll never see progress.)
But yes, the main reason I use Emacs is that it makes me happy :-)
> Emacs is a Gnostic cult. And you know what? That’s fine. In fact, it’s great. It makes you happy, what else is needed? You are allowed to use weird, obscure, inconvenient, obsolescent, undead things if it makes you happy. We are all going to die.
There’s a handful of things like Emacs and APL/J/K that HN introduced to me a decade ago that actively reduce my productivity — and I don’t need your explanations for how I’m using them wrong. They’re, to me, like a good book I’ve already read but keep rereading in-place of books I haven’t read. The reduced productivity is fine because we’re some unknown time away from nuclear war or falling down the stairs.
In fairness to Emacs, this is a bit sour grapes on my part!
I have tried to go fully into the "Emacs mindset" (org-mode for everything, multiple pages of custom hydra keybinds etc.) a number of times and I always bounce off. I always feel there is some activation threshold that if I could cross it, I could enter editor nirvana.
I used to joke that the way I use Emacs is I open it, give the empty buffer a very meaningful look, C-x C-c, and open VS Code.
For whatever it's worth, I think in 2025 with good LLMs, Emacs is actually bliss. Even as a true believer, I would regularly think of customisations, and then sigh at the effort and not bother. Now, I just get an AI to help me write the Emacs Lisp which not only teaches me new things, but also gives me (in seconds) an upgrade to my productivity which will last forever. Not only that, but I am using LLMs in my editor to help write code to make using LLMs in my editor even easier, so I feel like I've simultaneously crossed two thresholds.
My story is a lot like yours, except swap the two editors. I decide I'm really gonna try Visual Studio Code this time. Everybody uses it, it's become the default editor for like every recent programming language... it must be better than what I'm using, right? Fifty million Elvis fans can't be wrong!
And then I fire it up and... it's not compatible with my muscle memory. Plus I can't just pop open a buffer and morph my editor into what I need for the task in a language I like. (There is considerable rigamarole involved in writing a Visual Studio Code extension; I tried.) I can't work with buffers the way I'm used to, it doesn't indent the way I'm used to... and unless I'm willing to limit myself with VSCodium, it's spying on me in a way I consider hostile. So I put it away and get what I need done in Emacs. I must've been through this cycle like, six times.
The author thinks it’s perfectly valid choose a tool because it makes you happy, but doesn’t want to hear you trying to rationalize your choice based on technical merits using an objectively unsound argument.
> They choose obscure tech as a form of sympathetic magic, like the guy who uses NetBSD on a ThinkPad to feel like a William Gibson protagonist.
Ono-Sendai Cyberspace 7 for the win.
Though I'd say using Rust would feel more like Gibson's character, since it's more futuristic contrasted to those who go out of the way to look for bogus arguments not to use it.
He doesn't explore the inverse: choosing common tooling for similar reasons. Choosing Python because it feels like pseudocode, Ruby so you can feel like you are DHH every morning or Docker so you are a real devops person.
And then the other quadrants of the mainstream thing/obscure thing vs. pluses/minuses map: Emacs and VIM are really fast and you can use the same editor and familiar tooling to open a 10Gb file as your source code. And VSCode often crashes or needs restarts to get things working again.
OTOH, great writing! I learned a few words. Can't believe I didn't know Gnostic.
In defence of emacs: if I were using emacs, I'd be doing that not because of Neal Stephenson's essay, but rather because of the long-established legacy of the development, and because of the community. I believe that the combination of these two factors is very likely protecting emacs from a sudden enshittification so typical for proprietary software. I'm in the vim church, but for exactly the same reasons.
This article is insulting. It is trying to paint the picture that all of us who go against the mainstream are deluding ourselves if we think it is anything more than the digital equivalent of wearing a leather jacket.
Very often mainstream stuff really is actually worse than obscure stuff. I don't have to explain this to the HN crowd, I'm sure.
The article is pretentious (which is ironic since it is arguing for adopting mainstream technology).
The title of the post here ("Choose tools that make you happy") is wrong.
I wrote "You can choose tools that make you happy" to mean "you have permission to use tech just because it makes you happy or triggers your curiosity", so that people don't waste their time coming up with false technical reasons why their technology choices are rational. It is not a command that you should choose tools entirely or mainly for affective reasons.
I think for any given job there's a tool thats likely best. If you hire me to paint your car and I show up with a paint brush you're probably not amused, because you know that it needs to be spray painted. If I hire you to program a microcontroller and you try to use Ruby..
I don't normally comment on my score since thats a downvote brigade waiting to happen, but the amount people are offended by the idea that choosing tools has more to do with the project than personal taste is amusing!
Letting software engineers use their favourite tools, even if those tools are suboptimal, is a way to make your engineers happier without paying them anymore.
I had one boss who rode me daily for using Emacs. He insisted I’d work faster if only I’d switch from it to “an IDE”. It wasn’t long before I told him to knock it off and never bring it up again. My dude, what do you think this thing is?
It's just that software engineers like to pretend they're fully rational beings and don't go off of subjective reasons like the rest of society.
reply