If the LLM hype doesn't cool down fast, we're probably looking at another AI winter. Appears to me like he's just trying to ensure he'll have funding for chasing the global maximum going forward.
> If the LLM hype doesn't cool down fast, we're probably looking at another AI winter.
Is the real bubble ignorance? Maybe you'll cool down but the rest of the world? There will just be more DeepSeek and more advances until the US loses its standing.
Completely agree. At the same time, I'd wager a good chunk of developers isn't really in it for a love of computers and tinkering. Not a bad thing per se, just my observation.
For me, the power of Emacs is mainly that I can do everything with the keyboard, which is not only much faster, but also - to me - much more enjoyable than going through visual menus with the mouse.
For someone not good with the keyboard, it's probably a nightmare. I suppose it's good for power users and terrible for casual users, and I don't know if there's any way to really build one user interface that works equally well for both, it's usually a compromise.
The next best thing I love about Emacs is that I can do anything conceivable with code. This one is an even larger gap between power users and casual users.
I think tools like that are just fated to only attract a select few.
When I got into emacs 20+ years ago the "use only the keyboard" thing was a huge point of pride and to this day I don't understand why. Who cares? I use emacs because I can code the entire environment.
Fundamentally the mouse is just a form of modal editing. Emacs supports this in spades of course, and god-mode is my modal input minor mode of choice, but clicking to jump to a position on screen can often be a lot faster than I search or avy-jump commands, say nothing about how much gentler on the wrist it is. Then you can customize the menus and toolbar icons so you can be 1-2 clicks away from something that would otherwise require a chorded keypress or worse, an M-x command.
Then you have the biggest benefit of using the mouse: scrolling around reading code or text while having a drink or snack in the other hand. These days I use a trackball in my left hand. Regardless, the keyboard vs mouse thing always struck me as one of the many dumb flamewars that tech people engage in.
Pretty much every ergonomist will tell you that mouse use causes more ergonomic pains than keyboard use. They literally tell you to memorize as many keyboard shortcuts as possible.
> but clicking to jump to a position on screen can often be a lot faster than I search
It can be, but is it the norm? I have a distinct memory - over 15 years ago - of reading a blog post that recommended isearch to move the cursor and realizing how right it was. I suppose not everyone agrees.
> say nothing about how much gentler on the wrist it is
A bad mouse is as bad as bad posture on the keyboard. You only realize this once you're in pain. Not everyone reaches the point of pain.
> say nothing about how much gentler on the wrist it is
You should not be moving your wrist! Move your whole arm. Once again, one realizes this only when you're in pain. Not everyone reaches the point of pain.
> Then you can customize the menus and toolbar icons so you can be 1-2 clicks away from something that would otherwise require a chorded keypress or worse, an M-x command.
The same argument works for keyboard. If you're going the route of customizing the menu for particular commands, you can also customize the keyboard to minimize the keystrokes for those commands (e.g. via hydra).
Get in the habit of using Ctrl-r (isearch-backward) and Ctrl-s (isearch-forward) for moving around in the document. Whenever you need to jump the cursor backward or forward more than about 5 lines, and you can see the target location, you should be using i-search.
To do it effectively, you don't necessarily need to search for the exact word where you want to put the cursor. Let your eye defocus slightly and take in the whole paragraph or region around the target point, and choose a word that looks reasonably unique or easy to type. Then i-search for it to navigate to it. You may need to hit Ctrl-r or Ctrl-s repeatedly if your anchor word turns out not to be unique. But Emacs will highlight all the matches, so if there are more than a couple of them, Ctrl-g out of the search and choose another anchor word.
It's difficult to overemphasize how powerful this technique is, once you've mastered it. Mastering it simply requires that you do it repeatedly until your fingers do it "automatically". Emacs eventually becomes like an extension of your body, and you'll be performing hundreds of different keystrokes and mini-techniques like this one without thinking about them. It's comparable to the hundreds of subtle techniques you acquire for driving a car well.
> Pretty much every ergonomist will tell you that mouse use causes more ergonomic pains than keyboard use. They literally tell you to memorize as many keyboard shortcuts as possible.
Right but that's because their advice is tailored around the "average" computer usage, which is lots of mousing to click around in buried menus and hunting and pecking on the keyboard. RSI is just what it says: Repetitive Stress Injury. The best palliative for RSI is to stop repetitively stressing the same tendons and ligaments. So that means breaking up your keyboarding with some mousing. Alternating which finger and which hand you use. Getting up and stretching and taking breaks. Maybe using some dictation in lieu of using an input device.
If you're writing text, your mousing is mostly going to be scrolling, unlike doing something like CAD or design or illustration. In that context, the context of using emacs, mousing is fine.
And realistically, for my own RSI, exercise was the real solution. Rock climbing increased the blood flow to my wrists significantly. That's probably the only real solution to RSI.
> Regardless, the keyboard vs mouse thing always struck me as one of the many dumb flamewars that tech people engage in.
Certainly. I wouldn't argue that text editing speed is a relevant bottleneck in software development, actually. To me it's enjoyable and that's a big factor in my productivity, but that's just me.
My point was mainly that the keyboard (efficient use is difficult to learn) vs mouse (arguably easier to learn) is just one example of why the current desktop metaphor won over something I'd say is designed for heavy keyboard use (even if usable without it). The "code the entire environment" thing you mention is another example. Not sure I expressed that point all that well, rereading my comment it almost looks as if I'm trying to start a flame war :D
> My point was mainly that the keyboard (efficient use is difficult to learn) vs mouse (arguably easier to learn) is just one example of why the current desktop metaphor won over something I'd say is designed for heavy keyboard use (even if usable without it).
This comparison of the mouse and keyboard seems to have programmer tunnel vision. Anything involving layout, graphs, media editing (audio, video, image), 3D modeling, and drawing I think we can all agree are better served by the mouse (in tandem with the keyboard). It's really the mouse and keyboard together that's made the computer such a successful creative medium. Programming seems to me like a bit of anomaly in that it's one of the few creative tasks that doesn't benefit greatly from a mouse.
I have been coding for so long now that I can't have my keyboard any higher than my lap. I code with it resting directly on my legs. A mouse is right out. Any higher, and my hands turn to clubs.
I love emacs because I can do everything with the keyboard. It is faster and a lot easier on your body long term. My advice, start young. Keep your keyboard directly on your lap and use a ortholinear plank keyboard so your fingers don't have as far to travel. I was skeptical at first, but I will never go back.
Alternate between using the left and right Alt keys. The ergonomist's rule of thumb (no pun intended) is to use both halves of the keyboard. So if pressing Alt-x, use the right Alt button, etc.
I had RSI issues early in my career and this advice alone really helped. Never got the Emacs pinky/thumb. I recently switched to a MacOS and that is giving me thumb issues with the overuse of the Meta button. I now consciously have to force myself to use a different finger when pressing Meta.
Always remember: You have five fingers - no need to keep using the same one/two fingers to press Ctrl or Alt. It will take time getting your brain used to using other fingers for this purpose.
Oh, and yes: Definitely got lots of ergonomic pains due to mouse use. In fact, I changed my career from "regular" engineering to SW engineering partially to avoid having to use a mouse (e.g. CAD SW). And every ergonomist you'll meet will tell you "Memorize keyboard shortcuts and avoid the mouse as much as possible."
As the sibling comment put it, that’s when I look into ergonomics accessories.
My primary mouse is a trackball one, because I have pain in my arm (elbow and shoulder) when I use a regular one on a desk.
I will maybe get a split keyboard in the future. But I did get a mechanical one because of key travel. And I touch type, so I spend less time on the keyboard itself.
This is the thing people forget about emacs - it is primarily a lisp environment, entirely programmable. Something one can make their very own. Nothing else comes quite as close, even if the keyboard ergonomics (at least for me) do help to sell it. You can change the workspace to better the workflow in real time, that's the biggest selling feature.
And this is why, even though it is a better OS environment my grandmother will never use it.
And because emacs is under socialized and under adopted the emacs user will still have to use notion or outlook or whatever corporate security requires.
I'm not going to argue that emacs if "for everyone" and there's plenty in my own life that I'm happy to accept defaults in. But that said, it's not that hard to glue emacs onto existing tools if needed. If you're in a situation where you can only send emails on a locked down email client you can still script the client through emacs and some glue code. On MacOS, Apple script does wonders and for Windows there's AutoHotKey. Linux obviously is infinitely malleable.
To be fair to corporate, Emacs has a pretty terrible security model.
There's no reason a program like Emacs couldn't exist which had something like capabilities baked in, but as it is, every package has access to anything it wants.
I think this largely misses the point. It isn't about which out of keyboard vs mouse is objectively better or faster. It's about subjective comfort. If a system "feels" nicer to use then I'll feel more motivated while using it which means I'll use it more and be more productive, and that's a sufficiently good reason to prefer one over the other. For me, that means using the keyboard and not the mouse.
There's a ton of comments here saying the keyboard is more ergonomic than the mouse, I've never heard that before and it feels wrong on its face (it's called repetitive strain injury, using multiple forms of input should helpful).
But generally, please if you believe this provide some kind of source.
It's one of the oldest forms of "programmer identity" out there, one of those shibboleths that people who culturally identify as a hacker express that's independent of its factuality. A bit of a precursor to social media which elevates in group shibboleths over data as a matter of course. Programmers were the first to invent and use social media after all.
It is more than just that it uses lisp. I do like that, and I think it is the correct choice. But it is more that even something as basic "move cursor down" is not tied directly to a specific key. And the help system will literally take you to the source for any command, if you ask it to. (Takes some setup for this to work down to the c source, but it is there.)
Is a bit like having a problem with "ls" and wondering if you could fix it by scanning the source real quick. In emacs, that is often just a keystroke away. In most systems, good luck.
You can but that doesn't neccesarily mean you should.
I tried it for a while, after seeing my Eve Online friend skipping through tasks at a rate of knots without any mouse movement. My god the amount of tab pressing I had to do to get anything done was crippling. I might have to jump through 15 times to get to something that would take me less than a second to click.
Right, but not all, which is what makes unplugging your mouse from Windows painful. On Linux, I often forget to plug my mouse in and only notice when I want to play a game or something.
1. For small stuff, AWS et al aren't that much more expensive than Hetzner, mostly in the same ballpark, maybe 2x in my experience.
2. What's easy to underestimate for _developers_ is that your self hosted setup is most likely harder to get third party support for. If you run software on AWS, you can hire someone familiar with AWS and as long as you're not doing anything too weird, they'll figure it out and modify it in no time.
I absolutely prefer self hosting on root servers, it has always been my go to approach for my own companies, big and small stuff. But for people that can't or don't want to mess with their infrastructure themselves, I do recommend the cloud route even with all the current anti hype.
> 2. What's easy to underestimate for _developers_ is that your self hosted setup is most likely harder to get third party support for. If you run software on AWS, you can hire someone familiar with AWS and as long as you're not doing anything too weird, they'll figure it out and modify it in no time.
If you're at an early/smaller stage you're not doing anything too fancy either way. Even self hosted, it will probably be easy enough to understand that you're just deploying a rails instance for example.
It only becomes trickier if you're handling a ton of traffic or apply a ton of optimizations and end up already in a state where a team of sysadmin should be needed while you're doing it alone and ad-hoc. IMHO the important part would be to properly realize when things will get complicated and move on to a proper org or stack before you're stuck.
You'd think that, but from what I've seen, some people come up with pretty nasty self hosting setups. All the way from "just manually set it all up via SSH last year" to Kubernetes. Of course, people can and also definitely do create a mess on AWS. It's just that I've seen that _far_ less.
One way of solving for this is to just use K3s or even just plain docker. It is then just kuberneters/containers and you can hire alot of people who understand that.
Exactly. I also assume that the author was “writing” his stories in the head, while doing construction. He then just had to quickly put it onto “paper” in his breaks.
1. Reject it on the grounds of being too large to meaningfully review. Whether they used AI or not, this is effectively asking them to start over in an iterative process where you review every version of the thing and get to keep complexity in check. You'll need the right power and/or standing for this to be a reasonable option. At many organisations, you'd get into trouble for it as "blocking progress". If the people that pay you don't value reliability or maintainability, and you couldn't convince them that they should, that's a tough one, but it is how it is.
2. Actually review it in good faith: Takes a ton of time for large, over engineered changes, but as the reviewer, it is usually your job to understand the code and take on responsibility for it. You could propose to help out by addressing any issues you find yourself rather than making them do it, they might like that. This feels like a compromise, but you could still be seen as the person "blocking progress", despite, from my perspective, biting the bullet here.
3. Accept it without understanding it. For this you could _test_ it and give feedback on the behaviour, but you'd ignore the architecture, maintainability etc. You could still collaboratively improve it after it goes live. I've seen this happen to big (non-AI generated) PRs a lot. It's not always a bad thing. It might not be good code, but it could well be good business regardless.
Now, however you resolve it, it seems like this won't be the last time you'll struggle to work with that person. Can, and do they want to, change? Do you want to change? If you can't answer either of these questions with a yes, you'll probably want to look for ways of not working with them going forward.
Oh you're gonna learn how things work, if you stick around long enough. The decision you get to make is whether you'll learn one thing at a time while you're building, or everything all at once under pressure at 2am.
I feel in this context, refactoring has lost its meaning a bit. Sure, it's often used analogous to changes that don't affect semantics. But originally, the idea was that you make a quick change to solve the problem / test the idea, and then spend some time on properly integrating the changes in the existing system.
LLMs struggle with simplicity in my experience, so they struggle with the first step. They also lack the sort of intelligence required to understand (let alone evolve) the system's design, so they will struggle with the second step as well.
So maybe what's meant here is not refactoring in the original meaning, but rather "cleanup". You can do it in the original way with LLMs, but that means you'll have to be incredibly micro manage-y, in my experience. Any sort of vibe coding doesn't lead to anything I'd call refactoring.
I think a lot of this is because people (and thus LLMs) use verbosity as a signal for effort. It's a very bad signal, especially for software, but its a very popular signal. Most writing is much longer than it needs to be, everything from SEO website recipes, consulting reports, and non-fiction books. Both the author and the readers are often fooled into thinking lots of words are good.
It's probably hard to train that out of an LLM, especially if they see how that verbosity impressess the people making the purchasing decisions.
> I think a lot of this is because people (and thus LLMs) use verbosity as a signal for effort.
It's also one of the main use-cases for non-programmer use of the models, so there are business-forces against toning it down. Ex: "Make a funny birthday letter for my sister Suzie who's turning 50."
Withdrawal symptoms :P The buyer decides whether their problem is a good one to have and whether the solution is adequate. Even when it's, objectively, not.
I was hiring for a Django dev earlier this year. For the case study, almost all of them built a thin API backend in Django, and a React monster for the frontend (and in some cases, pretty much all the business logic). When asked about their motivations, almost nobody could explain it.
We hired one of the very few people that just used SSR.
i can explain it. (ok, i can't explain why someone would create a react monster instead of using a better suited frontend framework, but i can explain why i prefer to separate backend and frontend)
ever since i started using frontend frameworks for websites, the backend has become trivially simple. so simple that i have been able to reuse the same backend for all my websites built since. most websites do not need more than CRUD on the backend. and even for those that do need more backend logic, separating front and backend makes both parts easier to develop. they don't get entangled, and i can make drastic changes in either part without breaking the other.
frontend frameworks allow me to think of the frontend as an independent client application that runs in the browser. instead of having a complex application that displays here but runs over there, i have two simple applications, one that runs on the server and one that runs in the browser.
using a frontend framework makes development feel like writing a desktop application. i don't have to consider network latency, except to load and update data. but that can happen in the background. it doesn't affect the UI. it makes me think about loading data from the server efficiently. it allows me to preload data in the background. it allows me to cache it so that when the user switches between different views, the data doesn't have to be reloaded, yet it can still be updated.
you can do this with a server framework only too. but getting that working smoothly across multiple page loads is a lot more complex than having all views that share data in a single page application.
I like that too, in theory. We used to call that "rich client". Basically UIs that had full database access.
And there begin the problems. Do you really want to expose a full CRUD API, or are there consistency/security rules you want to enforce? That's cool, but makes API design a little more challenging and frontend development a little more frustrating. SSR eliminates a lot of these problems, and for many types of software, it's quite sufficient.
For a lot of software, it doesn't make that much sense of course, e.g. if you need clients for multiple platforms.
That's the kind of conversation I wanted to have with the candidates that went for that architecture.
Do you really want to expose a full CRUD API, or are there consistency/security rules you want to enforce? That's cool, but makes API design a little more challenging and frontend development a little more frustrating.
fair point, however i don't see that as a drawback. the security/consistency rules you want anyways. and an API makes it easier to enforce them and not allow people working on the frontend to get around them because they have direct access to the database. in difference to what you said, i believe the benefit of a rich client is that it doesn't have full access to the database, but only the access the API provides.
i also don't feel that it makes frontend work more frustrating, on the contrary, it means i don't have to worry about access control in the frontend because the backend is supposed to take care of that.
to give an example: if i want to limit the size of the text field, i have to implement checks twice, once in the html/js, to help the user, and once in the database access to make sure the user didn't cheat. i have to do that regardless of whether front and backend are separated or not. it doesn't make a difference. but the separation ensures that the frontend code can't get around the limit.
where it does get frustrating is when you have different teams that have to communicate and agree. but the problem there is the team size, not the architecture.
this subthread started out with the claim that small teams don't need the complexity of frontend/backend separation introduces. that's where i disagree. the complexity shouldn't be an issue. as i said, i find it reduces complexity. a small team also won't have the communication problems when disagreements arise over the API. they can handle that like disagreements over the class hierarchy or datastructures or whatever. you talk about it, make a decision and everyone is on the same page on what to implement.
That's the kind of conversation I wanted to have with the candidates that went for that architecture
For the consistency/security rules, I meant that any API accessible in the browser is also publicly accessible to anyone. Quite a lot easier to e.g. syphon data out of a system than if they just did SSR. So if you want to avoid that, you'll have to build a proverbial Chinese wall between frontend and backend. And whenever you want to add a feature, you'll have to adjust that wall.
For SSR, the devs working on the frontend can access anything they like. Sure, in bigger teams and for important consistency rules you'll want to encode that, but it's all a _very_ solved problem with stuff like Django.
For the consistency/security rules, I meant that any API accessible in the browser is also publicly accessible to anyone.
not quite. you still need access credentials. having an API doesn't mean that anyone can access it without permission. you protect an API the same way you protect the actual website.
Quite a lot easier to e.g. syphon data out of a system than if they just did SSR.
if the data is sent to the client, then the client ca access it either way. sure, embedding it in HTML makes it harder to parse, but that is really just security by obscurity. that's actually another reason why i prefer APIs. they make it blatantly obvious what data you are publishing. in a SSR page it is easier to let things slip through. the SSR page looks like a closed box, it gives the impression that it is possible to prevent users from entering that box and getting data out of it, but that is an illusion.
you'll have to build a proverbial Chinese wall between frontend and backend.
which is the API. small, only containing what is needed, very easy to verify that private data doesn't leak out.
Yeah, if the API design prevents this, parsing HTML is about as hard. But I've seen a lot of cases where a single request will get you _all_ the data you could ever want, a lot of it not even rendered on the frontend, no need to deal with pagination or anything. Kinda full database access as long as you have an auth token, which any logged in user has.
those are the cases that make it into the news when someone reports the insecurity of a API they found, and then gets accused for breaking into the website or database.
there are many reasons to prefer SSR over SPA, but covering up incompetence should not be one of them. designing an API is not hard.
My main issue with putting state in the frontend is that you introduced sync points, which is where, like, 90% of the bugs happen.
Take form input and validation. Great, let's write out the validation on the frontend. But that doesn't mean much. We need to sync it.
Okay... So let's just write the validation, again, on the backend. Hope it's the same validation. It never is, so we just introduced a whole class of bugs around that.
Or just take a look at routing. Okay, let's route on the frontend. But what about access control? Okay, let's do a little routing logic on the backend too. Oh and now we've run into the same problem.
When you do rich frontend and backend, you always have a minimum of two application states. You have two apps. You cannot get rid of the backend state, it's non-negotiable.
So you have to keep them in sync, or more accurately, try to keep them in sync.
you have to do the same on the server side and your database, if you have one. the API is just data too. you don't keep all your application state in you database, do you?
i don't know what kind of application you have in mind, but in mine the frontend state and the backend state are entirely different things. the only thing that needs to be kept in sync is the data itself. and that's easier than the whole frontend state which is a lot more complex. in most cases you treat the backend like a database itself. there is n additional state to be kept in the backend, than what goes into the database. at least with all the applications i ever built. i am sure there are other applications that are more complex, and i may change my mind when i get to work on one, but i believe most applications are CRUD, and complex UI state is only in the fronted, data state in the backend/database,
I keep as much state as I can in the database, yes. For example - foreign keys. I use constraints in the database to enforce application logic.
I could do this in the backend, yes. But that's needless complexity and it will blow up. Eventually, I'll write something to the database that's inconsistent and then I have to fix it. Because bugs happen.
hmm, i don't want to come across as argumentative, it is more curiosity, because i simply never wrote apps that way. i just don't see how application logic could affect the data itself. the data is independent, and of course there are constraints for data consistency, but it is completely separated from the application logic. application logic doesn't make it into the database at all, or if it does then at best i might store some application specific states in a separate area in the database. effectively a different database than the one that has actual data. i can't think of an example where that separation would not be possible.
the difference is how the application feels to the user. especially on a slow network. for every pageload in hackernews i have to wait seconds. as an SPA i would not have to wait at all unless i open a new story. because new comments can be loaded in the background while i read, and my own comment submissions can be sent in the background too.
