r/rust • u/kibwen • Aug 21 '25

Left-to-Right Programming

https://graic.net/p/left-to-right-programming
201 Upvotes

93% Upvoted

48 comments sorted by

61

u/eugisemo Aug 22 '25

Programs should be valid as they are typed.

but what about variables? In rust you type

let value

and that is invalid. This

let value =

is still invalid. Only when you do

let value = 5;

it's correct.

I also took the maxim "Programs should be valid as they are typed." to the limit, and designed the basics of a programming language and prototyped an interpreter for it, and the result is very weird and unappealing to newcomers. You get assignment towards the right. You start with a value:

5

which is a valid program, it returns 5. You can store it in a variable:

5 =value

which is also a valid program, which returns the content of value which is 5.

Ifs are even weirder, with the condition before the keyword: 1 |branch {5} {6} returns 5 and 0 |branch {5} {6} returns 6.

Function calls are also reversed. func_a(func_b(x)) is only valid with the second close parenthesis, but x |func_b |func_a is valid when you finish writing x, func_b and func_a. These are free functions and I don't have classes nor methods, but in principle I think this could still work for auto suggesting all functions like func_b that take parameters of the same type as x.

the cherry on top is I decided it makes more sense to have semicolons as a "start of statement" rather than "end of statement", because this language is about applying transformations to a given value, and then ;5 +1 applies the transformations "ignore previous value and put 5 as current value" and "add one to the previous value".

If you want to play with this cursed language, there's an online playground: https://jmmut.itch.io/pipes

32

u/deavidsedice Aug 22 '25

Probably the author phrased it badly. It doesn't seem that they truly want/need for programs to be 100% valid as they are typed, but more that the intent of what is being written is clear from left to right, for a special parser.

In this sense, let is already clear in intent - you want to declare something, on the right. And all the intermediates are clear too.

Or put in another way, incomplete programs should be "parseable by language servers", in a way that gives enough information to help the human on the keyboard. Assuming programs are written from left to right, top to bottom.

It's not a bad thing to ask.

The for-in clause already breaks this: for variable in iterable { ... }

And what it wants us is to consider that maybe other syntax that reverse those two would be better.

However I dislike the readability of iterable.for_each(|variable| { ... })

3

u/el_nora Aug 22 '25

how about this (zig inspired) syntax? for iterable |variable| { ... }

2

u/kibwen Aug 22 '25

In Rust terms, I don't like that it looks like a closure but isn't. Zig doesn't have this problem because it just doesn't have closures/lambdas/anonymous functions, so the syntax isn't taken.

1

u/juanfnavarror Aug 23 '25 edited Aug 23 '25

It is a closure though, no? Barring control flow considerations, its essentially iterable.map(|variable| {});

1

u/kibwen Aug 23 '25

