What a wonderful statement.

How is that a paradox? It’s like saying its a paradox that cameras on phone made it much easier to photograph and as a result, people make more photos. That isn’t a paradox, that is natural. Same for writing software.

Like, Subscribe and ring the bell.

deleted by creator

But it was promised that each electron from my body will be removed, until I’m smoke only. I assume this will take an eternity, but I’m here for science.

Just use Electron.

On a slightly different example, the suckless project has a huge emphasizes on lightweight code, which they call “suckless”. I don’t think in this case faster is the goal, but having less code and be simple as possible (not even configuration files allowed, you just recompile program) and almost no documentation in the code either. But the idea is the same, of having “lightweight” code.

• The fastest code is the code you don’t run.

Not really. The code can be slow, even if I do not run it. Also, sometimes additional code can do optimization (like caching), which is more code = faster. Or additional libraries, complexity and code paths can in example add multicore execution, which could speed up. So, I do not buy the less code is faster logic.

English.

Me too. What happened there? I thought it might be because some of my browser extensions block few scripts and other elements. Enabling some of the stuff didn’t make reveal the article, so I lost interest. Or is it paid?

I was there too doing lot of generalized functions that do everything. And I always hated the code. I am just hobby commandline guy, but even that is horrifying code. Doing this in complex code bases with real world impact is just bad.

Trying to abstract everything away in multiple layers of classes and function calls, just to avoid to write a 2 lines of code twice is the biggest evil in programming. Well probably not the biggest, but a huge problem in my opinion. Adding unnecessary complexity due to being clever is evil.

Only if you are dependent on Ai, because you cannot program yourself or don’t want to.

!(r.SendNow || r.DryRun) requires you to read the entire statement and then negate the result. While !r.SendNow && !r.DryRun each part of the statement stands on its own and is negated for themselves. That is how I read. I like the Ai suggestion more, because that is how I would write it myself. What I like about it is, that the negation of is right there with the variable. It gets more important, the more you divide sub-expressions in multiple lines.

It’s actually the first time I used to do Ai assisted unit test creation. There were multiple iterations and sometimes it never worked well. And the most important part is, as you say, think through and read every single test case and edit or replace if necessary. Some tests are really stupid, especially stuff that is already encoded in the type system through Rust. I mean you still need a head for revision and know what you want to do.

I still wonder if I should have just gave it the function signature without the inner workings of the function. That’s an approach I want to explore next time. I really enjoyed working with it for the tests, because writing tests is very time consuming. Although I am not much of test guy, so maybe the results aren’t that good anyway.

Edit: In about 250 unit tests (which does not cover all functions sadly) for a cli json based tool, several bugs were found thanks to this approach. I wouldn’t have done it manually.

I like writing code myself, its a process I enjoy. If the LLM write it for me, then I would only do the worse part of the job: debugging. Also for many people let the Ai write code means less understanding. Otherwise you could have written it yourself. However there are things when the Ai is helpful, especially for writing tests in a restrictive language such as Rust. People forget that writing the code is one part of the job, the other is to depend on it, debug and build other stuff on top.

Well that wasn’t meant to be too serious. You are surely aware of the situation that Haskell is not often used language in production. And a huge project you are doing with lot of Haskell is definitely something special.

he’s very familiar with C and C++. In his associated writeup on his Gopher page (link though Floodgap) [jns] simply declares it’s a language he’s quite fond of, which is reason enough of us.

So there are no technical reasons to do so. Its totally understandable to like and use a language for personal feelings. But it kinda feels like unnecessary complicated. So this should be done as a hobby project on something that is not important in my opinion.

Make it in Haskell if you want impress me.

I am a European who grew up with the German layout. For programming, its a disaster. Even back in 2006ish or so when I learned about AutoHotkey, I started using the US keyboard layout. After some time I switched entirely to the US layout. But recently, just a few years ago I found out there is a hybrid layout which is basically US, but with additional shortcuts to use my German characters (it shows up as this in KDE): German (US)

Yeah, looks like this tool is bullshit too. I have similar results with my own written text too. I will edit my text and stop posting about this tool.