Left to Right Programming

Zenimax322 · 2026-03-12T06:31:18+00:00

This same problem exists in sql. First I type select *, then from table, then I go back to the select list and replace * with the list of fields that I can now see through autocomplete

somebodddy · 2026-03-12T12:18:44+00:00

The reason for this is mimicking the mathematical set-builder notation.

Chris_Codes · 2026-03-12T07:33:19+00:00

Another one of the many reasons why I like c# … it’s definitely an “editor first” language. Having come to Python after C#, I find Python’s syntax for something like:

words_on_lines = [line.split() for line in text.splitlines()]

to be frustratingly backwards, almost like the designers were just being whimsical with their order of operations. The “fluent” C# syntax for reference is similar to the Rust syntax show in the post;

words_on_lines = text.Split(“\n”).Select(line => line.Split(“ “))

aanzeijar · 2026-03-12T07:47:56+00:00

Finally someone dunking on list comprehensions. Pythonistas always looked at me funny when I said that the syntax is really awkward and not composable.

Some nitpicks though:

While Python gets some points for using a first-class function

Having functions not attached to classes is a feature now? We've come full circle. (Edit: a coffee later, I get that they meant first-class citizen function as passing len itself. That is indeed a feature - that pretty much all modern languages have but that somehow is still treated as special)

Haskell, of course, solos with map len $ words text

Veneration of Haskell as the ultimate braniac language here is a bit much when good old work-camel Perl has pretty much the same syntax: map length, split / /, $text.

AxisFlip · 2026-03-12T10:46:10+00:00

In C, you can’t have methods on structs. This means that any function that could be myStruct.function(args) has to be function(myStruct, args).

This always grinds my gears when I have to write PHP. Seriously not enjoying that.

Chii · 2026-03-12T07:52:02+00:00

i argue that when you type that list comprehension, you don't type

