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

141–150 of 372 posts

Re: Left to Right Programming

#141

Post by ivanjermakov »

andsoitis wrote: post #119

> Programs should be valid as they are typed. Not possible. There are more keystrokes that result in invalid programs (you are still writing the code!!) than keystrokes that result in a valid program. More seriously, I do think that one consideration is that code is read more often that written, so fluidity in reading and comprehension seem more important to me than “a program should be valid after each keystroke.

Typing goes in the same directions as reading, so I expect many benefits to apply to both. But I agree that readability is much more important than writeability.

Re: Left to Right Programming

#142

Post by jayd16 »

taeric wrote: post #125
Zedseayou wrote: post #118

Earlier quoted context omitted.

Can you help me understand this situation? Almost always what I want to select is downstream of what I am selecting from, I can't write anything in SELECT until i understand the structure/columns available in FROM.

"I want 'first_name, last_name, and average(grade)' for my report." That is easy enough to state without knowing anything about how the data is normalized. Back when I worked to support a data science team, I actually remember taking some of their queries and stripping everything but the select so that I could see what they were trying to do and I could add in the correct parts of the rest.

This assumes I have all the column memorized but not all the tables?

Even in your example, first and last could refer to student or teacher. But presumably you know you're looking for student data before knowing the exact columns.

Re: Left to Right Programming

#143

Post by taeric »

mamcx wrote: post #137
taeric wrote: post #125

Earlier quoted context omitted.

"I want 'first_name, last_name, and average(grade)' for my report." That is easy enough to state without knowing anything about how the data is normalized. Back when I worked to support a data science team, I actually remember taking some of their queries and stripping everything but the select so that I could see what they were trying to do and I could add in the correct parts of the rest.

Even assuming that this is plausible way a user could think about it (that can be understood) it shows why is bad Think: I have 20 tables with the column `id` "I want 'id,id,id'" is bad UX, and is what here is being argued, then when the syntax guide you: "I want 'FROM a: id'" is better

I don't think anyone would ever say they want "id, id, id"? They would say they want "customer_id, order_id, item_id" or some such. You would then probably say, "we just use 'id' for the id of every item..." but many places that I've worked actually explicitly didn't do that for essentially this reason. Natural joins on "foo_id" "just work" if you don't give every table the same "id" column.

Re: Left to Right Programming

#144

Post by Philpax »

scuff3d wrote: post #81
xigoi wrote: post #28

Earlier quoted context omitted.

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"

Right-to-left is equivalent to left-to-right in this regard: you're still reading in one linear direction, as opposed to Python, where you have to read inside-out and revisit later parts of the line to correctly understand previous parts of the line.

Re: Left to Right Programming

#145

Post by Philpax »

williamscales wrote: post #26
danielPort9 wrote: post #21

Don’t know why python gets so much love. It’s a painful language as soon as more than one person is involved. What the author describes is just the tip of the iceberg

I find myself writing a very simple style of python that avoids list comprehensions and so on when working in a shared code base. For a language where there is supposed to be only one way to do things, there are an awful lot of ways to do things. Don’t get me wrong, writing a list comprehension can be very satisfying and golf-y But if there should be one way to do things, they do not belong.

If I have to write Python like Go, I'd rather just write Go. (Not disagreeing with you, but this is one of many reasons that Python is the least-favourite language that I use on a regular basis.)

Re: Left to Right Programming

#146

Post by Philpax »

SkepticalWhale wrote: post #25
danielPort9 wrote: post #21

Don’t know why python gets so much love. It’s a painful language as soon as more than one person is involved. What the author describes is just the tip of the iceberg

Maybe even painful for one dev once you need dependencies (virtualenv...)

Thankfully, uv makes this a lot better, but it'll still be a while before that percolates to the entire ecosystem, if ever.

There are real concerns about tying the language's future to a VC-backed project, but at the same time, it's just such an improvement on the state of things that I find it hard not to use.

Re: Left to Right Programming

#147

Post by sgarland »

mamcx wrote: post #134
sgarland wrote: post #79

Earlier quoted context omitted.

It's written that way because it stems from relational algebra, in which the projection is typically (always?) written first. >The order should be FROM -> SELECT -> WHERE, since SELECT commonly gives names to columns, which WHERE will reference. Per the SQL standard, you can't use column aliases in WHERE clauses, because the selection (again, relational algebra) occurs before the projection. > You could even avoid cr…

> It's written that way because it stems from relational algebra, A common misconception (that SQL is a realization of RA instead of barely based on it). In RA, is in fact `Relation > Operator`

Unless I am grossly misunderstanding your notation, I have always seen RA written with the operator first. Some examples:

https://cs186berkeley.net/notes/note6/

https://web.wlu.ca/science/physcomp/ikotsireas/CP465/W1-Intr...

https://home.adelphi.edu/~siegfried/cs443/443l9.pdf

Re: Left to Right Programming

#148

Post by taeric »

jayd16 wrote: post #142
taeric wrote: post #125

Earlier quoted context omitted.

"I want 'first_name, last_name, and average(grade)' for my report." That is easy enough to state without knowing anything about how the data is normalized. Back when I worked to support a data science team, I actually remember taking some of their queries and stripping everything but the select so that I could see what they were trying to do and I could add in the correct parts of the rest.

This assumes I have all the column memorized but not all the tables? Even in your example, first and last could refer to student or teacher. But presumably you know you're looking for student data before knowing the exact columns.

No, this assumes you know what you want for a query. Which, seems largely fair?

Like, how would you send this question to someone? Or how would you expect it to be sent to you? If your boss doesn't tell you from what table they want some data, do you just not answer?

And sure, there could be ambiguities here. But these are not really fixed by listing the sources first? You would almost certainly need to augment the select to give the columns names that disambiguate for their uses. For example, when you want the teacher and the student names, both.

And this is ignoring more complications you get from normalized data that is just flat out hard to deal with. I want a teacher/student combination, but only for this specific class and term, as an example. Whether you start the from at the student, the class, or the term rosters feels somewhat immaterial to how you want to pull all of that data together for why ever you are querying it.

Re: Left to Right Programming

#149

Post by Philpax »

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…

Rust doesn't have it built in, but it's part of itertools: https://docs.rs/itertools/latest/itertools/trait.Itertools.h...

This may eventually be upstreamed: https://github.com/rust-itertools/itertools/issues/1026

Re: Left to Right Programming

#150

Post by taeric »

jayd16 wrote: post #139
taeric wrote: post #106

Earlier quoted context omitted.

My main caveat here, is that often the person starting a select knows what they want to select before they know where to select it from. To that end, having autocomplete for the sources of columns is far far more useful than autocomplete for columns from a source. I will also hazard a guess that the total number of columns most people would need autocomplete for are rather limited? Such that you can almost certainly…

Seems nonsensical. Column names have no meaning without the table. Table is the object, columns are the properties. What language goes Property.Object? All popular languages have this wrong?

I'm assuming you are largely just not thinking this one through? We are not modeling the domain, we are describing some data we want to select. Without knowing how it is modeled, I can give a brief "top line" for expected select statements on many data models. "I want average_weather, year, zip_code", "I want year, college_name, degree_name, median_graduate_salary, mean_graduate_salary", "..."

I don't think it is tough to describe many many reports of data that you would want in this way. Is it enough for you to flat out get the answer? No, of course not. But nor is it enough to just start all queries at what possible tables you could use as a starting point.

Post reply on HN