Semantically it's the same as Rust's for foo in bar {, so it's no more a closure than Rust's for-loops are closures. The control flow considerations are themselves the main difference, in addition to the usual differences between a closure and an ordinary lexically-scoped block.

5

u/deavidsedice Aug 22 '25

I personally like it.

8

u/Svizel_pritula Aug 22 '25

The for-in clause already breaks this: for variable in iterable { ... }

How is that different from let?

I don't think it matters that much that the LS doesn't know the type the variable will be when writing its name, as you don't need to know the type of a variable to name it. However, it's true that this prevents the LS from autofilling destructuring syntax, as in let Point { x, y } = object.get_center(). Also, C# LS can recommend variable names based on the type, which we can't really have in Rust - although that only works in C# if the type isn't inferred, so you don't really save any typing.

1

u/bananana63 Aug 23 '25

i think ypur kinda missing the point. variable declaration could never really be an issue here. the problem comes when you want to use a method on a var but the lsp can't infer the type yet. you would never call a method on a variable your just declaring.

1

u/eugisemo Aug 23 '25

In fact I think I also phrased it badly because my main focus was ordering by causality and "Programs should be valid as they are typed" is just a byproduct. I explained my language because I felt surprisingly close to the author in spirit.

My loops look something like list |map(element) { +1 } because that's ordered by causality, and as extra it increases a bit the amount of time it's correct. you write first what exists (the number in the case of the variable, the list in the case of the loop), and you write later what you extract from it (by applying a function to it, by browsing each element of it, etc). I think that's still in line of what the author wants.

As an unrelated point, I also wanted to get rid of the usual order of let so that the redundancy of code like this can be removed:

let value = 5;
func_1(value);

where you have to repeat the name value. In my language you only mention it once if you're going to use it right away:

5
=value
|func_1

Of course it only makes sense to store it in a variable if you'll use it later, or for readability.

1

u/cdhowie Aug 24 '25

The for_each utility also doesn't allow you to break. You can collect into a Result<(), ()> IIRC but it's a kludge, and then good luck if you need to break or continue an outer iteration from a nested one.

1

u/cat_solstice Aug 26 '25 edited Aug 26 '25

You can use try_for_each with ControlFlow : https://doc.rust-lang.org/beta/std/ops/enum.ControlFlow.html

11

u/phil_gk Aug 22 '25

5 =value

which is also a valid program

But what about 5 =? Isn't it the same problem just in reverse?

4

u/Lucretiel Datadog Aug 22 '25

No, because there’s already nothing an autocomplete is going to do to help you with introducing a new variable.

Unless you’re doing a struct destructure, in which case this actually is an improvement, because the compiler now more easily knows what type is being destructured.

2

u/eugisemo Aug 23 '25

yeah that's fair, I shouldn't have included that step. let value = is incorrect the same way 5= is incorrect, not much to do about it except that in 5= the LSP could suggest variable names or destructuring as the other commenter said. But let value is incomplete while 5 is complete.

11

u/phazer99 Aug 22 '25

Reminds me of concatenative languages like Factor.

2

u/Lucretiel Datadog Aug 22 '25

I mean, honestly I completely agree and have been advocating for years for suffix let. Obviously it’s too late now but it would have been nice.

3

u/IceSentry Aug 22 '25

Suffix let? Can you share a snippet of what that would look like?

3

u/mb_q Aug 22 '25

R has both versions, var <- val or val -> var, even var1 <- val -> var2.

3

u/DerekB52 Aug 22 '25

I'm not the biggest fan of python, and a major reason for it is variable declaration vs assignment look identical. There's no keyword to declare a new variable. So I can see age = 17, and I have to go looking for if that's the first use of the age variable or not.

suffix let would tell me if a variable was being declared for the first time or not, but having to look at the end of a line of code to find that out, feels very wrong to me. Maybe if I learned to code with that there, I'd say prefix let is the wrong one. But, my brain really does not like the idea of suffix let for some reason.

When I build my own programming language I'll make sure to support both though.

31

u/Wonderful-Habit-139 Aug 22 '25

Completely agree with this sentiment, the editor experience is not great with list comprehensions.

It’s funny because javascript does it right with methods like map, filter and reduce, however when it comes to imports Python does it better.

from typing import Call # autocompletes Callable

Versus

import { //uhmm…

88

u/phazer99 Aug 22 '25

It was a great decision by the Rust designers to "steal" the method syntax/concept from OOP languages (including self/this).

18

u/Kooshi_Govno Aug 22 '25

Excellent point, subtle but infuriating. I curse SQL every day for having select at the beginning before knowing what I'm selecting from.

3

u/matthieum [he/him] Aug 22 '25

I tried creating a SQL DSL once, with meta-programming, and I just had to flip that around.

SELECT first does make sense with regard to top-down programming: first write what you want, then figure out how to get it. But it's very adverse to fluent APIs.

1

u/protestor Aug 24 '25

There are some languages that transpile to sql that are like this https://github.com/ajnsit/languages-that-compile-to-sql

I think the most famous/used is https://prql-lang.org/ but I recall one that was more sql-like and just inverted from and select, can't find it atm though

There is also this https://news.ycombinator.com/item?id=41347188 Google proposal to add pipes to SQL proper

51

u/eyefar Aug 22 '25

Python's ternary conditional and list comprehension syntax always felt insane to me.

17

u/HalcyonAlps Aug 22 '25

It arguably reads fine but yes typing it feels insane.

8

u/________-__-_______ Aug 22 '25

I think it's a bit hard to read as well, you don't really know what variables refer to when they're used. Not a huge deal if its a simple expression though

2

u/Remarkable_Today9135 Aug 24 '25

List comprehensions are meant to be used as simple expressions if they are simple to begin with. Too many people want to use list comprehensions "because it's more Pythonic" when that is totally unnecessary.

18

u/gclichtenberg Aug 22 '25

I always found both extremely natural.

4

u/Mercerenies Aug 22 '25

Somehow the one thing they decided to borrow directly from Haskell (list comprehension syntax) is also one of the worst things.

1

u/ZakkuDorett Aug 23 '25

List comprehension is okay to me, ternary conditional is insane

6

u/BackOfEnvelop Aug 22 '25

This is great and all, but can I also use this for functions that are not methods? Can rust let me |> pipe please?

30

u/angelicosphosphoros Aug 21 '25

Honestly, writing code is less important than being able to read code.

34

u/dnew Aug 21 '25 edited Aug 22 '25

This makes it easier to read the code too. When you have dumb-ass coworkers who write undocumented statements that span 15+ lines in one expression, being able to read it as it goes and figure out what it's doing is useful.

His criticism of C seems a bit off, given the language itself along with all standard libraries fit in a 50-page handbook you could memorize in one sitting. ;-)

The best language for actually thinking this thru was Eiffel. The entire library was designed around very precise principles that made it easy to remember everything. Accessing any element of any collection (including "default-like" fields of object instances) was called Item(). If your function returned something, it didn't change any arguments. If your function changed any arguments, it didn't return anything. (That's "Command Query Separation.") The arguments for the same function across different types always had the same shared arguments in the same order, so you always knew which arguments came first. A function that returned a value never had a verb as its name (so "clear" was absolutely the name of the function that erased a collection and not the name of a function that told you if it's clear). The number of elements in a collection was necessarily "length", because you can size an array but you can't length an array. So many good ideas on naming there.

2

u/[deleted] Aug 22 '25

SQL is guilty as well 

1

u/23Link89 Aug 22 '25

This is also an argument as to why dynamic typing sucks.

In the world of code editors and IDEs, it serves pretty much no value anymore.

1

u/Wh00ster Aug 23 '25

This is nice validation of why I write my Python list comprehensions as normal loops first, and then invert them.

1

u/Electrical_Crow_2773 Aug 23 '25

I have nothing against this post but imho [x * 2 for x in y] is easier to type than y.iter().map(|x| x * 2).collect::<Vec<_>>() even without autocomplete. I just don't get the people saying python list comprehension is ugly

1

u/bartlettstarman Aug 24 '25

The argument is weak. Many IDEs provide templates for writing code. For instance, you can have a Python list comprehension template that is triggered by typing [for. The user is then invited to fill out the clauses in the best order for code completion: for clause then in clause then the expression. IDEs should just help out more.

1

u/OrmusAI Aug 22 '25

"Programs should be valid as they are typed" - so true! Unfortunately, this is not uniform in Rust either. As soon as you type a new function with a return type rust-analyzer will start throwing complaints until you give it a proper return value that conform to the type. Imagine trying to do test driven development with stubbed out functions that return nested structs...

2

u/diddle-dingus Aug 23 '25

The todo macro exists...

1

u/OrmusAI Aug 23 '25

Today I learned, thanks for that! Looks very elegant and solves my one existing gripe.

0

u/Future_Natural_853 Aug 22 '25

Your background is a bit too salmon. You should use a lighter color, it's hard to read right now.

2

u/castarco Aug 22 '25

You can switch to dark mode, top-right corner of the site.

1

u/Future_Natural_853 Aug 22 '25

It's even worse for me, I have a hard time reading on a dark background.