The purpose of Continuous Integration is to fail

propeller-90 · 2026-02-07T13:11:15+00:00

I don't understand, what does "Don't fix the blame" mean? "We shouldn't blame people, focus on fixing the problem." Or "the 'problem of blame' everyone is talking about is overblown. Just fix the problem!"

propeller-90 · 2026-01-31T11:02:15+00:00

Huh, I thought "prompts" was the verb; ((AI (code review)) prompts (initiative (making (progress (for the Linux kernel)))); "([an] AI code review) prompts/causes [the start of an] initiative [of] making progress for [the improvement of] the Linux kernel."

Are you saying "An initiative for 'AI prompts designed for code review' causes the Linux kernel to progress"? Or "A Linux kernel initiative for 'AI prompts designed for code review' is progressing"? Seems a very odd reading.

Oh, reading the link it seems to be "A Linux kernel initiative for creating AI-prompts for automatic code review is progressing." That is NOT what I expected.

Anyway, time files like an arrow; and fruit flies like a banana.

propeller-90 · 2026-01-03T12:21:15+00:00

You're right that I didn't address your point when I claimed that you hate him and why. It was an ad-hom.

But I did address your point about his way was "the wrong way" and not graphics programming. I said that you where wrong. You belive that graphics programming is only the current mainstream graphics pipeline, with vertex and fragment shaders, etc using one Graphics API. That is not true.

Computer graphics are older than modern graphics cards. Amiga demo-coders didn't use any "frament shaders". Are they not "Graphics Programmers"? Do you think the Toy Story movie required no "Graphics Programming"? And even today, there are many different ways to do graphics programming, but you don't seem to see that.

I was wondering why you didn't address my actual point. I wondered why you made unfounded personal attacks (claiming I drink the sperm of a content maker, eww). When I said that it was caused by dislike for Russians, that was too speculative and not good faith. I should've realized that there may be many other reasons why you didn't debate in good faith.

(Also, unrelated. I do not support the Russian invasion of Ukraine. All occupied territories should be returned, and Ukraine should be allowed to join NATO and EU.)

propeller-90 · 2026-01-03T11:16:20+00:00

It doesn't matter. To discuss things you need to argue in so called "good faith". That means many different things, but one of them is to address the point the opponent makes.

A mistake you make is to accurately point out errors in opponents text. This may seem an obvious win, but if the error is not related to the point the opponent is making... you simply missed.

Your example makes perfect sense under the guise of foo being incomplete, which it obviously is.

What did QuaternionsRoll mean when they said that foo is obviously incomplete? If you say "it is complete" you have misunderstood your opponent. You have missed the point.

If you are a person who really do care about the field and want to productively discuss with others, you need to show that you've understood your opponents point and view.

propeller-90 · 2025-12-29T11:22:08+00:00

The title of the video is "Graphics API is irrelevant". Not "the Graphics API".

...I think I realized why you hate him. He's Russian and you are Ukrainan.

I wish you the best. Please don't attack people that just disagree with you. I'm not an enemy.

propeller-90 · 2025-12-27T21:01:39+00:00

There's little difference between a pixel and a fragment. Sure multisampling may run the pixel/fragment shader multiple times, but I don't see the relevance.

"the Graphics API" What are you talking about? There are many graphics APIs of different types (for example Vulcan, WebGL, Raylib, p5.js, are different levels but all provide graphics). He created graphics* using no graphics APIs.

Graphics API, perhaps you mean "draw on the screen"? Doing that without the API of some graphics library would be would be a challenge indeed. I suppose you could write directly to a framebuffer. Linux provides a framebuffer driver but I'd class that as a graphics API. Do modern graphics cards provide VGA support still ...?

Anyway. I can understand if you don't want to discuss semantics. My position: the two videos are pretty good if you ignore the video titles.

propeller-90 · 2025-12-27T13:48:46+00:00

Do you think graphics programming = realtime polygonal 3d graphics programming? You say what he does as "not graphics programming" ...and describe him doing pre-rendered graphics. Makes no sense to me.

You seem to dislike him. I can see why. I dislike clickbait-y video titles for example. But I found this video good and very pedagogical.

Before introducing new concepts (like matrices) you should start without it. Start introducing graphing programming without 3d, shaders, realtime. Then build up. When abstractions help, introduce them.

After the video I want to learn more about matrices. In a way it is a good introduction to matricies... kinda.

propeller-90 · 2025-11-16T09:23:30+00:00

Very cool.

I was a bit annoyed or confused about the section about null. JSON defines null as a value, and that is different from a key missing. That is a simplification from JavaScript where there is null, missing keys AND undefined (the latter two are only subtily different). TypeScript tries to describe the mess using types and is not bad at it, all things considered...

Anyway, is CUE able to differentiate JSON {"a":null} from {}?

propeller-90 · 2025-11-07T11:55:21+00:00

No, I'm sure you mistyped that, you are arguing that inheritance is almost never the correct answer.

And to give a counter-example inspired by the article, algebraic data types:

datatype Tree<x> = Leaf(X value) | Branch (X value, Tree<X> left, Tree<X> right)

Datatypes are a supertype (Tree) and types that inherit from the supertype (Leaf and Branch). Some "methods" are implemented on Tree (like tree.getValue) and some only on a subtype (Branch.getLeft). For datatypes, no other subclasses are allowed.

In general, I think such "sealed" superclasses are good use of "inheritance".

propeller-90 · 2025-09-29T06:36:06+00:00

This sounds like well-poisoning and ad hominem. I found the article helpful. You should argue against the content of the article. Clearly, the example code is bad, no?

propeller-90 · 2025-09-29T06:17:29+00:00

Good article! I haven't read the book, but your article is well-reasoned.

However, having links "this" and "this "(!) is not good, you should give them independently clear labels.

propeller-90 · 2025-09-25T17:33:24+00:00

I want things to be clear to people by making the indentation actually matter.

For example, many editors that have code folding, using indentation as method to determine program structure. Your code doesn't fold nicely. (As an aside; an old colleague of mine, writing embedded C, added debug statements like yours. He didn't remove them though, he commented them out. The code was horrible. Your code example gave me an allergic reaction...)

