zupa-hu

I'm wondering what wavelengths our monitors / phones have. I always thought of flux (the app) that it is reducing blue light. But keeping the red part may be just as important.

For anyone interested, here is a short vid on how to color your iphone screen red: https://www.youtube.com/watch?v=omuGVs7eP-A

Thanks for clarifying, based on the title I totally thought the study was about critical thinking in general.

For the record, I’m not going to read the article to verify your statement.

Oh wow you can also use this for contract diffing when signing in person!

Interesting. You have a bug in the name of your language. :)

Same here.

Consider updating your vocabulary because the term is often used for both.

Note that rendering to the “screen” really means writing bits at a memory range, which is just one interface for displaying things. Html is another, higher level interface these days.

My partner is an orthodontist. (That’s a specialization within dentistry.) I’m a software engineer btw.

The saying goes that you only need to floss the teeth you want to keep.

If you think about it, a toothbrush will only clean 3 sides of a tooth. Top, outer side, inner side. Not the 2 sides facing neighbour teeth.

How on earth is it very important to clean those 3 sides but not the remaining 2? That just doesn’t make sense. If you think flossing is not useful, to be coherent, you must believe toothbrushing is not useful.

On the flip side, learn how to do flossing right to not hurt your gums. The floss must follow the shape of the tooth, and not be straight. (Ie. move along a U path.) Flossing in a straight line does more harm then good.

Hey, thank you so much for Pager! It helped me a lot (in supporting my own free users on Reddit)! I was often wondering how long it will remain free. Well, forever.

<3

had such a good laugh, I’m going to steal that :)

Thanks, that's great to hear!

Hi, author here. If you want to play with the language try the language docs that includes executable playgrounds: https://lang.boomla.app/types/boolean

As I understand Swift's error handling falls straight into the explicit camp. That's all good and I love it.

My problem is that it seems it's not for everyone at every stage of their journey. When I teach software development to a musician, it's just in the way. I needed a language that works for professional developers doing low-level work, but also for citizen developers doing their first round of hacking.

Originally, I thought implicit error handling is not for me. I will add support for those who hate explicit error handling and not use it myself. I'm at a point in my journey where I started questioning the benefits of explicit error checks (ie. Swift's try keyword or ? in Boomla) when all I do is propagate errors.

I'm thinking that maybe it would be interesting to start with implicit error handling, and turn on explicitness where you need it. Existing error handling approaches don't let you do that. I see the big idea in this approach that you can turn it on incrementally, with no far reaching effects. How you handle errors is a local implementation detail of the function.

Of course we will see, I might end up sticking to the explicit model, but for now I enjoy it. Luckily, migration won't be an issue, I can just return to using explicit error handling if I change my mind, and current code will keep working as is.

Thanks for the link!

So the error type can be left out when the compiler can infer it. If it is left out, and the compiler can't infer it, Zig will fail to compile and provide an error message pointing to the missing error type information. Thanks for the clarification, this totally makes sense.

> That seems like it'd work without being problematic like Java's exceptions.

It's definitely a _huge_ improvement. I think the usecase with returning different errors is significant when you are mixing lots of 3rd party components.

I'm building a platform, which defines several interfaces that components must implement, so I believe those intefaces would "erase" the concrete error types and everything would just end up being anyerror. That said, I could still see concrete error types still being used in some lower level logic, where function calls don't cross such an interface boundary.

As for projects that don't bother with implementing 3rd party interfaces, I can totally see how that may be a blessing.

The problem is that making function signature errors optional effectively "colors" all the functions. If I want to write a function with errors in the signature, then what if I call a function that doesn't have the error in the signature? In the presence of dynamic dispatch (ie. interfaces), the compiler can't infer the errors. Thus errors in function signatures can be required or not, but they can not be optional.

(Please point out any of my mistakes.)

(Author) Thanks for the Zig examples, great comparison! I'm puzzled how Zig can do exhaustiveness checks in the presence of interfaces (dynamic dispatch). A quick google search suggested Zig may not have them?

The problem is, having dynamic dispatch, I would think the resulting error types can not be inferred, which means they must be explicit in function signatures. As a result, we are back to Java checked exceptions with its refactoring hell.

So that seems to be a hard tradeoff. Or please correct me.

Just for clarification, Go/Boomla errors can also have dedicated types, so you don't need to compare error strings. Yet it is correct that you can not tell if you have exactly covered all possibilities.

(Author) Thanks indeed checked exceptions have been brought to my attention in this thread, and in theory they are indeed very similar, except I understand changing the type of a checked exception causes refactoring hell, so they are painful to use in practice.

The other aspect is ergonomics. A major problem I have with try..catch blocks that the article doesn't touch on is that they created nested blocks, with their own scopes. This either results in nesting hell, or the variables that are assigned inside the try block must also be defined outside the try block. This makes the code simply unpleasant to write.

(Author here) Yes, that's correct. It's an algebraic effect elevated to a dedicated language feature.

The benefit is that it is simpler than having full-blown algebraic effects, both to learn and to actually use. Probably not for you, but for most people, and definitely for the non-professional developer kind.

> I don't think you can lump Java with the others in this comparison

Fair point, I've removed Java from the examples. Apologies, I haven't used Java for ages and relied on my memories. That said, I understand they are not used much in practice because changing a checked exception's type is a refactoring nightmare. Or are they?

> Also I really dislike phrases like this [...]

Okay, help me do better, what about citizen developers? I mean the kind of person who explicitly never wants to be a developer, yet there s/he is developing a program. I called them novice in this page, and the people I have in mind would not be offended at all.

And yes, compared to them, someone with a computer science background and 10 years of coding experience is a seasoned developer. Open to suggestions.

It didn't exist originally, but for high level programs like a TODO app that is mostly html templates, those question marks really don't add much value. Plus every time I showed code snippets to web developers, they got hung op on them.

Also, I wrote Go for like a decade, I love the explicitness of Go's error handling, but I still hate the `if err != nil {...}` checks.

Another reason was that Boomla will have a complete nocode UI, and I really don't want to clutter it up with explicit error handling.

That said, it's still an experiment, I guess.

Author here, thanks for the comment, it is indeed a hard compiler error not a warning. Bad wording.

It is a fair point too about new developers / seasoned developers. Maybe citizen developers is a better phrase? I've encountered many non-professional developers who just hack together things and really couldn't stand verbose error handling. And for what they do, frankly, I don't blame them. I'm also fine writing bash scripts without a decent type system.

Thanks for the long answer. Okay, it's good you have thought it through. Will be interesting to see how it evolves.

I enjoyed the thoughtful article.

It's interesting that type checking happens at runtime so there is no compile time, only runtime. It seems this would make it acceptable. But I wonder if the assumption will always hold.

The assumption:

> The program doesn’t even have any inputs: all parameters are “hard-coded” into it. [1]

Will that always hold? What about environment variables? If the language ever needs to handle parameters, this assumption breaks and thus compile time and runtime will be separated.

Other languages like Go would force you to insert type assertion which is the same thing just explicit. I forces you to "approve" what's happening, and that's a good thing.

There is the saying that every configuration language will eventually evolve into a full blown programming language. I guess it's all about the real world proving the underlying assumptions to be incorrect.

[1] - https://ruudvanasseldonk.com/2024/a-type-system-for-rcl-part...

Do you have a better idea?

The problem is there are not 100 tools out there but literally infinite, in the sense that one could not learn them all simply because new ones are created faster.

Given that, the article does have an implied filter criteria that goes unsaid, even though it says otherwise.

Indeed.

The problem is the cost of doing this. If it gets overturned, the defendant shouldn’t be the one to bear the cost. I’d be happy with either 1) the patent owner or 2) the patent office, who didn’t do its job properly.

So to paraphrase, the problem is around context passing between threads, which makes sense.

Sounds like that could be solved by a language surfacing the context at thread boundaries like the `go` statement, possibly channels.

Thanks for the answer!

> Thread-local storage is bad because it's implicit and causes bugs when used with concurrency; if you farm out some work to another goroutine, it will break.

Can you elaborate on why being implicit is bad and how it causes bugs?

I understand that shared data (via pointers) may cause race conditions and other unexpected behavior, so let's say we require that the thread-local storage can only store values (with value semantics).

If you could point out any issues with that, I'd greatly appreciate it.

Great post, love reading these.

I noticed the author mentions implicit context argument passing in Odin. I looked into it, and as I understand it is for language related use only - memory management, etc.

I'm looking for inspiration in this regard as I'm working on a language. I'm familiar with Go-s context passing and aware of Java's thread locals. Can you recommend other any languages with different approaches that I should look into?