> For 99% of tasks I'm totally certain there's people out there that are orders of magnitude better at them than me.
And LLMs slurped some of those together with the output of thousands of people who’d do the task worse, and you have no way of forcing it to be the good one every time.
> If the AI can regurgitate their thinking, my output is better.
But it can’t. Not definitively and consistently, so that hypothetical is about as meaningful as “if I had a magic wand to end world hunger, I’d use it”.
> Humans may not need to think to just... do stuff.
If you don’t think to do regular things, you won’t be able to think to do advanced things. It’s akin to any muscle; you don’t use it, it atrophies.
> And LLMs slurped some of those together with the output of thousands of people who’d do the task worse, and you have no way of forcing it to be the good one every time.
That's solvable though, whether through changing training data or RL.
> And LLMs slurped some of those together with the output of thousands of people who’d do the task worse
Theoretically fixable, then.
> But it can’t. Not definitively and consistently
Again, it can't, yet, but with better training data I don't see a fundamental impossibility here. The comparison with any magic wand is, in my opinion, disingenuous.
> If you don’t think to do regular things, you won’t be able to think to do advanced things
Humans already don't think for a myriad of critical jobs. Once expertise is achieved on a particular task, it becomes mostly mechanical.
-
Again, I agree with the original comment I was answering to in essence. I do think AI will make us dumber overall, and I sort of wish it was never invented.
But it was. And, being realistic, I will try to extract as much positive value from it as possible instead of discounting it wholly.
Your comment is nonsensical. Have you ever used any LLM?
Ask the LLM to... I don't know, to explain to you the chemistry of aluminium oxides.
Do you really think the average human will even get remotely close to the knowledge an LLM will return to such a simple question?
Ask an LLM to amend a commit. Ask it to initialize a rails project. Have it look at a piece of C code and figure out if there are any off-by-one errors.
Then try the same to a few random people on the street.
If you think the knowledge stored in the LLM weights for any of these questions is that of the average person I don't even know what to say. You must live in some secluded community of savant polymaths.
A general question for the room: where's the tipping point where you need a "proper" backend, in a different language, with all the inconveniences of possible type safety issues and impedance mismatches?
Because I feel like for 90% of small-medium projects it's just good enough with all the backend stuff within the same Next.js process as the front-end. I just do "separation of concerns"-ish with the code organization and funnel all communication with something structured and type safe like tRPC.
Feels separate enough but very pleasant to work anyway.
For most CRUD apps, Next.js + tRPC is the right call.
My tipping point was long-running tasks (OCR, AI processing that takes 30+ seconds) and wanting to scale backend compute separately from frontend serving.
If you don't have those needs, stick with what you have.
Thanks for the answer! I've hit those tipping points myself in exactly the same scenarios (OCR and AI). For me, ends up being hacky or just decoupled (independent job runners). Makes sense to have a proper monolith backend for these.
What's your take on opinionated distros like Doom Emacs or Spacemacs?
I've been doing my daily journaling and task management on Emacs for while now, using Doom Emacs. Rationale was that it'd be mostly pre-configured to a sane standard and that, for actual text editing, I'm a long time vim enjoyer, so evil mode is great there.
However I always feel that when I go beyond the safe borders of the preconfigured, leader-key-accessible realm, I'm quite lost. I don't have good intuitions on how to interact with more raw parts of the system.
And I do want to venture further, so I'm feeling I need to get re-started with one of the recommended tutorials/books.
Should I start fresh Emacs install instead?
PS: I've coded in a bunch of lisps in the past and I have already done a bit of customization on top of Doom, so I sort of know my way around, but I'm just not comfortable I guess.
My petty opinion is that distributions which disable the menu bar are bad, distributions which use an edgelord dark theme are bad, and distributions which do both are terrible. Where Doom in particular is concerned I dislike the fact that it starts with Vi keybindings by default (I quite disfavour modal editing, there's a reason I switched away from Vim after 5 years) and that it changes the 's' binding so I can't even rely on my muscle memory.
I've tried both Spacemacs and Doom (and others like Witchmacs and Bedrock) and now I'm just using my own 800 line init.el (which does include comments and whitespace so the actual LOC will be lower) and 110 line custom.el (if you set the custom file to a different file than your init then using customize to change settings won't mess things up if you manually edit your init).
If you really like Doom you can try reading its code base, if it's just too much then maybe it would be better to try setting up your own configuration from scratch.
I think some of these are unfair criticisms, because they are things that can be trivially changed. E.g. disabling evil mode or changing the theme are one-line modifications in the Doom config. After all, any opinionated Emacs distro has to make some choices otherwise there would be little point in anyone using one.
For me the issues with Doom are (a) the complexity as a whole that it introduces, and (b) so many things are already installed/configured that you end up using them without any real "under the hood" understanding which is so essential for customisation.
One tip I read somewhere (possibly from Steve Yegge?) was that it's a good idea to disable the Emacs menu bar - and I agree. The Emacs menu bar is this kind of weird uncanny valley thing. It looks like a normal menu bar, but any time you click one of the items on it, you'll find that you're doing something that actually only makes sense if you're into Emacs already. It won't help you when you're starting out, and once you're up and running you won't need it (but you can ctrl+right click on the buffer to get if you ever feel like you do...) - and, meanwhile, it's taking up space on the screen that you could use for more lines of text.
(macOS users are stuck with the menu bar generally, and that means they're stuck with the Emacs menu bar too. Just ignore it.)
While you're there, get rid of the scroll bars too. They never work properly, and this way you get an extra column or two of text per window.
The Edit menu has undo, cut, copy, and paste. Is that stuff that only makes sense if you're into Emacs already? The Help menu has the tutorial and the manual. Same question. The File menu has open file, save, save as, close, and quit. If you open a file which uses a mode which has options you get a menu showing those options.
I don't think the discoverability of all those things is worth giving up in exchange for 1 more line of text, but of course everyone is different and that makes the world such an interesting place.
Hmm, good question. I had another go, for the first time in years, albeit with experienced Emacs eyes now, so I know roughly what's going on. Still felt like every click just gave me More Emacs Shit, which I remember being the main confusing thing.
Almost none of the options bring up a friendly GUI dialog of the sort you might be accustomed to; you're most likely just plonked back in the Emacs frame, possibly in some new window that opened in some random place, that doesn't seem to work quite like anything you've ever seen before, or possibly in the minibuffer, ditto, plus its own set of additional confusing aspects.
So perhaps the suggestion to just dispense with it entirely (along with the toolbar, which I forgot to mention...) was just the thing that got me over this initial notch in the difficulty curve, the bit where I just needed to give up and accept that Emacs was going to be one of those things that was absolutely not like anything else.
(You're not wrong about the discoverability though. I've been using Emacs for 20 years now and I did find a couple of interesting-looking things.)
> What's your take on opinionated distros like Doom Emacs or Spacemacs?
If you use vanilla emacs without customization, you are going to have a very basic text editor experience. That is fine if you understand that, and understand that you'll need to start adding your own customizations (like enabling eglot for LSP, and company-mode for code completions, etc) in order to get to an experience closer to what you'd get out of the box in an IDE like vscode.
Some people might see vanilla emacs, assume emacs is just a plain text editor, and go back to their fancy IDEs. For them, distros like doom/space would be good for avoiding that initial shock/disappointment.
Another great use for doom/space is to see what is possible. Figure out what bits you like, and then figure out how to enable them in your own vanilla-based config. Essentially window-shopping for your own emacs config.
But in the end, I'd recommend you eventually get to the state I am in: I started with a completely vanilla emacs and then slowly added the bits that I wanted. That way I have only what I want, and nothing that I don't want. I don't get surprised by unexpected features. My breakages are fewer because I use so few packages. My load times are great because I am not loading a bunch of stuff I don't use. I understand everything that is enabled in my config.
You also might want to check out emacs-solo. It's a config that is built based entirely on built-in packages rather than 3rd party packages. I still use some 3rd-party packages like company-mode but it is good to see just how far you can go with the built-in stuff (for example, you probably don't need projectile, you can use the built-in project.el, and you probably don't need lsp-mode, you can use the built-in eglot): https://github.com/LionyxML/emacs-solo
Whatever works for you works. If you want to use your editor for a goal, using the guardrails of Doom is fine. I use a vanilla setup as my base but I've been using emacs since before distributions. If you want to tinker or otherwise learn emacs more deeply, feel free to start from a vanilla config.
Don't use them. A personal config is highly personal, and a distro force someone else's preferences onto you. Even things like how exactly your config is organized.
But ultimately it's all about tradeoffs and what works for you. You don't necessarily need to go beyond your distro, but if you want to or need to, then that's a good sign to try it
I went from Emacs to Vim to Vscode and back to Emacs with Doom, but I still use pretty much all of them. Vscode has copilot, Emacs has org mode, vim is great for light editing.
Vim is the magic that lets me use all of those for what I want without having to change muscle memory, and Doom just happens to aligns with my needs perfectly on that regard.
I think anyone trying to master Emacs within the lines of this article will be trying to bend it to their particular needs and likely will be annoyed at any opinionated configuration.
The answer to your question will depend if you want to add community extensions beyond what Doom integrates or if you want to personalize Emacs by yourself. The latter will work just fine with leader keys as long as you map them, all Elisp should be still available in pretty much the same way. The former will probably be much harder.
I personally use Doom because there are a lot of out of the box optimizations, some don't like how hlissner has brought nix ideas of declarative package management into the mix, but I am a nix user so it makes sense. I also am an evil (heretic) user - Doom is configured from the get go as a gateway from vim/neovim into emacs, and it does that job very well.
I would say use both. You can run multiple emacs configurations, and you could have your vanilla config which you slowly build as well as Doom/spacemacs where you can see what is possible.
They have their place. I started out with Doom and it definitely helped to streamline the beginner phase where vanilla would have felt overwhelming. But, as with you, I soon became frustrated when I wanted to move beyond its default configuration.
I've since switched to Vanilla and I've been using ChatGPT to gradually explain and help me integrate the Doom features that I like, so that I end up with a similar base that I actually understand and which I can deviate from where I want to.
I have tried Doom Emacs in a Debian VM on Windows host, because that was the opportunity to install a new Emacs thing for me (to code while playing a game). There Doom Emacs was not stable. Sometimes it just crashed and one time I even lost a whole function I wrote, because somehow it doesn't do the same backup file thing Emacs usually does. The keybindings were nice, but the stability requirement I have overrules it. So I am back to standard Emacs and currently using evil mode.
I'm in the same boat and curious if other more experienced users have any resources to point to. My anedoctal data point is that after starting with doom emacs and having problems to set it up on another machine i fund out all i needed was a very small configuration file to accomplish my orgmode/agenda usage needs. So all it took was an issue and a clear vision of the goal to find a way through. Maybe it is a healthy approach to keep the complexity manageable to your usage
IMO, they're a great way to get started without having to invest too much time up-front. On the other hand, that was 10 years ago and it's a LOT easier to throw together a usable config nowadays; with LSP + built-in tree-sitter modes, you no longer need 3 packages per language plus a bunch of configuration glue.
>>I've been doing my daily journaling and task management on Emacs for while now
Trust me, move to Google Docs.
This is simply a whole larger and easier universe compared to anything Org-mode will ever evolve to be. Its also backed up online, pictures are embedded in the document itself. And several other features come out of the box. You also don't have spend years learning to use it, and can get productive from minute 1.
I think it's become a running theme: senior devs who have been coding for a while now are able to extract value from these tools because, even if you don't know Rust, you know how to code.
BS code smells the same in any language.
Beginner devs don't even know what smelling means.
Seniors being able to extract more from any new tool is a time proven constant. That hasn't changed.
What happened is that companies tried to push an idea that this new AI thing would be inhospitable to whoever is already an experienced programmer. The idea of "new land", fair and equal to all. Smelling woudn't matter, because all smells would be new and unfamiliar.
After insisting on this silly mistake for a while, they realized that experienced programmers were actually their only viable target audience, and attempted to change their approach accordingly. It's embarassing.
I thought this was going to be yet another post about how AI is ruining Junior devs so we'll have a Senior replacement crysis in a few years.
It sort of is, indirectly, and I agree with pretty much everything.
But the bit about sycophancy was particularly enlightening. I actually thought "plain" ChatGPT-like interfaces could be good for learning. But the Youtube ROAS example is really powerful. If the student can skew the teacher's conclusions so much just by the way they phrase their questions/answers, we're going to mislead new programmers en masse.
I'm not even sure that the extensive prompting they say they use for their "Boots" is good enough.
I guess in the age of AI you still need someone to repeatedly reject your pull requests until you learn. And AI won't be that someone, at least for now.
I think I agree. From personal experience, even when I ask for scathing critique, the need to placate and make me feel better seems to bleed through ( both on 4o and 5 as far as I could tell ). I am not sure what to make of it.
We go back to this original prediction that the tool will help those, who both want help and are painfully aware of LLMs peculiar issues.
The incentives align: when the success metric is engagement, it will be optimized for engagement. It makes perfect sense that it is going to agree with you.
> But the bit about sycophancy was particularly enlightening.
I always try to stay above this by prompting the question twice, with the opposite biases. But I of course don't know, which hidden biases I have that the LLM still reinforces.
I just come from writing a comment on the other Datastar post on the home page, literally saying that I don't see the point of it and that I don't like it.
But I'm now here to defend Datastar.
It's their code, which, up to now, they built and literally given away totally for free, under a MIT license. Everything (even what "they moved to the Pro tier") should still be free and under the MIT license that it was published under originally.
You just decided to rely and freeload (as, as far as I can tell, you never contributed to the project).
You decided to rely on a random third party that owns the framework. And now you're outraged because they've decided that from now on, future work will be paid.
The software was released as a free version, with NO expectation for it to go commercial.
The fact that they switch to a paid version, and stripping out features from the original free version, is called "bait and switch".
If OP knew in advanced, he will have been informed about this and the potential 299 price tag. And he will have been able to make a informed decision BEFORE integrating the code.
> You just decided to rely and freeload (as, as far as I can tell, you never contributed to the project).
But you complaint about him being a freeloader for not contributing to a project. What a ridiculous response.
I feel like you never even read the post and are making assumption that OP is a full time programmer.
Datastar can do whatever they want, its their code. But calling out a *bait and switch* does not make OP the bad guy.
Yeah, I agree, it's over the top. I'm just matching the over-the-top language of the original post, which pretty much calls the Datastar devs "disgraceful" and to "f them".
I did read the post. I know OP not a programmer. And that makes it even worse: OP has the audacity of saying they "make no money from the project" while it being a scheduling tool for their presumably plenty money-making clinic.
It would in fact be less shocking if they were a programmer doing a side project for fun.
This piece is not a rational, well tempered article. Is a rant by someone who just took something that was free and is now outraged and saying fuck you to those who made their project possible in the first place, not even understanding how licenses work or even being aware that the code they relied on is still there, on github, fully intact, and available for them.
This sort of people not only want to get it for free. They want their code to be maintained and improved for free in perpetuity.
its not bait and switch, its main has features we are willing to continue to support given we did a whole rewrite and this is what we think you should use. Don't like it? Fork it, code is still there. I hope your version is better!
> its not bait and switch, its main has features we are willing to continue to support given we did a whole rewrite and this is what we think you should use. Don't like it? Fork it, code is still there. I hope your version is better!
It sounds like your are the dev of Datastar...
Let me give one piece of advice. Drop the attitude because this is not how you interact in public as the developers of a paid piece of software.
You can get away with a lot when its free/hobby project, but the moment you request payment, there is a requirement for more professionalism. These reactions that i am reading, will trigger responses that will hurt your future paycheck. Your already off on a bad start with this "bait and switch", do not make it worse.
I really question your future client interactions, if they criticize your product(s) or practices.
> I hope your version is better!
No need for Datastar, my HTMX "alternative" has been in production (with different rewrites) over 20 years. So thank you for offering, but no need.
I'll certainly defend d*'s right to do what they did, but the wisdom of doing so is going to come into question as soon as they reject a PR because it contains a feature that's in Pro. I don't think people who are concerned about that deserve to be called "freeloaders", but I guess a fork is a way out of such acidic rhetoric too.
D* has a core, which is open and will be set in stone soon when v1 is released, with the expectation that it'll barely, if ever, change again.
The rest is plugins, which anyone can write or modify. There's no need for the plugins to get merged upstream - just use them in your project, and share them publicly if you want. You could even do the same with the pre-pro versions of the pro plugins - just make the (likely minor) modifications to make them compatible with the current datastar core.
They're also going to be releasing a formal public plugin api in the next release. Presumably it'll be even easier to do all of this then.
Sounds like they put some real thought into it then, which is good news. I was picturing two different core distributions, which would create the sort of conflict I was imagining, but as long as core does stay maintained, it seems likely that fear will stay imaginary.
As I answered somewhere else, the over-the-top freeloader term I think is justified because OP clearly expects not only to benefit from the work already available, freely, but also to be entitled, for free, to any work and improvement that comes in the future.
This is nonsensical. Someone did something for free. Fantastic. They used it, successfully, for a production system that enables scheduling for their job.
Nobody took that away from them. They didn't force them to rebuild their tool.
The code is even there, in the git history, available for them.
If OP doesn't like what the devs decided to do with the project, just move on or fork and pay someone to help you fix any outstanding bugs or missing features.
The “outrage” is literally just people saying they’ll use a different project instead. Why would they ever fork it? They don’t like the devs of datastar they don’t want to use it going forwards. Yes the developers are allowed to do what they want with their code and time, but people are allowed to vote with their feet and go elsewhere and they are allowed to be vocal about it.
There's something to investigate here.
Made me notice I'm actually exposed to very similar crap on other places. Scary.
reply