Bits of Syntax: Assignment

Andrew (he/him) - Sep 24 '19 - - Dev Community

Recently, I've become quite interested in programming language design. The syntax of a language can affect its readability and usability, but it can also impact its aesthetics as well as frame how developers think while they're using it.

Java, with its strong object-oriented design, can lead programmers to focus intently on data hierarchies, variable scope, and relationships between different functional components of a codebase. Strongly functional languages like Haskell, R, and Scala, tend to lend themselves more to thinking about streams of data, lambda expressions, and map-reduce pipelines. "Bare metal" languages like C and Assembly can have you squeezing as much performance out of your code as possible, while hopefully not trying to access out-of-bounds memory.

I'm fascinated by how software engineers and language designers over the past 80 years or so have attacked the problem of bridging the gap between binary and human-readable languages in hundreds, if not thousands, of different ways. That's why I'm starting this series of discussions: to pick everyone's brains about what bits of syntax you love, which ones you hate, and which ones you could care less about. I'll tell you my thoughts and you tell me yours!


For this inaugural discussion, I'd like to focus on assignment. There are many different ways to declare and initialise variables. Variable assignment probably has the widest variety of operators among all basic programming concepts; we've got the standard:

x = 5
Enter fullscreen mode Exit fullscreen mode

the more explicit

x := 5
Enter fullscreen mode Exit fullscreen mode

and my favorite, which I think gives a strong sense of movement and is closest to the mathematical

x <- 5
Enter fullscreen mode Exit fullscreen mode

There are more languages which use keywords like let and set to declare variables and then there's LISP, which of course uses lots of parentheses:

(let ((x 12)) ...)
Enter fullscreen mode Exit fullscreen mode

What's your preferred assignment operator? How would you solve the assignment / equality dilemma? And what do you think of multiple / parallel assignment? (For instance, I love the fact that some languages use pattern matching to assign multiple variables different values in the same line of code, like: (a, b) = (3, 4).)

If I had to choose, I'd say I actually prefer forward assignment, like

4 -> x
Enter fullscreen mode Exit fullscreen mode

I know it's been drilled into our heads since maybe middle school algebra, but I don't understand why variable assignment goes right-to-left (RTL; x <- 3) rather than left-to-right (LTR; 3 -> x). Basically all of the rest of our code (as well as most world languages) are written and read LTR.

Doing assignment like this also makes it easier to pipeline operations. Lots of languages allow you to skip the first argument to a function by use of a pipe operator. So instead of:

sqrt(3)
Enter fullscreen mode Exit fullscreen mode

...you might do something like

3 | sqrt()
Enter fullscreen mode Exit fullscreen mode

or

3 %>% sqrt()
Enter fullscreen mode Exit fullscreen mode

LTR assignment would make this code flow really nicely. Instead of:

x = pow(sqrt(log(5)), 2)
Enter fullscreen mode Exit fullscreen mode

...we could do

5 -> log() -> sqrt() -> pow(2) -> x
Enter fullscreen mode Exit fullscreen mode

...which reads like a series of steps: "take 5, and get its logarithm, then take the result and get the square root, then..."

If I wrote my own language, I would enforce LTR assignment and add some syntactic sugar to allow those empty parentheses to be dropped as well, giving something like:

5 -> log -> sqrt -> pow(2) -> x
Enter fullscreen mode Exit fullscreen mode

What do you think? Do you love it or hate it?

I'm looking forward to hearing your thoughts!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .