3,876 karma · joined December 20, 2011
What I meant with "menial coding" is those jobs where people have to submit TPS reports on how much hours they spend for each customer. Reading a paper such as this one [1] is typically not directly necessary for being a good frontend developer, but it might stimulate someone to develop into a more fruitful employee in the long run. Managers would have to explain to their customer why time is being spent on that, and that requires some vision and creativity, which is not always a given.
It would help if you briefly specified the AI you are using here. There are wildly different results between using, say, an 8B open-weights LLM and Claude Opus 4.6.
Not so fast. People have built pretty amazing thought frameworks out of a few axioms, a few bits, or a few operations in a Turing machine. Dolphin songs are probably more than enough to encode the game of life. It's just how you look at it that makes it intelligence.
A major advantage of (certain) extension mechanisms is that you can update them in real-time. For example, in Emacs you can change functions without losing the current state of the application. In Processing or live coding environments, you can even update functions that affect real-time animation or audio.
Another advantage is that they can pose a very nice API, that allows for other people to learn an abstraction of the core application. If you are the sole developer, and if you can spend the time to keep an active memory of the core application, this does not help much. But it can certainly help others to build upon your foundation. Gimp and Emacs are great examples of this.
A disadvantage is that you have to keep supporting the extension mechanism, or otherwise extensions will break. That makes an ecosystem somewhat more slow to adapt. Emacs is the prime example here. We're still stuck with single-threaded text mode :)
As stated in my first comment, Obsidian does not support Emacs keybindings properly, nor is it open source. Writing an extension to add Emacs keybindings is not at all trivial, because you have to work around a lot of existing and undocumented functionality.
There are other reasons for not vibe coding your own alternative, but as LLMs keep progressing, these reasons may become less relevant.
I think I've spent ~20 hours and a couple of $100 of Claude Opus tokens in Cursor. So it's not cheaper or easier, but the amount of frustration saved with having proper Emacs keybindings might delay catastrophic global warming by a few days.
Oh, and of course I'm not compatible with all the Obsidian extensions, nor do I have proper hosting for server-side sync yet. All in all, a fool's errand, but I'm having fun.
What I find interesting is that I have little motivation to open source it. Making it usable for others requires a substantial amount of time, which would otherwise be just a fraction of the development time.
I assume you mean outperforms in speed on the same model, not in usability compared to other more capable models.
(For those who are getting their hopes up on using local LLMs to be any replacement for Sonnet or Opus.)
ANC reduces background noise, which typically allows users to listen at lower volumes, thereby reducing total sound exposure to the ear. So if the user adapts their volume, that would lead to less risk of tinnitus. This works for me :)
But there are lots of people on forums suggesting that there is a link between tinnitus and ANC. One reason could be that ANC headphones allow you to listen very accurately to inner auditory signals, and if you already had some tinnitus, you might start to notice it.
If you feed this into a decent chatbot, or in an Ask HN, you might be surprised.
That would seem logical, as the results are then completely deterministic, but it turns out that a suboptimal token may result in a better answer in the long run. Also, allowing for a little bit of noise gives the model room to talk itself out of a suboptimal path.
Interestingly, most jobs don't incentivize working harder or smarter, because it just leads to more work, and then burn-out.
[1] https://en.wikipedia.org/wiki/Automation#Paradox_of_automati...
I didn't exactly understood what was meant here, so I went out and read a little. There is an interesting paper called "Neural Networks are Decision Trees" [1]. Thing is, this does not imply a nice mapping of neural networks onto decision trees. The trees that correspond to the neural networks are huge. And I get the idea that the paper is stretching the concept of decision trees a bit.
Also, I still don't know exactly what you mean, so would you care to elaborate a bit? :)
Many people used to say that LLMs were no more than a stochastic parrot, implying that they would be incapable of forming novel ideas. It is quite obvious that that is no longer the case.
The thing they currently lack is the social skills, ambition, and accountability to share a piece of software and get adoption for it.
The actual paper doesn't, and merely implies correlation. Which is fascinating (and well-known) and might still prove useful in one way or another.
[1] https://jamanetwork.com/journals/jama-health-forum/fullartic...
Also, this remark is giving away a fairly limited view on art appreciation:
> While you can learn from failures, only sales strengthen the muscle because only they show that someone actually cares about what you are making
This is obviously not the case for art projects that target only a few people, or art practices that do not result in tangible objects. (Although there are some exceptions, such as Marina Abramovich, but those are very limited.)
Great for them, but this is not about all art. It just is impossible to live of most art forms. This type of art fits well with our economy, and therefore makes a living. That fit is more important than all the business advice put on top.
The article does point out exactly this problem, but glosses over the fact that most artists don't want to change to popular art. Only a few can, and most don't want to.