Skip to content

Left to Right Programming

Technology
27 11 0
  • This post did not contain any content.

    I'm always suspicious of people who say that a language is suboptimal and use as evidence some filthy one-liner. Maybe if you bothered to write some whitespace and didn't write the language ignorant of its features (like generator expressions) you would end up with better code?

    sum(
        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
    )
    

    You no longer have to "jump back and forth" except one single time - you have to look to the end to see where line is coming from and then you can read the body of the main expression from start to finish.

    People don't, in fact, read code from top to bottom, left to right; they read it by first looking at its "skeleton" - functions, control flow, etc - until finding the bit they think is most important to read in detail. That implies that "jumping back and forth" is a natural and necessary part of reading (and hence writing) code, and so is nothing to fear.

    There is still a slight advantage to not having to jump around, but consider the costs: in Javascript, map and filter are methods on Array and some other types. So how are you going to implement them for your custom iterable type? Do you have to do it yourself, or write lots of boilerplate? It's easy in Python. It's not bad in Rust either because of traits, but what this all means is that to get this, you need other, heavy, language features.

    In practice, you often know what a comprehension is iterating over due to context. In those situations, having what the comprehension produces be the most prominent is actually a boon. In these scenarios in Rust/JS you are left skipping over the unimportant stuff to get to what you actually want to read.

  • I'm always suspicious of people who say that a language is suboptimal and use as evidence some filthy one-liner. Maybe if you bothered to write some whitespace and didn't write the language ignorant of its features (like generator expressions) you would end up with better code?

    sum(
        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
    )
    

    You no longer have to "jump back and forth" except one single time - you have to look to the end to see where line is coming from and then you can read the body of the main expression from start to finish.

    People don't, in fact, read code from top to bottom, left to right; they read it by first looking at its "skeleton" - functions, control flow, etc - until finding the bit they think is most important to read in detail. That implies that "jumping back and forth" is a natural and necessary part of reading (and hence writing) code, and so is nothing to fear.

    There is still a slight advantage to not having to jump around, but consider the costs: in Javascript, map and filter are methods on Array and some other types. So how are you going to implement them for your custom iterable type? Do you have to do it yourself, or write lots of boilerplate? It's easy in Python. It's not bad in Rust either because of traits, but what this all means is that to get this, you need other, heavy, language features.

    In practice, you often know what a comprehension is iterating over due to context. In those situations, having what the comprehension produces be the most prominent is actually a boon. In these scenarios in Rust/JS you are left skipping over the unimportant stuff to get to what you actually want to read.

    I agree with you that the one liner isn't a good example, but I do prefer the "left to right" syntax shown in the article. My brain just really likes getting the information in this order: "Iterate over Collection, and for each object do Operation(object)".

    The cost of writing member functions for each class is a valid concern. I'm really interested in the concept of uniform function call syntax for this reason, though I haven't played around with a language that has it to get a feeling of what its downsides might be.

  • I agree with you that the one liner isn't a good example, but I do prefer the "left to right" syntax shown in the article. My brain just really likes getting the information in this order: "Iterate over Collection, and for each object do Operation(object)".

    The cost of writing member functions for each class is a valid concern. I'm really interested in the concept of uniform function call syntax for this reason, though I haven't played around with a language that has it to get a feeling of what its downsides might be.

    I was also thinking about UFCS. I do like it for its flexibility, but I did try it in Nim one time and was left feeling unsure. Unfortunately I now can't remember what exactly I didn't like about it.

  • This post did not contain any content.

    Is string length len, length, size, count, num, or # ? Is there even a global function for length? You won’t know until you try all of them.

    This is Python basics, so the argument would be to optimize readability specifically for people who have zero familiarity with the language.

    (The other examples have the same general direction of readability tradeoff to the benefit of beginners, this one was just simplest to pick here)

    That's a valid tradeoff to discuss, if discussed as a tradeoff. Here it is not. The cost to readability for anyone with language familiarity appear to be not even understood.

  • Is string length len, length, size, count, num, or # ? Is there even a global function for length? You won’t know until you try all of them.

    This is Python basics, so the argument would be to optimize readability specifically for people who have zero familiarity with the language.

    (The other examples have the same general direction of readability tradeoff to the benefit of beginners, this one was just simplest to pick here)

    That's a valid tradeoff to discuss, if discussed as a tradeoff. Here it is not. The cost to readability for anyone with language familiarity appear to be not even understood.

    The point of the article is about how IDE's can't validate certain things as you type them in this order. The example of a string length function could be replaced by any other API.

  • The point of the article is about how IDE's can't validate certain things as you type them in this order. The example of a string length function could be replaced by any other API.

    That is one of the points, yes.

    But, the reason for wanting the IDE to validate based on partially entered expressions is given as making it easier to follow the code for a person working left-to-right.

    And it's not an invalid thing to want, but I expect the discussion to also include how it affects reading the code for a non-beginner.

  • I'm always suspicious of people who say that a language is suboptimal and use as evidence some filthy one-liner. Maybe if you bothered to write some whitespace and didn't write the language ignorant of its features (like generator expressions) you would end up with better code?

    sum(
        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
    )
    

    You no longer have to "jump back and forth" except one single time - you have to look to the end to see where line is coming from and then you can read the body of the main expression from start to finish.

    People don't, in fact, read code from top to bottom, left to right; they read it by first looking at its "skeleton" - functions, control flow, etc - until finding the bit they think is most important to read in detail. That implies that "jumping back and forth" is a natural and necessary part of reading (and hence writing) code, and so is nothing to fear.

    There is still a slight advantage to not having to jump around, but consider the costs: in Javascript, map and filter are methods on Array and some other types. So how are you going to implement them for your custom iterable type? Do you have to do it yourself, or write lots of boilerplate? It's easy in Python. It's not bad in Rust either because of traits, but what this all means is that to get this, you need other, heavy, language features.

    In practice, you often know what a comprehension is iterating over due to context. In those situations, having what the comprehension produces be the most prominent is actually a boon. In these scenarios in Rust/JS you are left skipping over the unimportant stuff to get to what you actually want to read.

    People don’t, in fact, read code from top to bottom, left to right

    100% this.

    This false premise is also why a few (objectively wrong) people defend writing long essays: functions with hundreds of lines and files with thousands; saying "then you don't have to go back and forth to read it", when in fact, no one should be reading it like a novel in the first place.

    Once you get used with list and dict comprehensions, they read just fine. Much like the functional approach is not really that readable for a newcomer either.

  • The point of the article is about how IDE's can't validate certain things as you type them in this order. The example of a string length function could be replaced by any other API.

    The example of a string length function could be replaced by any other API

    I don't know about that, len is a built-in -- like str, abs, bool. There are only a few of them and they're well known by people familiar to the language (which seems to exclude the article author). Their use is more about the language itself than about what to expect from a particular API.

    In fact, most Python APIs that go beyond built-in usage actually look much more object-oriented with "left-to-right" object.method() calls. So this argument seems silly and goes away with some familiarity with that language.

  • Comprehension is functional programming too, they arise from list monad https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/13-the-list-monad
    And Haskell do notation indeed reads top-down, unlike Python, but I find both quite readable.

  • That is one of the points, yes.

    But, the reason for wanting the IDE to validate based on partially entered expressions is given as making it easier to follow the code for a person working left-to-right.

    And it's not an invalid thing to want, but I expect the discussion to also include how it affects reading the code for a non-beginner.

    It's got nothing to do with being a beginner. I've been working as a professional software developer for ~15 years now and still I have to use new libraries/frameworks/in-house dependencies quite frequently. I know how to get the length of a string, and so does the author of the article.

    But that's why it's a simple example and nothing more, and it applies to everything else. We write left to right, and IDEs autocomplete left to right, so it makes sense for languages to be designed to work that way.

    There's a lot of reasons why Java works much better with IDEs than python, and this is one of them.


    Besides that, it is best practice to show problems on simple, easy to follow use cases that highlight exactly the problem in question without further fluff. It's expected that a non-beginner can abstract that problem into more difficult use cases, so I don't think OOP did anything wrong with choosing string length as an example.

  • The example of a string length function could be replaced by any other API

    I don't know about that, len is a built-in -- like str, abs, bool. There are only a few of them and they're well known by people familiar to the language (which seems to exclude the article author). Their use is more about the language itself than about what to expect from a particular API.

    In fact, most Python APIs that go beyond built-in usage actually look much more object-oriented with "left-to-right" object.method() calls. So this argument seems silly and goes away with some familiarity with that language.

    The argument is not silly, it totally makes sense, and your point even proves that.

    A lot of libraries use module-level globals and if you use from imports (especially from X import *) you get exactly that issue.

    Yes, many more modern APIs use an object-oriented approach, which is left-to-right, and that's exactly what OOP is argueing for. If you notice, he didn't end the post with "Make good languages" but with "Make good APIs". He highlights a common problem using well-known examples and generalizes it to all APIs.

    The auther knows full well that this blog post will not cause Python to drop the List comprehension syntax or built-in functions. What he's trying to do is to get people to not use non-LTR approaces when designing APIs. All the points he made are correct, and many are even more pressing in other languages.

    For example, for a hobby project of mine I have to use C/C++ (microcontrollers). And this problem is huge in C libraries. Every function is just dumped into the global name space and there's no way to easily find the right function. Often I have to go to google and search for an external documentation or open up the header files of a project to find a function that does what I want, instead of being able to just follow the IDE autocomplete on an object.

    And sure, if I know every library and framework I use inside out and memorized all functions, methods, objects, variables and fields, then it's easy, but unless you work 30 years in a bank where you maintain the same old cobol script for decades, that's not going to happen.

  • I'm always suspicious of people who say that a language is suboptimal and use as evidence some filthy one-liner. Maybe if you bothered to write some whitespace and didn't write the language ignorant of its features (like generator expressions) you would end up with better code?

    sum(
        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
    )
    

    You no longer have to "jump back and forth" except one single time - you have to look to the end to see where line is coming from and then you can read the body of the main expression from start to finish.

    People don't, in fact, read code from top to bottom, left to right; they read it by first looking at its "skeleton" - functions, control flow, etc - until finding the bit they think is most important to read in detail. That implies that "jumping back and forth" is a natural and necessary part of reading (and hence writing) code, and so is nothing to fear.

    There is still a slight advantage to not having to jump around, but consider the costs: in Javascript, map and filter are methods on Array and some other types. So how are you going to implement them for your custom iterable type? Do you have to do it yourself, or write lots of boilerplate? It's easy in Python. It's not bad in Rust either because of traits, but what this all means is that to get this, you need other, heavy, language features.

    In practice, you often know what a comprehension is iterating over due to context. In those situations, having what the comprehension produces be the most prominent is actually a boon. In these scenarios in Rust/JS you are left skipping over the unimportant stuff to get to what you actually want to read.

    Did we read the same blog post?

    Not a single time did OOP talk about readability. That was not a point at all, so I don't know why you are all about readability.

    It was all about having a language that the IDE can help you write in because it knows what you are talking about from the beginning of the line.

    The issue with the horrible one-liner (and with your nicely split-up version) is that the IDE has no idea what object you are talking about until the second-to-last non-whitespace character. The only thing it can autocomplete is "diffs". Up until you typed the word, it has no idea whether sum(), all(), abs(), <, >, or for-in actually exist for the data type you are using.

    If you did the same in Java, you'd start with diffs and from then on the IDE knows what you are talking about, can help you with suggesting functions/methods, can highlight typos and so on.

    That was the whole point of the blog post.

  • People don’t, in fact, read code from top to bottom, left to right

    100% this.

    This false premise is also why a few (objectively wrong) people defend writing long essays: functions with hundreds of lines and files with thousands; saying "then you don't have to go back and forth to read it", when in fact, no one should be reading it like a novel in the first place.

    Once you get used with list and dict comprehensions, they read just fine. Much like the functional approach is not really that readable for a newcomer either.

    The blog post wasn't about reading, but about writing. And people usually do write top-to-bottom, left-to-right.

    The whole point of the blog post was to write code that the IDE can help you with when writing. It didn't go into readability even once.

  • This post did not contain any content.

    I'll agree that list comprehensions can be a bit annoying to write because your IDE can't help you until the basic loop is done, but you solve that by just doing [thing for thing in things] and then add whatever conditions and attr access/function calls you need.

  • Did we read the same blog post?

    Not a single time did OOP talk about readability. That was not a point at all, so I don't know why you are all about readability.

    It was all about having a language that the IDE can help you write in because it knows what you are talking about from the beginning of the line.

    The issue with the horrible one-liner (and with your nicely split-up version) is that the IDE has no idea what object you are talking about until the second-to-last non-whitespace character. The only thing it can autocomplete is "diffs". Up until you typed the word, it has no idea whether sum(), all(), abs(), <, >, or for-in actually exist for the data type you are using.

    If you did the same in Java, you'd start with diffs and from then on the IDE knows what you are talking about, can help you with suggesting functions/methods, can highlight typos and so on.

    That was the whole point of the blog post.

    I dunno, did we?

    Screenshot from the post

    I think rust's iterator chains are nice, and IDE auto-complete is part of that niceness. But comprehension expressions read very naturally to me, more so than iterator chains.

    I mean, how many python programmers don't even type hint their code, and so won't get (accurate) auto-complete anyway? Auto-completion is nice but just not the be-all and end-all.

  • The blog post wasn't about reading, but about writing. And people usually do write top-to-bottom, left-to-right.

    The whole point of the blog post was to write code that the IDE can help you with when writing. It didn't go into readability even once.

    the last section before the conclusion only mentions readability

  • The argument is not silly, it totally makes sense, and your point even proves that.

    A lot of libraries use module-level globals and if you use from imports (especially from X import *) you get exactly that issue.

    Yes, many more modern APIs use an object-oriented approach, which is left-to-right, and that's exactly what OOP is argueing for. If you notice, he didn't end the post with "Make good languages" but with "Make good APIs". He highlights a common problem using well-known examples and generalizes it to all APIs.

    The auther knows full well that this blog post will not cause Python to drop the List comprehension syntax or built-in functions. What he's trying to do is to get people to not use non-LTR approaces when designing APIs. All the points he made are correct, and many are even more pressing in other languages.

    For example, for a hobby project of mine I have to use C/C++ (microcontrollers). And this problem is huge in C libraries. Every function is just dumped into the global name space and there's no way to easily find the right function. Often I have to go to google and search for an external documentation or open up the header files of a project to find a function that does what I want, instead of being able to just follow the IDE autocomplete on an object.

    And sure, if I know every library and framework I use inside out and memorized all functions, methods, objects, variables and fields, then it's easy, but unless you work 30 years in a bank where you maintain the same old cobol script for decades, that's not going to happen.

    from X import *

    That's malpractice in most cases, and thankfully, becoming more rare to find in the wild. Any decent linter will shout at you for using star imports.

    What he’s trying to do is to get people to not use non-LTR approaces when designing APIs.

    Then he should have picked examples of APIs that break this, not use the built-in functions. Because as it reads now, it seems he is just against established conventions for purism.

    this problem is huge in C libraries

    yeah, one of my favorite things about python is that everything not in the language itself is either defined in the file, or explicitly imported. Unless, like mentioned, you have anti-patterns like star imports and scripts messing with globals().

  • This post did not contain any content.

    I'm kinda surprised that pretty much nobody who commented here seems to have understood the point of the post.

    It wasn't about readability at all.

    It was about designing APIs that the IDE can help you with.

    With RTL syntax the IDE doesn't know what you are talking about until the end of the line because the most important thing, the root object, the main context comes last. So you write your full statement and the IDE has no idea what you are on about, until you end at the very end of your statement.

    Take a procedural-style statement:

    len(str(myvar))

    When you type it out, the IDE has no idea what you want to do, so it begins suggesting everything in the global namespace starting with l, and when you finish writing len(, all it can do is point out a syntax error for the rest of the line. Rinse and repeat for str and myvar.

    Object-oriented, the IDE can help out much more:

    myvar.tostring().length()

    With each dot the IDE knows what possible methods you cound mean, the autocomplete is much more focussed and after each () there are no open syntax errors and the IDE can verify that what you did was correct. And it you have a typo or reference a non-existing method it can instantly show you that instead having to wait until the end of the whole thing.

  • I dunno, did we?

    Screenshot from the post

    I think rust's iterator chains are nice, and IDE auto-complete is part of that niceness. But comprehension expressions read very naturally to me, more so than iterator chains.

    I mean, how many python programmers don't even type hint their code, and so won't get (accurate) auto-complete anyway? Auto-completion is nice but just not the be-all and end-all.

    Fair, I missed one word. You missed the whole blog post.

    It's a big difference between writing code and writin APIs, tbh. If you write crap code that's your problem. If you write crap APIs it's the problem of anyone using your API.

  • the last section before the conclusion only mentions readability

    What about all the other sections?

  • 0 Stimmen
    1 Beiträge
    11 Aufrufe
    Niemand hat geantwortet
  • SHUT THE FUCK UP!

    Technology technology
    20
    2
    94 Stimmen
    20 Beiträge
    235 Aufrufe
    teft@piefed.worldT
    Why censor fucking but not fuck?
  • 346 Stimmen
    17 Beiträge
    201 Aufrufe
    L
    Great interview! The whole proof-of-work approach is fascinating, and reminds me of a very old email concept he mentions in passing, where an email server would only accept a msg if the sender agreed to pay like a dollar. Then the user would accept the msg, which would refund the dollar. So this would end up costing legitimate senders nothing but would require spammers to front way too much money to make email spamming affordable. In his version the sender must do a processor-intensive computation, which is fine at the volume legitimate senders use but prohibitive for spammers.
  • The Decline of Usability: Revisited | datagubbe.se

    Technology technology
    8
    68 Stimmen
    8 Beiträge
    80 Aufrufe
    R
    I blame the idea of the 00s and 10s that there should be some "Zen" in computer UIs and that "Zen" is doing things wrong with the arrogant tone of "you don't understand it". Associated with Steve Jobs, but TBH Google as well. And also another idea of "you dummy talking about ergonomics can't be smarter than this big respectable corporation popping out stylish unusable bullshit". So - pretense of wisdom and taste, under which crowd fashion is masked, almost aggressive preference for authority over people actually having maybe some wisdom and taste due to being interested in that, blind trust into whatever tech authority you chose for yourself, because, if you remember, in the 00s it was still perceived as if all people working in anything connected to computers were as cool as aerospace engineers or naval engineers, some kind of elite, including those making user applications, objective flaw (or upside) of the old normal UIs - they are boring, that's why UIs in video games and in fashionable chat applications (like ICQ and Skype), not talking about video and audio players, were non-standard like always, I think the solution would be in per-application theming, not in breaking paradigms, again, like with ICQ and old Skype and video games, I prefer it when boredom is thought with different applications having different icons and colors, but the UI paradigm remains the same, I think there was a themed IE called LOTR browser which I used (ok, not really, I used Opera) to complement ICQ, QuickTime player and BitComet, all mentioned had standard paradigm and non-standard look.
  • 162 Stimmen
    7 Beiträge
    63 Aufrufe
    L
    I wonder if they could develop this into a tooth coating. Preventing biofilms would go a long way to preventing cavities.
  • 33 Stimmen
    15 Beiträge
    148 Aufrufe
    E
    And they all suck, my boss is still alive.
  • 300 Stimmen
    71 Beiträge
    787 Aufrufe
    T
    Time to head for greener pastures.
  • How a Spyware App Compromised Assad’s Army

    Technology technology
    2
    1
    41 Stimmen
    2 Beiträge
    38 Aufrufe
    S
    I guess that's why you pay your soldiers. In the early summer of 2024, months before the opposition launched Operation Deterrence of Aggression, a mobile application began circulating among a group of Syrian army officers. It carried an innocuous name: STFD-686, a string of letters standing for Syria Trust for Development. ... The STFD-686 app operated with disarming simplicity. It offered the promise of financial aid, requiring only that the victim fill out a few personal details. It asked innocent questions: “What kind of assistance are you expecting?” and “Tell us more about your financial situation.” ... Determining officers’ ranks made it possible for the app’s operators to identify those in sensitive positions, such as battalion commanders and communications officers, while knowing their exact place of service allowed for the construction of live maps of force deployments. It gave the operators behind the app and the website the ability to chart both strongholds and gaps in the Syrian army’s defensive lines. The most crucial point was the combination of the two pieces of information: Disclosing that “officer X” was stationed at “location Y” was tantamount to handing the enemy the army’s entire operating manual, especially on fluid fronts like those in Idlib and Sweida.