Reducing Assumptions, Exploding Your Code

https://ryelang.org/blog/posts/reducing_assumptions_but_exploding/

by mpweiher • 18 days ago

30 10 18 days ago

ryelang.org

middayc5• 18 days ago

I'm the author. If anyone has any feedback, you are welcome ...

broken-kebab• 17 days ago

The idea looks elegant!

The only thing so far which feels not fully fitting is that dot and pipe are often semantically equivalent - applying function to the output of the previous one. And yet you still need to pick the right one.

E.g. Clojure (which is too hosted over OOP language) treats dot as an indicator that it's a method, but invocation/application follows the same syntax as any fn:

(.method (function arg))

Meanwhile in Rye:

"12 8 12 16 8 6" .load .unique .sum

when unique and sum are from underlying Golang, but if I made them myself it suddenly has to be:

12 8 12 16 8 6" .load | unique | sum

middayc5• 17 days ago

Thanks! But words with dots vs. Pipes dont work that way.

All functions, user level or builtins (written in Go) (or generic methods that dispatch on the Kind of first arg) have exactly the same calling conventions/rules. Dot vs pipe is a matter of evaluation priority, that works the same on all of them.

In fact there are more word types in that "game", words, dotwords, opwords and pipewords :) look here for more: https://ryelang.org/meet_rye/specifics/opwords/

tananan• 17 days ago

I generally work on internal-use Python codebases. I would much rather do some basic validation and fail loudly if anything I didn’t account for happens.

One of the issues I run into is that agents are predisposed to write extremely defensive, odd-case-handling code, and that makes me recoil when I have to look into it: the SNR ratio is very low. You get a spaghetti that is unlikely to crash, but really hard to extract the gist of. And finding more global bugs can be difficult because what should be structural impossibilities can be coerced into silent skips.

The article made me think that maybe what I’d like is a language where validation doesn’t triple the lines of code you have to write.

middayc5• 17 days ago

I agree, if you don't have a clear view on what you want to do on certain exception, or you are adding information or translating/wrapping error into a higher level one, then it can be cleaner to let program fail naturally in that specific case. Catch, print error and panic makes no sense in many cases and can make the exception less clear when it happens.

gumby• 17 days ago

…agents are predisposed to write extremely defensive, odd-case-handling code… the SNR ratio is very low. You get a spaghetti that is unlikely to crash, but really hard to extract the gist of. And finding more global bugs can be difficult because what should be structural impossibilities can be coerced into silent skips.

Have you tried asking for a summary of the logic being relied on, and asking LLM to simplify the code?

I’m 85% joking, of course, given the current state of automated code generation and the terrible summaries you usually when asking for a summary of text. But in theory that’s what they are supposed to do.

mike_hock2• 17 days ago

Yeah, or just let the exceptions bubble up and the boilerplate goes away.

middayc5• 17 days ago

But sometimes you must act on exceptional situations, recover, take alternative route, provide default, or translate exception from lower level one to a higher level one. From cause based to more intent based. Err, file not found setup.txt -> Couldn't read your setup -> ...

Which its great if this also doesn't loose lower level information, but just wraps it, so end user could dig into the error.

mike_hock2• 17 days ago

But sometimes you must act on exceptional situations, recover, take alternative route, provide default

And then the Rye version is presumably just as verbose.

or translate exception from lower level one to a higher level one

This is the actual flaw in exception-based languages. Adding context should be much more convenient.

Reducing Assumptions, Exploding Your Code

Related Stories