kristiandupont

I am reminded of this course in university where there was a written assignment with a minimum page count. Even at that time, I remember thinking: "If I am able to express everything necessary in just one page, that should give me the absolute top grade!".

The backend for a game is not just an .exe file. It can be a mess of a system that relies on all kinds of services that need maintenance and that one dev who knows how to reset the cache.

I agree that it's shitty that buyers can lose access to a game they bought, but I really struggle to see how this could function practically.

I feel similarly. I really liked React when it came out because compared to the alternatives at the time, it just felt perfect.

I still prefer it over almost everything, including Svelte, Vue and Solid. But I have started using Crank (https://crank.js.org/) which seems a step closer to where I want to end up. However, I have so far only used it for toy projects so I can't speak to how well it will scale, both in terms of performance and DX.

What people mean is obviously that you use JS primitives for looping, branching, conditionals, etc. over some DSL. Everybody knows that the tags are added syntax, there is no conspiracy here.

It reminds me about this video where John Cleese talks about creativity. One of his points is that his work was better than some of his more talented peers simply because he set aside more time to let ideas mature:

https://www.youtube.com/watch?v=Pb5oIIPO62g

For one thing, just about every airline in the world is a potential customer.

That seems like a very, very long-winded way of accusing them of "embrace, extend, extinguish"? Which is obviously not falsifiable, but just feels a bit trite at this point, IMO.

I personally switched back to vscode as I started using Claude and Opencode more for the AI flow, and I didn't see much added value any longer. Also, I was incredibly frustrated that they decided to hide the close button and finally, there were weird issues with editor groups spawning at unwanted times. They might be able to fix it, but I felt that they were starting to reach the limits of what you can do with a "live fork".

..assuming that those roles will be performed by humans, that is.

SQLite is a rock solid piece of software that offers a great value prop: in-process database. For locally running apps (desktop or mobile), this makes perfect sense.

However, I genuinely don't see the appeal when you are in a client/server environment. Spinning up Postgres via a container is a one-liner and equally simple for tests (via testcontainers or pglite). The "simple" type system of SQLite feels like nothing but a limitation to me.

I agree that this isn't a very interesting example, but your statement is: "just asking the model to do a simple transform". If you assert that it understand when you ask it things like that, how could anything it produces not fall under the "already in the model" umbrella?

They may not be, but even so they might find themselves in a prisoner's dilemma. I wouldn't rely in this logic for peace of mind.

>For short-sighted management, this is all desirable since the sloppy output looks nice in the short term

It was a sobering moment for me when I sat down to look at the places I have worked for over my career of 20-odd years. The correlation between high quality code and economic performance was not just non-existing, it was almost negative. As in: whenever I have worked at a place where engineering felt like a true priority, tech debt was well managed, principles followed, that place was not making any money.

I am not saying that this is a general rule, of course there are many places that perform well and have solid engineering. But what I am saying is that this short-sighted management might not be acting as irrationally as we prefer to think.

Why would it need people to steer the AI? I can easily see a future where companies that don't rely on the physical world (like manufacturing) are completely autonomous, just machines making money for their owner.

I wrote my own modal-mode extension for vscode/cursor because couldn't get the VIM-ones to function like I wanted. During that time, I thought that I should look into Kakoune and Helix as those seemed to represent a true iteration on the paradigm. Being able to see what you're about to change makes complete sense, as does the "multi-cursor first" approach.

However, after a few weeks, I ended up rewriting things to be more classic VIM-like after all. This might have just been muscle memory refusing to yield, I am not sure. One thing I remember though, was that the multi-cursor+selection approach only really helps when you can see everything you're about to change on the screen. For large edits, most selections will be out of the scroll window and not really helping.

I still haven't written it off completely, though with AI I increasingly find myself writing more prose than keywords and brackets, so I am not sure it's going to feel worth it.

I had Claude help me get a program written for Linux to compile on macOS. The program is written in a programming language the author invented for the project, a pretty unusual one (for example, it allows spaces in variable names).

Claude figured out how the language worked and debugged segfaults until the compiler compiled, and then until the program did. That might not be magic, but it shows a level of sophistication where referring to “statistics” is about as meaningful as describing a person as the statistics of electrical impulses between neurons.

I have been positively surprised with Mistral which I have been trying out.

I am very curious about this significant hint, could you point me to some material?

Very cool! I'll try it out!

Very nice! I am the author of Kanel* which generates types for each table, view, etc. I tend to use it together with Knex which gives me strong type safety from simple selects and updates and sporadic type safety from complex queries with joins etc.

The advantage to your approach (I guess) is increased type safety for complex queries, trading off the loss of "fundamental" types with, say, branded ID types? I guess the two approaches are quite complementary, perhaps I should try that.

* https://github.com/kristiandupont/kanel

I shared this tool for remembering recurring tasks on LinkedIn: https://github.com/kristiandupont/balls-in-the-air and it got quite a bit of attention.

No login or signup is required so it's very easy to try out and quite fun to play with, which probably helped. I think the time people are willing to invest in something before getting some sort of reward is approaching sub-second territory.

>And that's probably something most people are okay with

You think most people are okay with most white collar jobs disappearing? I certainly am not, personally.

The point of that thought exercise is to show that reasoning by induction is flawed. As best I can tell, you discount it with further induction.

I've used gas and induction stoves and they are almost comparable. I certainly wouldn't replace my heat pump and induction stove with gas.

I don't feel that I see this anywhere but if so, I guess I'm in a third camp.

I am "pro" in the sense that I believe that LLM's are making traditional programming obsolete. In fact there isn't any doubt in my mind.

However, I am "anti" in the sense that I am not excited or happy about it at all! And I certainly don't encourage anyone to throw money at accelerating that process.

Hallucinations, no. Mistakes, yes, of course. That's a matter of prompting.

I use LLM's to write the majority of my code. I haven't encountered a hallucination for the better part of a year. It might be theoretically unsolvable but it certainly doesn't seem like a real problem to me.

Only tangentially related, but: what is the appeal of TUI's? I don't really understand.

The advantages of CLI's are (IMO) that they compose well and can be used in scripts. With TUI's, it seems that you just get a very low fidelity version of a browser UI?