Secretly, all code wants to be spaghetti. You and your team have to put a conscious effort into prevent that from happening. Degrading the core of the language like this is like inoculating your homebrew with sewage and expecting it not to go wrong.
When if is just a function
71–80 of 111 posts
Re: When if is just a function
#72Just here to point out that the actor’s name is Bob Odenkirk not Odendirk. In a statically typed language this would be an error at compile time not hacker news comment time.
Re: When if is just a function
#73Earlier quoted context omitted.
This criticism seems at face value to also apply to first-class functions, which I thought was a totally uncontroversial pattern. Do you dislike those too?
First-class functions are problematic too[1], but function is always a definition. While code block is usually meant to be executed right away. [1]: https://github.com/ziglang/zig/issues/1048
Re: When if is just a function
#74For lambda calculus, the motto is "when everything is a function". The boolean true is the function λx.λy.x, while false is λx.λy.y. If b then x else y then simply becomes b x y. In a functional language like Haskell that is basically a typed lambda calculus with lots of syntactic sugar, we can replicate this with: type MyBool a = a -> a -> a myTrue :: MyBool a myTrue = \x y -> x myFalse :: MyBool a myFalse = \x y ->…
yourIf == myId
No instance for (Eq (MyBool a0 -> a0 -> a0 -> a0))
arising from a use of ‘==’
Undecidability of function equality aside, we could indeed define "myIf = id" instead.Re: When if is just a function
#75Re: When if is just a function
#76The Trade-offs section doesn't list the biggest one. Secretly, all code wants to be spaghetti. You and your team have to put a conscious effort into prevent that from happening. Degrading the core of the language like this is like inoculating your homebrew with sewage and expecting it not to go wrong.
I never programmed in a team, so my experience of programming is probably very different from yours. You probably want something like electric cattle fencing (if I borrow your juicy language) for your team, but if I program for my self I just want an open field of Rye I can explore :)
Re: When if is just a function
#77The apply* ?thing is kinda hard to parse, would turn me off seeing lots of that in a codebase.
I can break it down for you, but yes ... it's quite specific, I was trying to apply an `if` which is not something I needed to do or would look to do so far. The point is that you can also apply all "control structure like" functions, like any other function - consistency, not that this is advised or often used.
?word is a get word. `x: inc 10` evaluates inc function, so x is 11, but `x: ?inc` returns the inc function, so x is the builtin function.
apply is a function that applies a function to a block of arguments. It's usefull when you want to be creative, but it's not really used in run of the mill code.
.apply (op-word of apply) takes first argument from the left. `?print .apply [ "Hello" ]`
Here we needed to take second argument from the left and this is what a * modifier at the end of the op- or pipe-word does. `[ "hello" ] .apply* ?print`
You asked for it :P
Re: When if is just a function
#78Earlier quoted context omitted.
> You might wonder: “Won’t the block execute immediately when passed as an argument?” Here’s the key insight: in Rye, code blocks { ... } are values. They don’t evaluate until you explicitly tell them to.
You're correct, that is lazy evaluation. The entire article talks about lazy evaluation without mentioning it, which was my point
Blocks are not evaluated by default, but they are eagerly evaluated if the function that accepts it decides to do so (if, do, loop) ... I understand lazy evaluation more like something that is meant to be evaluated, but physically only gets evaluated when or if you do need the result, which I'm not sure is entirely the same.
Re: When if is just a function
#79Re: When if is just a function
#80When everything is an expression, like rust (I think), that's enough. Most of the control flow are used as statements, but if needed, they can be used directly as expression, and you get basically all the advantages. After seeing how effective this is, using a language that doesn't have this feature can be really annoying. On the other hand, I would like to explore "when arithmetics is just a function". I think Elm d…
12 + 23 ; is technically
12 ._+ 23 ; or not using op-word is
_+ 12 23 ; or if we bind function _+ to add
add: ?_+ ; we get
12 .add 23 ; and
add 12 23
It has downside because op-words don't behave exactly as math expressions would, but you can use parenthesis and we have a math dialect which includes full math precedence rules. math { 12 * 2 + 23 * 3 }