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?
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.
> 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?
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.
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.
> 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.
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.
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.
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.
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'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 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.)
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.
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.
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.
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.
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).
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.
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
>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.
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.
> 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.
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.
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.
> 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 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.
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!
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.
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.
> 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.
> 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]
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
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.
88 comments
[ 2.9 ms ] story [ 141 ms ] threadit may cost you more in slower development times.
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.
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?
- 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.
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.
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.
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.
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.
Otherwise, it's all vibes.
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.
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.
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.
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.
Just a little bit of microservices/kubernetes…what could possibly go wrong
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.
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!
> 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.)
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.
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.
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.
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.
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. :)
so in fine it's touchy-feely.
You could always target scala/akka engineers with it. Theres a lot of crossover there.
This is what "dynamic typing" means.
In other languages, you know that the types are right /before/ you run the code.
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.
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.
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).
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.
You don't need a cluster for most things. A simple server managed with Ansible playbooks will take you quite far.
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.
Discuss your ideas with a civil engineer
You'd be surprised how similar our professions are
Our shoddy work is our fault, we know how to do better, we don't
We are like civil engineering in 1850
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.
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.
:)
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.
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.
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.
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]
but
> We are all going to die.
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.
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