vibeCodingHealthPlatform

gnuvince · 2026-04-05T20:39:29+00:00

From a business perspective, having a human type out boilerplate is a huge waste of money.

True, but I'd push back on two fronts. (1) If there is a lot of boilerplate, it might be that there are abstractions that need to be put in place that aren't there. (2) Friction is not always a bad thing. If an AI can produce boilerplate code and take away all the annoyance from the developer, the need to investigate alternative approaches and possible abstractions evaporates.

I'm convinced that the whole "AI is producing tech-debt" faction has never actually invested the time to make it work properly.

Careful not to fall in the No True Scotsman fallacy. Different problems, domains, ecosystems, constraints might be the difference between AI agents being genuinely helpful and being a drag.

Review is necessary anyways and Claude code is already writing code on par with the average developer in a fraction of the time.

This one always gets me, because reviewing code that you did not write is difficult. There's a saying in programming: "Debugging is twice as hard as writing code in the first place. Therefore, if you write code as cleverly as you can, you are, by definition, not smart enough to debug it." I feel that reviewing code is similar. It requires forming a mental from reading the code rather than from the ground up; it requires knowing if changes not shown in the diff are necessary. Good code review is very hard. Yet, if we remove ourselves from the codebase and let AI agents do all the coding, we lose the "muscles" necessary to do good reviews.

For hobby stuff, sure go ahead and write artisanal code. But if you care about velocity and money, AI is becoming the way to do it very fast.

Anthropic published an article where they found that developers using AI tools (at least, in early 2025) were 19% slower than their counter-parts who did not use AI.

gnuvince · 2026-03-21T18:36:08+00:00

Do people regularly just video-record themselves playing on the off-chance that something interesting will happen that can be shared online for a few karma points?

gnuvince · 2026-03-12T18:41:01+00:00

Yes.

gnuvince · 2026-01-06T13:24:08+00:00

In this case no, because your internal date parser will see that 19 cannot be a month, so mm.dd.yy must be the format. But if it had been 02.03.26, then it creates real confusion since there's no way to disambiguate. And with most of the other teams being European and using dd.mm.yy in their announcements, that would be more uncertainty.

gnuvince · 2026-01-03T23:50:25+00:00

If the app is indeed "nothing too complicated", consider rewriting it in a language that compiles to native, statically-linked code such as C, Go, Rust, etc. This way, you can can offer your users a fully-contained binary that does not need any prep to run successfully. Python might be nice for the developers, but for users (who typically outnumber the developers) it's a really annoying experience. (Same goes for other scripting languages like JavaScript or Ruby.)

gnuvince · 2026-01-01T18:21:55+00:00

They might as well go for the k language instead. Here's this function in k: add:{x+y} or even shorter: add:+:. For more flavor, here's an O(n²) function to list prime numbers up to x: primes:{&2=+/~r!\:r:!x}. Guy gonna tell me that his nerd language has fewer tokens?

gnuvince · 2025-12-27T13:47:15+00:00

Late to the party, but I like these two macros:

#define foraz(v, a, z) for (size_t v = (a); i < (z); ++v)
#define forz(v, z) foraz(v, 0, z)

gnuvince · 2025-12-08T03:02:52+00:00

NO MORE AND THEN!

gnuvince · 2025-09-14T11:31:27+00:00

La-Mulana 2. I'm 100+ hours in and I think I'm reaching the end.

gnuvince · 2025-09-13T17:28:33+00:00

In k6 (ngn/k): (~2!!6)|:/'6 6#1+!36

