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

181–190 of 372 posts

Re: Left to Right Programming

#181

Post by AdieuToLogic »

It seems to me what the author desires is linguistic support for the Thrush combinator[0]. Another colloquial name for it is "the pipe operator."

Essentially, what this combinator does is allow expressing a nested invocation such as:

  f(g(h(x)))
To be instead:

  h(x) |> g |> f
For languages which support defining infix operators.

EDIT:

For languages which do not support defining infix operators, there is often a functor method named `andThen` which serves the same purpose. For example:

  h(x).andThen(g).andThen(f)
0 - https://leanpub.com/combinators/read#leanpub-auto-the-thrush

Re: Left to Right Programming

#182

Post by [deleted] »

Twey wrote: post #63
Terr_ wrote: post #54

That's fine for doing algebra in pure functions, but what about destructive commands or interactive scenarios? For example, using "rm" on the command line, or an SQL "delete". I would very much like those short programs to be invalid , until someone provides more detail about what should be destroyed in a way that is accident-resistant. If I had my 'druthers, the left-to-right prefix of "delete from table" would be i…

The solution suggested by the author, I assume, is `table.where(true).delete()` and `all_my_data.rm()`, which indeed has the property you describe.

[deleted]

Re: Left to Right Programming

#183

Post by jagged-chisel »

sgarland wrote: post #123
kerkeslager wrote: post #105

Earlier quoted context omitted.

> It's written that way because it stems from relational algebra, in which the projection is typically (always?) written first. Okay, so what? We're not obligated to emulate the notational norms of our source material, and it is often bad to do so when context changes.

I was explaining why it is the way that it is. If you'd like your own version of a parser, here's Postgres' [0]. Personally, I really like SQL's syntax and find that it makes sense when reading it. [0]: https://github.com/postgres/postgres/tree/master/src/backend...

There was not argument about how much sense it makes. There was an argument for improving readability by placing the table names first.

Lots of people “like” things because they are familiar with them. And that’s a fine enough reason. But if you step out of your zone of familiarity, can you find improvements? Are you willing to forgo any prejudice you may possess to evaluate other suggestions?

Just a little willingness to see another perspective is all anyone asks.

Re: Left to Right Programming

#184

Post by balfirevic »

sgarland wrote: post #79
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…

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, in which the projection is typically (always?) written first.

It's inspired by a mish-mash of both relational algebra and relational calculus, but the reason why SELECT comes first is because authors wanted it to read like English (it was originally called Structured English Query Language).

You can write the relational algebra operators in any order you want to get the result you want.

Re: Left to Right Programming

#185

Post by AdieuToLogic »

marcosdumay wrote: post #88
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…

How would this approach support SQL constructs such as the HAVING[0] clause? Or is that what you meant by:

  WHERE sum(d) > 100 -- the above with having sum(d) > 100
0 - https://www.w3schools.com/sql/sql_having.asp

Re: Left to Right Programming

#186

Post by atq2119 »

aquafox wrote: post #72

The consensus here seems to be that Python is missing a pipe operator. That was one of the things I quickly learned to appreciate when transitioning from Mathematica to R. It makes writing data science code, where the data are transformed by a series of different steps, so much more readable and intuitive. I know that Python is used for many more things than just data science, so I'd love to hear if in these other co…

The next step after pipe operators would be reverse assignment statements to capture the results.

I find myself increasingly frustrated at seeing code like 'let foo = many lines of code'. Let me write something like 'many lines of code =: foo'.

Re: Left to Right Programming

#187

Post by dragonwriter »

sgarland wrote: post #91
marcosdumay wrote: post #88

Earlier quoted context omitted.

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…

> always creating an intermediary result-set You want the DB to first run SELECT * FROM , and then start operating on that?

Presumably, the intermediate result sets would necessary be materialized, only logical.

Re: Left to Right Programming

#188

Post by robmccoll »

hnlmorg wrote: post #96
xigoi wrote: post #23

Earlier quoted context omitted.

It’s a good language for beginners and, unfortunately, many people think that learning more languages is hard and useless.

That’s also precisely the reason why we have the clusterfuck that is the JavaScript ecosystem. People complain that we can’t have nice things. But even when we do, enough developers will be lazy enough not to learn them anyway.

I'd argue it's because the web is the dominant platform for many applications and no other languages can offer a first class experience. if WASM had direct access to the DOM and web APIs and maybe a little more runtime support to lessen the bloat, I'd use something else.

Re: Left to Right Programming

#189

Post by shkkmo »

taeric wrote: post #167
jayd16 wrote: post #159

Earlier quoted context omitted.

If my boss asks me for a zip code, I'm going to ask "for what?" If they ask for "address for a customer" I can go to the customer table and look up what FKs are relevant and collect all possible data and then narrow down from there.

I'd assume they would ask for "aggregate sales by month to zip codes," or some such. Which, you'd probably get from a reporting table, and not bother trying to do the manual aggregate over transactional data. (That is, OLAP versus OLTP is a very real divide that you can't wave away.) Realistically, I strongly suspect you could take this argument either direction. If you have someone making a query where they are havi…

Your approach only works with massive assumptions about the structure of the data or a very simplistic data structure.

SELECT statments don't just use table names, they can use aliases for those table names, views, subqueries, etc.

The FROM / JOIN blocks are where the structure of the data your are selecting from is defined. You should not assume you understand what a SELECT statement means until you have read those blocks.

Re: Left to Right Programming

#190

Post by lock1 »

michaelfeathers wrote: post #124

This is called point-free style in Haskell. Sometimes it is called a fluent-interface in other languages.

Or "point-less" style ;)

Could you elaborate? AFAIK tacit programming tend to be scrambling around composition, paren, and args which makes left-to-right reading significantly harder for function with arity greater than 2.

I find Java's method reference or Rust's namespace resolution + function as an argument much better than Haskell tacit-style for left-to-right reading.

Post reply on HN