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.
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.
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
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.
Spot on. Could not have articulated it better if I tried.
I'll add a data point though: https://flownet.com/gat/jpl-lisp.html
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.
Assuming the pose and lighting a big joint, inhaling deep:
"Yah, well... Snobol isn't, but have you ever heard of micralyzed Speedball...err...SpitBol!?!?"
Madly giggling putting https://en.wikipedia.org/wiki/SPITBOL in here, and vanishing into the OFF :p
In terms of endurance, productivity, peoples, money.
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 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.
It is Gnostic cult, even if it happens to be true.
I know, I know, I should let it go [1].
(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 :-)
Tideflat•1d ago
it may cost you more in slower development times.
kstrauser•1d ago