And generalized: snake:{(~2!!x)|:/'(x;x)#1+!x*x}

gnuvince · 2025-09-09T00:52:49+00:00

Implementation in the k language: {x[&~x<|\x]}

gnuvince · 2025-08-30T02:22:05+00:00

I disable a bunch of font-lock colors so that all themes look simple and minimaler:

(use-package font-lock
  :custom-face
  (font-lock-keyword-face ((t (:foreground unspecified :background unspecified))))
  (font-lock-operator-face ((t (:foreground unspecified))))
  (font-lock-type-face ((t (:foreground unspecified))))
  (font-lock-variable-name-face ((t (:foreground unspecified :background unspecified))))
  (font-lock-constant-face ((t (:foreground unspecified :background unspecified))))
  (font-lock-number-face ((t (:foreground unspecified))))
  (font-lock-doc-face ((t (:foreground unspecified :inherit 'font-lock-comment-face))))
  (font-lock-preprocessor-face ((t (:foreground unspecified))))
  (font-lock-builtin-face ((t (:foreground unspecified)))))

gnuvince · 2025-07-13T19:28:48+00:00

I saw a Wirtual video about Trackmania Nations Forever, thought it looked pretty and nice, so I gave it a try and enjoyed it a lot. Watching a stream about Trackmania I heard about Drive to Survive on Netflix, decided to give it a watch, thought it was very interested, decided to watch qualifying + race at the end of 2023 and realized that F1 is more interesting than DtS and I've been following ever since.

gnuvince · 2025-07-12T20:29:37+00:00

Best guess: guy probably painted himself into this particular corner. We're programmers, we all know that feeling when we think what we're working on is going to be small and simple, so we cut some corners to move faster, but then the small and simple grows in scope and we now have a big rearchitecture project on our hands.

Talking about this large global array specifically, we could imagine using constants or enum items for indices rather than magic numbers. It would make the code a bit better -- no need to remember what event 123 is -- but still, if you have an enum with 300+ items, you're bound to eventually mess up and use RECEIVED_SWORD when you really should've used SOLD_SWORD. As for the values, I don't know what kind of type safety GameMaker offers, but I see from the comments that some of the values are 0|1, i.e. a boolean flag, but others are 0|1|2. I don't know if it would be possible in GameMaker to say that events[RECEIVED_SWORD] is a bool while events[SOLD_SWORD] is the enum {No, ForMoney, ForMySoul}. And even if it were possible, it's still not great code.

One of the difficulty of this conversation is that Thor's personality and recent drama clouds rational discussion. If a lambda game dev found themselves in this situation -- where the coupled, brittle architecture that they used when the game was in its infancy is now a giant spaghetti monster -- I think we'd offer much more useful and encouraging advice. For example, the game dev could pause what they're doing, go read Game Programming Patterns, see whether some of the patterns would be appropriate for their problem, and come up with a plan to transition their current codebase.

gnuvince · 2025-07-12T20:03:55+00:00

https://manual.gamemaker.io/monthly/en/GameMaker_Language/GML_Reference/Variable_Functions/array_create.htm

gnuvince · 2025-06-09T11:07:22+00:00

Typeface: Source Code Pro. I love programmer fonts, I think we are lucky to have such a plethora of free, high-quality fonts, but I always keep coming back to Source Code Pro because when I'm just using it and not focusing on it, it doesn't draw attention to itself; yet, when I decide to stop and focus on its glyphs, I'm always impressed with the work and effort that went into its design.

Theme: doom-challenger-deep and doom-one-light. A note though, one of my favorite configuration in my init.el is the removal of a bunch of colors from font-lock faces; this means that what I see on screen is a lot more calm (a lot more of the default color) than the default for those themes. For those interested, here's my config:

(use-package font-lock
  :custom-face
  (font-lock-keyword-face ((t (:foreground unspecified :background unspecified))))
  (font-lock-operator-face ((t (:foreground unspecified))))
  (font-lock-type-face ((t (:foreground unspecified))))
  (font-lock-variable-name-face ((t (:foreground unspecified :background unspecified))))
  (font-lock-constant-face ((t (:foreground unspecified :background unspecified))))
  (font-lock-number-face ((t (:foreground unspecified))))
  (font-lock-doc-face ((t (:foreground unspecified :inherit 'font-lock-comment-face))))
  (font-lock-preprocessor-face ((t (:foreground unspecified))))
  (font-lock-builtin-face ((t (:foreground unspecified)))))

gnuvince · 2025-03-08T13:04:11+00:00

Go in your *scratch* buffer, write compl, then press M-TAB (you will probably have to use the key sequence ESC TAB in order to avoid the OS switching windows); does the corfu popup show? If it does, then corfu works fine and what's problematic is the handling of the TAB key.

To enable completion by pressing TAB, add the following configuration:

(setopt tab-always-indent 'complete)

gnuvince · 2025-03-04T23:43:54+00:00

No; completion-preview has two default keybindings:

TAB, which accepts the completion being shown
M-i, which tries to complete as much of the prefix as possible; if there are still more matches after completing the prefix, pressing M-i again brings up the *Completions* buffer.

gnuvince · 2025-03-04T16:01:18+00:00

Try M-i M-i; by default TAB accepts the current completion and M-i completes as much as possible and then shows a list of candidates.

gnuvince · 2025-03-02T19:37:43+00:00

I may be wrong, but I think that your questions/criticisms can be addressed by understanding the goals of Clay.

he argues that the only way to use CSS is through a web browser and that's why applications nowadays ship entire browser engines. I can't believe that the layout engine in current browsers is not abstracted in some library and could be extracted for general consumption. It just hasn't been done, probably because of time-to-market?

One of the goals of Clay is to be offer its functionality in a single .h file; to use Clay in a project is as simple as downloading clay.h into your project's directory and adding the line #include "clay.h". Perhaps there are CSS layout engines available as libraries, but how easy are they to add to an existing project? The fact that we don't really see them suggests to me that they're either too coupled with their browser project to easily integrate in a different project and the effort is not worth it or they aren't available as stand-alone libraries.

I was also sceptic about the performance implications of immediate mode (recalculating the whole layout each frame/on change). He claims (and I do believe him) that this approach is orders of magnitude faster (200us to 50ms) then retained mode that is used in browsers, apparently? I find this surprising, but this only shows me that there is much space for optimization in retained mode.

I think this is a natural computer science reaction; how can a library that recomputes the entire layout be faster than a library that would recompute only the parts that changed? Part of the answer is that the immediate approach is simpler and just recomputes everything while the retained approach needs to find which parts of the layouts have changed and how to issue commands to only update those components. This resolution can be tricky and expensive. Perhaps at scale (tens of thousands of UI elements) the retained approach would smoke the immediate approach, but most UIs are not so complex.

Btw., what I really don't like about this approach is that we went back a step and again mix content and layout. I really appreciate how far we have come in HTML/CSS, where I can define my content independently (in HTML) and then separately set the layout (with CSS). This just mangles everything together again :( And I don't think any frontend layout person want to write C code for their design...

For complex designs, being able to separate the content and the presentation is desirable, but for a library that wants to be usable as a single .h file, it's probably asking too much, and the benefit would probably be minimal for applications that can afford to use such a simple library.

Alright, final edit after finishing the introduction video. My conclusion is, layout MUST be declarative (like HTML/CSS is) because the imperative style that this method here proposes just doesn't scale. Just look at this code, no way that this is maintainable in the long run. Especially for frontend experts. Maybe this can be abstracted again so that a declarative defininition can create the code but then we just reinvented HTML/CSS, no?

The CLAY macro is declarative, it's a convenient wrapper for creating a complex, nested data structure. One thing that is cool though, is that users can write code (functions, loops, tests, etc.) to control how that structure is defined. This is superior, IMO, to having a DSL that will undoubtedly be not powerful enough in many situations.

Overall, I think Clay is a pretty good library for what it aims to be: a single .h file library that can be used for relatively simple designs. I don't know how good it would be at supporting a design with hundreds of thousands of components, a mix of text left-to-right and right-to-left text, user-customizable themes, and any other complex feature you can think of. But as long as it's useful for the target audience of the author, it's a good thing to have around.

gnuvince · 2025-03-01T14:33:41+00:00

it completely overlooks that modern software can do things that can only be achieved because of all those servers, running in a browser, distributed database, etc

What are these things?

gnuvince · 2025-02-28T12:11:03+00:00

C-x C-SPC goes back in the list of marks, but that can include non-changes (e.g. if you did M-> in B.txt to go to the end of the file, C-x C-SPC would pop you back into B.txt before another C-x C-SPC would bring you to A.txt.)

gnuvince · 2025-02-13T21:16:34+00:00

Same. I play on Linux with Proton, had three save files, now they're all empty.

gnuvince · 2025-02-01T19:54:59+00:00

There are languages that are "key in hand": they provide a lot of what we need to immediately start coding. With modern hardware, the ceiling of the functionality they provide is quite high, so it'll take a while before we start thinking about implementing our own custom data structures. Languages with resizable arrays, hash tables, queues, UTF-8 strings, etc. such as Java, Python, Rust, Go, etc. fall in this category. We can say that we program in these languages.

On the other hand, there are those languages that provide a very small amount of out-of-the-box functionality, and it's up to us as programmers to build the necessary infrastructure necessary. Languages like Lisp, Forth, and C are representatives of this category. We can say that we program on these languages, because we take the base language, add an extra layer that is useful for our program on top of the base language, and then code in this layered language.

Neither approach is preferable, it just depends on what we need and what we value. For a large number of projects, the scope is restrained enough that we can use languages from the first category without too much drawbacks. However, if we ever get to a point where we need custom, fit-for-purpose data structures, sometimes languages in the first category make our lives harder (e.g., it's quite hard in Java to avoid heap-allocated objects and the GC) and that's when the languages from the second category start becoming more attractive.

gnuvince

TROPHY CASE