This is interesting, but I'm not convinced it's better than the python it's being compared to. Memorizing and understanding the behavior of functions that perform control flow seems no easier than memorizing and understanding hardcoded syntax/keywords. The additional flexibility of making everything a first-class citizen allows people to write code that is too clever for its own good. I could be wrong but I think there is a broad consensus that reflection is a Bad Idea.

Open to being convinced otherwise

(tangent but related, aren't the "Loops" and "Iteration" examples given for python literally the exact same syntax, with the exception of changing how the iterable is generated?)

▲ Nevermark a day ago | parent | next [-]

> I could be wrong but I think there is a broad consensus that reflection is a Bad Idea.

Reflection may be bad in practice for other reasons/conditions, but the lack of simple/minimal/regular primitive conventions in many languages, makes reflection a basket of baddies.

The code blocks of Rye seem comparable to closures, which is a sensible thing to have. Once all code blocks are closures, there are fewer concepts to wrangle, and functional control makes excellent sense.

	▲	hatthew a day ago \| parent [-]
		That makes sense, thanks!

▲ middayc a day ago | parent | prev | next [-]

It depends on what you want. If you want the most stabile and predictable way to specify the behavior, then static control structures have little downsides.

If you want to explore with how you can specify behaviors or rules and create new options or the ones tightly fitting your problem domain or mental model, then this gives you more tools to do so.

▲ hshdhdhehd a day ago | parent | prev [-]

I agree. In any somewhat functional language (I.e. all the mainstream ones) you can wrap "if" in a function if you please.

E.g.

    function funif (b, f) {
       return (b && f())
    }

If you want to do clever stuff. I never feel the need as I would rather abstract over bigger things.

▲ andriamanitra 21 hours ago | parent | next [-]

You may not want a fresh scope for control flow as you often want to use variables from the outer scope inside the if statement. Imagine you wanted to do something like this with your if statement implemented with a function (this is how the syntax would look like using a block argument in Ruby):

    state = "inactive"
    if_func(condition) {
        state = "active"
        activate_button.disabled = true
        deactivate_button.disabled = false
    }

In many languages you would need to wrap `state` in something that can be passed by reference, and make the function take multiple parameters. For example in JavaScript it would turn into something like this mess:

    let state = ["inactive"];
    if_func(condition, ({state, activate_button, deactivate_button}) => {
        state[0] = "active";
        activate_button.disabled = true;
        deactivate_button.disabled = false;
    }, {state, activate_button, deactivate_button});

▲ middayc a day ago | parent | prev [-]

You can do it, but that is not how the (default) control structures work in those languages. There is usually also some syntax cost.

	▲	hshdhdhehd a day ago \| parent [-]
		Thats a good point. Idiomatics are important and not following them makes incompatible code.