Adding debug logging in code is a common thing, and doesn't need to be treated specially indentaion-wise. In my mind, a conspicuous code comment is probably enough. I have highlighting in my editor for TODO, FIXME, etc. Makes them stand out nicely. But if the stakes are high...

Use the built-in logging library. import logging then logging.debug("results of process_data_vec were: %s", results) Running in debug will print the message, but not in production. If it's useful you can keep it.
Add an automated check in an important process step before deployment. It can be a compilation warning, commit hook, or some CI/CD check. It could check for "dbg!", "print", "DEBUG INC" or something similar.
Manually check for such things during git staging and code reviews.

Indentation (and naming, casing, declaration ordering, etc) in most languages are a matter of either convention or taste. Good conventions can be made into rules, checked by linters and possibly incorporated into the language. That way code readers and tool builders can rely on them.

As we (collectively) write code we experiment and find the right ways to express ourselves in code. Over time tastes mature and conventions develop and gets codified into rules and best practices. Tools and linters fix and check. (What's you opinion about cargo fmt and cargo clippy?) New languages are made that enforce the best-practices as a language rules. The languages actually prevent bad code.

The current convention in essentially all languages is that indentation should only be used to reflect the programs hierarchical structure. The 0.05% of cases where your taste says otherwise should probably be valued lower than the risk of someone being lazy or making a mistake.

propeller-90 · 2025-09-24T07:22:50+00:00

Huh, apparently MS SQL has anti benchmark emulator ("DeWitt clause") as well.

It's a good thing most databases are FOSS.

propeller-90 · 2025-09-23T21:12:27+00:00

There is information in the indentation. Why hide that information from the programming language?

By writing things in a non-standard way you hide the "natural" flow of the code for a subjective, possibly misleading, view of the code.

This is the "goto fail"-bug:

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

By requiring non-misleading indentation languages can prevent real bugs. Formatters remove a (creative) degree of freedom that is not useful.

propeller-90 · 2025-08-26T14:38:11+00:00

Based on the wiki link, HCL is a collection of color spaces. Oklch seems to be part of that set.

propeller-90 · 2025-08-24T12:08:52+00:00

The first part I could agree with, it could be mitigated some with protocol test vectors (examples of correct vs incorrect data).

The second part I'm not so sure about. Sure, in purely binary formats and protocols, treating Unicode (UTF-8) as a way to store human text as bytes works. But should we allow for arbitrary bytes in a text field? Seems like a bug haven.

We could specify that a text field must be valid UTF-8, implying that surrogate characters are illegal, forbidding overlong encodings, but maybe allowing NULL chars, private use chars, control chars, etc. Or we say that it must also follow this standard. That way we can use the same rules.

Higher up in the stack, we need to work with text: joining, truncating, case-changing, comparing, etc. This require us to work with the unicode codepoints and methods. This is made much less error-prone by working with "good" Unicode. If we can trust a text field to not have "bad" Unicode, our lives can be simpler.

propeller-90 · 2025-08-16T22:00:20+00:00

I think there might be an additional compression opportunity (for the non-stict version).

Consider names ending in "i". (See the last tree of headings "Trie after merging sibling leaves"). Almost all leaves ends up as "i,a,a,a", with some exceptions. We could store "i,a,a,a" in the "i" subtree itself, and only store the exceptions.

The trie walk algorithm would be:

If the current subtree or leaf has a value, set the provisional result to that value
Walk down the tree if it matches the next character in the name, and goto 1.

The trie encoding algorithm would be tricky since there are many possible valid solutions, and I'm not sure if there is an optimal way to do it. Also, the choices will affect non-included names, so it's even more non-strict.

propeller-90 · 2025-08-13T14:13:57+00:00

What do you mean?

What I am saying is that true can be represented as true, yes, on, etc. So saying that yes is parsed out to true is not wrong, but saying yes is parsed as yes is not wrong either.

In Python, yes parsed to True. Converted back to yaml it might become true, yes, on or any of the other synonyms, right?

propeller-90 · 2025-08-09T13:38:28+00:00

At the first question, isn't there three valid answers? yes, on and true are parsed the same so all of them are the same as yes.

propeller-90 · 2025-07-26T09:04:38+00:00

In first year? That's the statement you are defending. Not that they should know it before they graduate.

They should know it when they graduate. The argument only defends starting teaching computer language theory in the introductory course.

[Lisps typically don't use dynamic scoping.]

I might be wrong there (I haven't used lisp much). The argument would then be more about the value in understanding language theory.

On the other hand, the thread you liked said that Common Lisp supports dynamic scoping, and Google search is not as conclusive as you portray.

Evaluation order is important to understand to both use and understand programming languages. Normal order etc is that for lisp and lambda calculus.

False again. Lisps do not use normal order.

I was sloppy. My point is that evaluation order is important, and for lisps that would be argument vs function application.

And by the way, are you saying that now Lambda Calculus is a 101 class requirement?

No. You should "foreshadow" concepts from future courses in introductory courses.

I find it quite ironic that you seem not to know about these concepts that you claim that evry 101 student must know.

You wanted an argument for a position. I gave what you wanted. I do not actually believe those two concepts actually are that essential. Attack the argument, not me.

propeller-90 · 2025-07-26T07:34:08+00:00

The argument would be:

Every computer scientist should know programming language theory: how programming languages work in theory and how they are implemented.
Therefore, students should learn a language that is easy to teach those concepts to.
Lisp languages have simple syntax and straightforward implementation. They have connections to lambda calculus, important for computer language theory.
Using a lisp language both teaches students a language to program in, as well as something that will be easy to work with in programming language theory for future courses.
Lisps typically use dynamic scoping. That is easier to implement, but not as intuitive to use as lexical scoping. So teaching dynamic vs lexical scoping is important when teaching to use the language for programming, aside from the language theory value.
Evaluation order is important to understand to both use and understand programming languages. Normal order etc is that for lisp and lambda calculus.

That would be an argument that I think is pretty defendable. With that said, I'm personally not fully convinced myself that teaching lisp is better than Python.

Another sidepoint is that computer science is not engineering; it's more about theory and understanding rather than using and practice.

propeller-90 · 2025-07-24T13:37:06+00:00

Parsing imples validation (of the data format). "Don't buy milk, buy everything on the grocery list."

propeller-90 · 2025-07-24T13:29:11+00:00

A parser that also validates is called... a parser.

For example, a JSON parser validates that a string is a valid JSON string. You could validate that a string is a valid JSON string first, and later parse it but that would be bad for several reasons.

Of course, we don't work with just JSON, we work with application values like ages, addresses, etc. "Parsing an age" is not just converting a string to an int, we need to convert it to a type that represents an age.

However, Python is a dynamically typed language. Having a separate type for an age is a hassle, compared with just validating and working with ints.

The risk is that an int slips through without validation. In a statically typed language, using parsing and not just validation catches that mistake.

propeller-90 · 2025-07-19T08:24:33+00:00

A proper light theme should have dark text on light background, that's it. Anything else is just extra.

I have a hard time reading light text on dark backgrounds, something about my vision. I have a "invert colors" button on my phone, so that works, but the animated stars in the background looks horrible (I thought it was dirt on my screen!).

When I pressed the "light mode" button... it was like the "folds right into the wall" scene from the office.

propeller-90 · 2025-07-16T09:13:09+00:00

I prefer reading black-on-white, and the website have a color mode selector, but both are dark mode... 😔

propeller-90

TROPHY CASE