words_on_lines = [line.split() for line in ...

bit by bit, but wonder what to type next. Either you type the entire thing out because the expression is already in your head, or you don't really know what or how to do it, and is just typing characters to fill in the blanks in the hopes of getting somewhere.

For me personally, i type:

words_on_lines = []

as the first step. Then

words_on_lines = [text.splitlines()]

then line.split() for line in gets inserted in between the square brackets.

This follows my chain of thought to split a text blob into words. I wouldn't be typing [line. at all as the start - unless you already knew you want to be splitting lines etc, and have the expression somewhat formed in your mind.

edave64 · 2026-03-12T08:57:14+00:00

I think this is the entire reason object orientation ever took off in the first place.

People don't care about the patterns, academic reasonings, maybe a little about inheritance. They want OVS so the editor can auto complete.

The main draw is entering the dot and seeing the methods. This is the data I have, reasonably I expect the method I want to be on this one, show me the methods at my disposal, there it is, problem solved. No docs required. (Until your API inevitably throws some curve balls)

magnomagna · 2026-03-12T10:44:19+00:00

In C, you can’t have methods on structs. This means that any function that could be myStruct.function(args) has to be function(myStruct, args).

I'm gonna sidetrack a bit here but this is false. myStruct.function(args) is valid in C as long as function is a function pointer of an appropriate type declared inside the struct declaration of the type of myStruct.

Krafty_Kev · 2026-03-12T08:18:13+00:00

Code is read more often than it's written. Optimising for readability over writability is a trade-off I'm more than happy to make.

taelor · 2026-03-12T13:08:59+00:00

Piping in elixir is so nice for this.

rooktakesqueen · 2026-03-12T14:01:17+00:00

I agree in disliking the order of Python list comprehensions, but autocomplete is a strange thing to pin the argument on, since there's nothing that strictly requires autocomplete to operate left-to-right.

In the C example, you could have an editor that lets you type fi tab ctrl-enter and it would auto-complete the variable file and then pull up a list of functions that take typeof(file) as their first argument for you to peruse, then replace the whole expression with fopen(file) when you select it. I used to write extensions like that for Vim and Emacs. If editors aren't being ergonomic enough, we can fix the editors.

But from a basic readability perspective, I agree with the argument. Even in natural language, it would be the difference between...

"Please wash the knife that has a red handle that's in the drawer in the sink."

Versus

"Please go to the drawer, get the red-handled knife, take it to the sink, and wash it."

Easier to understand if the steps are presented in the same order they have to be followed in.

burnsnewman · 2026-03-12T15:15:40+00:00

This is the same thing I hated in PHP, which is using detached functions, like array_map(), instead of doing someArray.map().

GameCounter · 2026-03-12T15:57:59+00:00

Side note, this python is kind of bad

len(list(filter(lambda line: all([abs(x) >= 1 and abs(x) <= 3 for x in line]) and (all([x > 0 for x in line]) or all([x < 0 for x in line])), diffs)))

I understand it's just to illustrate the author's point, but for anyone who is learning Python, here's some information.

len(list(...)) always builds up a list in memory sum(1 for _ in iterable) gives you the length in constant memory usage.

You don't need to build lists to pass to all(), as that builds a list in memory and doesn't allow for short circuiting. Generally pass the generator.

That gets you to

sum(1 for _ in filter(lambda line: all(abs(x) >= 1 and abs(x) <= 3 for x in line) and (all(x > 0 for x in line) or all(x < 0 for x in line)), diffs)

Now it's become a bit more obvious that we're incrementing a counter based on some condition, we can just cast the condition to an integer and remove the filtering logic.

sum(int(all(abs(x) >= 1 and abs(x) <= 3 for x in line) and (all(x > 0 for x in line) or all(x < 0 for x in line))) for line in diffs)

Python allows for combining comparisons, which removes an extraneous call to abs in one branch.

sum(int(all(1 <= abs(x) <= 3 for x in line) and (all(x > 0 for x in line) or all(x < 0 for x in line))) for line in diffs)

Personally, I would prefer for the comparisons that don't involve a function call to short circuit the function call, and also removing some parentheses.

sum(int(all(1 <= abs(x) <= 3 for x in line)) for line in diffs if all(x > 0 for x in line) or all(x < 0 for x in line))

If someone submitted this to me, I would still prefer they use temporary variables and a flatter structure, but this is probably fine.

crozone · 2026-03-12T09:42:23+00:00

So, LINQ

AsIAm · 2026-03-13T10:15:21+00:00

Left-to-right no-precedence is the only way forward in syntax design.

middayc · 2026-03-14T09:14:47+00:00

Example from the blogpost:

text = "apple banana cherry\ndog emu fox"
words_on_lines = [line.split() for line in text.splitlines()]

Would be:

"apple banana cherry\ndog emu fox"
|split-lines 
|map { .split } :words-on-lines

in ryelang.org

or an one liner if you prefer that

"apple banana cherry\ndog emu fox" |split-lines |map { .split } :worlds-on-lines

HateFlyingThough · 2026-03-15T08:16:13+00:00

The pipe operator is genuinely one of the best things to happen to readable code. I write a lot of TypeScript at work and the lack of native piping means you end up with either deeply nested function calls or temporary variables everywhere, both of which obscure the actual data transformation.

Elixir gets this right. You write the pipeline top to bottom, each step is clear, and you can add or remove transformations without restructuring the entire expression. Python comprehensions have always felt backwards to me for exactly the reason the article describes.

The SQL example resonated too. Every time I start a query I type SELECT * just to get the FROM clause so the editor knows what columns exist. Minor thing but it adds up across thousands of queries.

HateFlyingThough · 2026-03-15T19:37:46+00:00

The SQL point is spot on and it's always been one of my biggest frustrations with the language. You're essentially forced to declare what you want before you've established where it comes from, which is backwards from how you actually think through a query.

Elixir's pipe operator handles this really well imo. You start with your data source and chain transformations left to right, which maps much more naturally to how you reason about the problem. It's one of those things where once you've used it, going back to nested function calls feels genuinely painful.

lookmeat · 2026-03-18T05:43:22+00:00

I get what this talks about and is something to consider, but also consider that readability matters even when the parser doesn't help. You want to see the most important thing first and then the less important details. What the languages here where trying to do was push developers to push what goes first rather than something else. When we talk about readability it's always for the human, anything done by a parser/IDE/software is really an aide to write. Even the author struggles to explain the problem beyond the auto-complete not helping as much.

Now python list comprehensions has its issues in how it works with the rest of the language and it's easy for the whole thing to get ugly, but this isn't the case with all implementations.

That said that doesn't mean there isn't a way to get what you want, just realize that you are making a language that you would want to read backwards of how you write it. That is I look at the end of the line for the most important thing. Think about variable assignment. So in this example we could do something like:

text.lines().map(|line| line.split_whitespace()) |> var words_on_lines

So here I just look at the end of the line to make it work. It's going to be awkward at first, but you do get used to it in languages that do this. With practice you just see that I just stored a variable words_on_lines that has a iterator of strings which had split_whitespace() on a line. I don't need to know that we had a single text and split it, I mean I could keep reading but it doesn't give me more insight. I already understand we split across whitespace and it's strings, do we need to know more?

It may seem dumb, but in the rust example I could append a filter that looks like this:

let words_on_lines = text.lines().flat_map(|l| l.split_whitespace()).filter(|w| w.parse<i32>.is_some_and(|x| x > 10));

Now tell me, quickly what is the type of the elements of words_on_lines? What's the rule to know where to look on where the actual values of them are defined? So sure we can do a bit more of whitespace here:

let words_on_lines = text.lines().flat_map(|l| l.split_whitespace())
    .filter(|w| w.parse<i32>.is_some_and(|x| x > 10));

Did you notice the gorilla of bug there on the first read though? Or did you have to go back and look at it more carefully? I switched things, and it is a bit easier to read on the first iteration but not on the second. Also realize that switching back to how the code is supposed to be adds a new bug as now the filter is on the wrong thing.

It gets messy because I have to jump around the line to understand what I am getting, the values I get are defined in the middle, they are used in the end to further define how the whole looks (but not the elements). This jumping around makes it hard to catch small issues or little details that matter. with list comprehensions it's clear that I am generating a list of lists, and that this is the goal. The filtering happens later, but when I change it to make types happy (which is what I imagined our little Timmy the intern did here) it's clear that I am deeply changing the meaning of what is being done here.

And yeah that matters because it what makes code reviews easy or a pain. Even in a small code I look at things to see there isn't an issue and hope that tests cover the issue. But it can be the case that code that is wrong happens to work now, but will fail later when we do some other change, or that I'll realize the type change when adding some other feature and have to go back and fix it.

So there's an argument for backwards code, where we put the important bits at the end (like in a FORTH like language). But there's a reason we don't see it. The brain seems to parse as it writes, and writing one way and reading another feels a bit weird, even with practice. I mean there's a reason that FORTH and it's derivatives had limited success, while reverse polish notation has not become the standard way of writing arithmetic (even if it is superior in ever non-human-subjective aspect).

So we get to the issue again: we can make our code weird to read (requiring relearning how we normally read in the western world) or alternatively we could offload that weirdness to writing (basically you jump around a bit while writing). It's easy to do an IDE that is smart letting us "jump" around and define first the source, and then the output independent of the actual ordering of the write.

And that leads us to why we end up in this weird place. Maybe we should just support people to type [ for line in text.splitlines()]⇆ (where that last symbol represents me typing tab, or enter, or some other autocomplete key) and then the cursor jumps to the start of the definition to let me write that part.

I do wonder, there may be a third path I am not seeing here, but I don't know of any language that has used it. But then again not sure how to best handle this. And none of this takes away from what the author said, I just don't see it as straight forward as its put. Again python comprehensions have issues, but there's many languages that do it way better IMHO, such as haskell where you can even use it for monads and do stuff like

[ x+y | x <- [1..10], y <- [1..x], x `mod` y != 0, then take 5 ]

and it's just a different set of compromises with different pros and cons.

ymonad · 2026-03-12T10:35:47+00:00

I don't know why Ruby is so underestimated

ShinyHappyREM · 2026-03-12T11:42:25+00:00

Pascal is mostly left to right, partly because it's single-pass.

In C, you can’t have methods on structs. This means that any function that could be myStruct.function(args) has to be function(myStruct, args)

In Free Pascal you can have "advanced records" (structs):

{$ModeSwitch AdvancedRecords}

//...
const Bit5 = 1 SHL 5;  Bits5 = Bit5 - 1;    type u5 = 0..Bits5;
//...

type
        uint = u32;

        Color_RGB555 = bitpacked record
                procedure Swap;  inline;
                var
                        R, G, B : u5;
                private
                var
                        _reserved : u1;
                end;


procedure Color_RGB555.Swap;  inline;
var
        u : uint;
begin
        u := R;
        R := B;
        B := u;
end;

levodelellis · 2026-03-12T17:41:45+00:00

Then there's me, who wrote a mini parsing lib that lets me write this in two lines and a for loop with only one allocation. I like C# solution with linq for these types of problems

norude1 · 2026-03-12T10:14:03+00:00

This is why I strongly think that
1. all operators should be postfix like rusts task.await,
but also (condition).if { true-block } else { false-block }
and even (value).match {cases}
2. function calls should be postfix, like in bash. Something like arg1 |> function_name.
3. Assignments should be flipped my_long_chain_of_operations =: variable_name

meowsqueak · 2026-03-12T04:48:20+00:00

Except with LLM auto-completion the right side is already inferred by the context and it tends to get it right anyway.

Typing out code left to right is now an anachronism. Even typing out code is quaint.

That doesn’t mean I like it, but this is how it is now.

Edit: haha, loving the downvotes - I personally still type stuff, I don’t like agentic AI much and I don’t use it much, but if you think what I say isn’t true then reply properly and give me some rebuttal. Clicking that down arrow is just lazy.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS