Microsoft acquired GitHub way before LLMs existed.

That’s called immediately mode gui (or imgui). It has nothing to do with think about elements or pixels. You do have elements, it’s just that they’re rendered directly (immediately) instead of stored.

You have a panel+border+text “primitive” drawing functions. Nothing is stopping you from creating a single function that calls all 3 of those. You probably should, since it’s probably a common pattern. You could call it DrawBoxedText. There is no difference between a DrawBoxedText function and a BoxedText element with a draw() method.

The first problem is a you problem though. There’s nothing stopping you from dividing your global god-class into smaller ones. For example, you can have one state struct per windows. So windows wouldn’t have access to the state of other windows.

The second problem is also the reason I don’t often use imgui. Imgui is great for introducing UI to applications that would re-render every frame, like a video game. But for every other application, it feels like a waste. If I wanted to waste resources I would write it in python or JavaScript.

Not saying that named parameters are bad, but the builder pattern serves the same purpose and imo it’s more ergonomic.

TrainBuilder::new()
  .with_electric_motor(true)
  .with_width(1.0)
  .build()

I don’t care about the color of the train or the amount of wheels, I just want the default train with a few changed parameters.

If you do named parameters in rust, you would need to set every parameter. The only way to not set every parameter is to give a special meaning to the Default trait. But that is uncommon to happen in rust. And many structs that could easily derive Default don’t.

As long as I know the answer, you can ask whatever you want.

Product specifications are different for the parts accessible to a user and the parts not accessible to the user.

If you tell a user “you can take it apart” the user will believe the product was made with taking it apart in mind. But it was not.

For example, a toy that is made to be taken apart, like legos, will survive it being taking apart thousands of times. But an electronic device that was made to take it apart only for repair purposes may last only tens of cycles.

So if a user disassembles their controller 100 times, a part will probably break, and the user will complain about it being such bad quality that it broke after taking it apart “a few times”.

That’s why it is important to disclose what you are MEANT to do as opposed to what you technically CAN do.

How can our DNA be “complex” when it is 9X% of the DNA of a banana?

That claim doesn’t make sense to me

Lots of talk about the problems of implicit conversions. Which is known, and is the reason that rust does not have implicit conversions. But when it came to the heart of the article, the explanation of why unsigned is bad for sizes, it’s just:

• One example about wrapping in ring buffers.
• Saying “in the 90s there were a lot of problems”.
• The lower boundary “0” being near “normal” numbers.

I can see how you can think the 3rd one is an issue. But then the answer should be the java one of just removing unsigned. Since that issue is not exclusive to sizes, every unsigned use case has it.

It seems like the real problem here is having implicit conversions.

Many tourist destinations are popular due to their architecture and monuments. Ghost towns don’t make big monuments and cathedrals.

Spanish from Spain has an official dictionary that dictates what is correct and isn’t. You can’t be more prescriptive than that. Sure, that dictionary adds words based on usage, even ones that are clear misspellings of the “real” word, but they are marked as so.

Some people are just elitist.

“Ew? You use the GUI? I’m way better since I do that from the terminal”.

But since the terminal has a shit UI, they do all sort of things for it to resemble a GUI more. So they can have the convenience of a GUI while not hurting their pride.

I’m not looking to argue about the importance of my points. I wouldn’t have listed so many in that case.

The point I’m trying to make is that this is a very incomplete article, as it doesn’t seem that much thought was put on the downsides.

A good article would’ve considered every angle. And so would probably conclude (if it had a conclusion) that the premise is incorrect, and the world of language design is more nuanced than “having both modifiers and annotations is bad language design”.

And at that point, the article would’ve probably ended up being: when should annotations be used instead of modifiers?

Many of the most popular languages have both modifiers and annotations:

• Java
• Rust
• Python *Javascript

C doesn’t have both because it doesn’t even have annotations. Idk about C++, but it either doesn’t have annotations (like C) or it should be in the list above

All of those have been heavily criticized from a language design PoV. And I’ve never seen anyone complain about this. People genuinely don’t believe this to be an issue.

The closest is public static int main() for java. But making them annotations would not fix that, only rearrange the issue vertically.

I did not intend to sound angry. I was trying to do an honest review of this article. Since I did not consider it good at all.

What a way to validate OP by completely misreading what he said.

What is this article? There is no author, and it is written as if it were an objective truth when it is clearly subjective.

There is no conclusion, it’s just an introduction paragraph that says “do this, this is good design”, followed by a pro-con analysis, and then the article just ends. Given that it has real drawbacks, you would think it would be more nuanced than “do this, this is good design”.

Furthermore the analysis is not even complete. The only 2 drawbacks mentioned only affecting the developer of the language. And ignoring more obvious drawbacks that would affect the users of the language:

• Aesthetics. Annotations are just uglier than modifiers. Due to their special syntax instead of just a naked keyword.
• Annotations take up more space. Screen space is valuable, annotations usually are stacked vertically, which takes up a lot of vertical screen space. This is in order to mitigate their use of horizontal screen space by their syntax.
• Disorder. Annotations are not ordered, which means they are harder to parse by a human. And if there is a wall of annotations, a human might miss an important one because it is surrounded by others that are just boilerplate.
• “Downgrading” modifiers to annotations removes their perceived importance. Modifiers modify the class/function/whatever, annotations add to it. Usually, you can ignore annotations and just look at the modifiers. If modifiers are annotations, you have to read the annotations to filter which ones are important to you and which aren’t. Which is harder to do due to the previous point “Disorder”.
• If annotations were objectively better than modifiers, the logical conclusion would be “your language should not have modifiers, do annotations instead” instead of “if your language has both, remove modifiers”.
• Namespacing is not objectively better. I don’t want to import “public” in every single file. It’s just useless boilerplate at that point. And some dependency might export their own “public”. Or even worse, a non-annotation (function, class) named “public”. If reserving keywords for modifiers is a concern, you can just prepend the uncommon ones with “__”. Nobody is going to complain that they can’t use the name “__readonly” because it’s reserved.
• Variable declarations do have modifiers too (for example “const” in C). Annotations are awful for variable declarations. See the point about screen space. Same for closures or code blocks.

You have still not answered the question: what’s the lie?

Headline: says something. (That is obviously not true and just clickbaiting)

Instant disclaimer: the headline is not good, it should be instead “don’t do this other thing”.

Later in the article: how do we avoid doing the thing I told you not to do? By doing what I told you not to do.

The dude may be correct (idk, haven’t bothered reading the rest of the article), but he doesn’t know how to write/communicate. I don’t believe he’s respecting my time. Just tell in the title what you actually want to talk about.

Inline comments yes.

Function/Class/Module doc comments should absolutely explain “what”.

Investments are not effort-to-profit. They are risk-to-profit.

There is no such a thing as risk-free investing. If there is an investment with good returns, it means it’s just as easy to lose all that money.