While the author claims "semantics beat syntax every day of the week," the entire article focuses on syntax preferences rather than semantic differences. Pipelining can become hard to debug when chains get very long. The author doesn't address how hard it can be to identify which step in a long chain caused an error. They do make fun of Python, however. But don't say much about why they don't like it other than showi…
Pipelining might be my favorite programming language feature
11–20 of 360 posts
Re: Pipelining might be my favorite programming language feature
#12While the author claims "semantics beat syntax every day of the week," the entire article focuses on syntax preferences rather than semantic differences. Pipelining can become hard to debug when chains get very long. The author doesn't address how hard it can be to identify which step in a long chain caused an error. They do make fun of Python, however. But don't say much about why they don't like it other than showi…
Yeah, I agree that this can be problem when you lean heavily into monadic handling (i.e. you have fallible operations and then pipe the error or null all the way through, losing the information of where it came from).
But that doesn't have much to do with the article: You have the same problem with non-pipelined functional code. (And in either case, I think that it's not that big of a problem in practice.)
> The author uses examples that function very differently.
Yeah, this is addressed in one of the later sections. Imo, having a unified word for such a convenience feature (no matter how it's implemented) is better than thinking of these features as completely separate.
Re: Pipelining might be my favorite programming language feature
#13Re: Pipelining might be my favorite programming language feature
#14While the author claims "semantics beat syntax every day of the week," the entire article focuses on syntax preferences rather than semantic differences. Pipelining can become hard to debug when chains get very long. The author doesn't address how hard it can be to identify which step in a long chain caused an error. They do make fun of Python, however. But don't say much about why they don't like it other than showi…
>Let me make it very clear: This is [not an] article it's a hot take about syntax. In practice, semantics beat syntax every day of the week. In other words, don’t take it too seriously.
Re: Pipelining might be my favorite programming language feature
#15This is why I love Scala so much
Re: Pipelining might be my favorite programming language feature
#16This is why I love Scala so much
Re: Pipelining might be my favorite programming language feature
#17The tidyverse folks in R have been using that for a while: https://magrittr.tidyverse.org/reference/pipe.html
Re: Pipelining might be my favorite programming language feature
#18Pipelining can guide one to write a bit cleaner code, viewing steps of computation as such, and not as modifications of global state. It forces one to make each step return a result, write proper functions. I like proper pipelining a lot.
Re: Pipelining might be my favorite programming language feature
#19 data.iter()
.filter(|w| w.alive)
.map(|w| w.id)
.collect()
collect(map(filter(iter(data), |w| w.alive), |w| w.id))
The second approach is open for extension - it allows you to write new functions on old datatypes.> Quick challenge for the curious Rustacean, can you explain why we cannot rewrite the above code like this, even if we import all of the symbols?
Probably for lack of
> weird operators like , , $, or >>=
Re: Pipelining might be my favorite programming language feature
#20To one up this: Of course it is even better, if your language allows you to implement proper pipelining with implicit argument passing by yourself. Then the standard language does not need to provide it and assign meaning to some symbols for pipelining. You can decide for yourself what symbols are used and what you find intuitive. Pipelining can guide one to write a bit cleaner code, viewing steps of computation as s…
i mean this sounds fun
but tbh it also sounds like it'd result in my colleague Carl defining an utterly bespoke DSL in the language, and using it to write the worst spaghetti code the world has ever seen, leaving the code base an unreadable mess full of sharp edges and implicit behavior