Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Left to Right Programming

graic.net

Post reply on HN
Print view View original

81–90 of 372 posts

Re: Left to Right Programming

#81

Post by scuff3d »

xigoi wrote: post #28
scuff3d wrote: post #4

I don't think making your tools happy is a particularly valid reason to code in one style vs another.

Left-to-right is also much easier to wrap your head around. Just imagine the data going on a conveyor belt with a bunch of machines instead of having to wrangle a nested tree.

A not insignificant number of functional languages disagree. You often read functional code from the inside out, which basically means you're reading right to left as you move up function calls.

For the record though, "it's more readable" is a much better argument then "LSP mad"

Re: Left to Right Programming

#82

Post by Someone »

sgarland wrote: post #69

Is the entire complaint that autocomplete doesn’t work well? Have you tried learning your language?

It’s more about learning the language’s library, which typically is too large to remember in detail, than about learning the language, which typically is small enough for that.

Re: Left to Right Programming

#83

Post by xg15 »

I think the most absurd syntax goes to Python again.

Python offers an "extended" form of list comprehensions that lets you combine iteration over nested data structures.

The irony is that the extensions have a left-to-right order again, but because you have to awkwardly combine them with the rest of the clause that is still right-to-left, those comprehensions become completely unreadable unless you know exactly how they work.

E.g., consider a list of objects that themselves contain lists:

  toolboxes = [
    Box(tools=["hammer"]),
    Box(tools=["wrench", "screwdriver"])
  ]
To get a list of lists of tools, you can use the normal comprehension:

  toolsets = [b.tools for b in toolboxes]
But to get a single flattened list, you'd have to do:

  tools = [t for b in toolboxes for t in b.tools]
Where the "t for b" looks utterly mystifying until you realize the "for" clauses are parsed left-to-right as

  [t (for b in toolboxes) (for t in b.tools)]
while the "t" at the beginning is parsed right-to-left and is evaluated last.

Re: Left to Right Programming

#84

Post by pjmlp »

juancn wrote: post #39

SQL shows it's age by having exactly the same problem. Queries should start by the `FROM` clause, that way which entities are involved can be quickly resolved and a smart editor can aid you in writing a sensible query faster. The order should be FROM -> SELECT -> WHERE, since SELECT commonly gives names to columns, which WHERE will reference. You could even avoid crap like `SELECT * FROM table`, and just write `FROM…

Kusto, the Azure query language for data analysis uses that form with piping as well.

https://learn.microsoft.com/en-us/kusto/query/?view=microsof...

Also the LINQ approach in .NET.

I do agree, that is about time that SQL could have a variant starting with FROM, and it shouldn't be that hard to support that, it feels like unwillingness to improve the experience.

Re: Left to Right Programming

#85

Post by papercrane »

rspencer wrote: post #73

I had a similar thought a few years ago with an Advent of Code problem for which my solution in python might have been max(map(sum, input_list.split(None))) To decipher this the eye has to jump to the middle of the line, move rightwards, then to the left to see the "map" then move right again to see what we are mapping and then all the way to the beginning to find the "max". The author would probably suggest rust's s…

> Though neither python nor rust have such a nice `.split(None)` built in.

Sorry, I'm not sure I understand what `.split(None)` would do? My initial instinct is that would would return each character. i.e. `.chars()` in Rust or `list(s)` in Python.

Re: Left to Right Programming

#86

Post by pjmlp »

layer8 wrote: post #45
juancn wrote: post #39

SQL shows it's age by having exactly the same problem. Queries should start by the `FROM` clause, that way which entities are involved can be quickly resolved and a smart editor can aid you in writing a sensible query faster. The order should be FROM -> SELECT -> WHERE, since SELECT commonly gives names to columns, which WHERE will reference. You could even avoid crap like `SELECT * FROM table`, and just write `FROM…

While I agree, some SQL editors do provide code completion for the SELECT clause if you type the FROM clause first.

That is my trick as well, but feels backwards, by now there could be a variant of SQL supporting FROM first.

Re: Left to Right Programming

#87

Post by lackoftactics »

juancn wrote: post #39

SQL shows it's age by having exactly the same problem. Queries should start by the `FROM` clause, that way which entities are involved can be quickly resolved and a smart editor can aid you in writing a sensible query faster. The order should be FROM -> SELECT -> WHERE, since SELECT commonly gives names to columns, which WHERE will reference. You could even avoid crap like `SELECT * FROM table`, and just write `FROM…

This was a historical decision because SQL is a declarative language. I was confused for too long, I want to admit, about the SQL order: FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT

As a self-taught developer, I didn't know what I was missing, but now the mechanics seem clear, and if somebody really needs to handle SELECT with given names, then he should probably use CTE:

WITH src AS (SELECT * FROM sales), proj AS (SELECT customer_id, total_price AS total FROM src), filt AS (SELECT * FROM proj WHERE total > 100) SELECT * FROM filt;

Re: Left to Right Programming

#88

Post by marcosdumay »

juancn wrote: post #39

SQL shows it's age by having exactly the same problem. Queries should start by the `FROM` clause, that way which entities are involved can be quickly resolved and a smart editor can aid you in writing a sensible query faster. The order should be FROM -> SELECT -> WHERE, since SELECT commonly gives names to columns, which WHERE will reference. You could even avoid crap like `SELECT * FROM table`, and just write `FROM…

The order should be starting on FROM, followed by any sequences of whatever clauses (except for FROM), always creating an intermediary result-set.

FROM table -- equivalent to today's select * from table

SELECT a, 1 as b, c, d -- equivalent to select ... from table

WHERE a in (1, 2, 3) -- the above with the where

GROUP BY c -- the above with the group by

WHERE sum(d) > 100 -- the above with having sum(d) > 100

SELECT count(a distinct) qt_a, sum(b) as count, sum(d) total_d -- the above being a sub-query this selects from

Re: Left to Right Programming

#90

Post by sgarland »

Someone wrote: post #82
sgarland wrote: post #69

Is the entire complaint that autocomplete doesn’t work well? Have you tried learning your language?

It’s more about learning the language’s library, which typically is too large to remember in detail, than about learning the language, which typically is small enough for that.

The complaints listed seem to focus on attributes / methods of a class. You can read Python’s docs, and see the methods available to a str type, for example.

To me, that’s learning the language. Learning its library would be more like knowing that the module `string` contains the function `capwords`, which can be used to - as the name suggests - capitalize (to title case) all words in a string. Hopefully, one would also know that the `str` class contains the method `upper`, so as not to confuse it with `string.capwords`.

Post reply on HN