Live data from Hacker News

Left to Right Programming

graic.net

331–340 of 372 posts

Re: Left to Right Programming

#331
post #293
post #199

This is almost FP vs OOP religious war in disguise. Similar to vim-vs-emacs ... where op comes first in vim but selection comes first in emacs. If you design something to "read like English", you'll likely get verb-first structure - as embodied in Lisp/Scheme. Other languages like German, Tamil use verbs at the end, which aligns well with OOP-like "noun first" syntax. (It is "water drink" word for word in Tamil but "…

> Other languages like German, Tamil use verbs at the end Doesn't German have the main verb on the second position? (For a simple example, "I drink water" would be "Ich trinke Wasser")

Inviting native German speakers to comment. Of course we anglophone-only HN geniuses can answer cesarb's question brilliantly on our own. But perhaps as a little sidebar we could also get your 'opinion'. Thanks! /s

Re: Left to Right Programming

#333

Earlier quoted context omitted.

Did you ever not do things like select name, min(price) from product join product_price on product.id = product_price.product_id where you start with "I need a product name and minimum price" before thinking about where they come from? The more one uses SQL to filter for, the more you'll think about what you want to achieve vs how (which comes after): in a sense, the SELECT is your function return type declaration, a…

> where you start with "I need a product name and minimum price" before thinking about where they come from? Sure, and pretty much every time the names I wrote up were not the ones in the table so that was a complete waste of time. > the SELECT is your function return type declaration That might be true if “select” only contained aliases, bur that’s not the case at all, so what it is is complete nonsense.

This presumes that you never pick the wrong table, as well? :D

My argument would be largely that you are doing a search of all of the tables for the columns that you want. With having to know the way to join the necessary tables along the way.

And I want to be clear, I don't think this is necessarily "the way." I more think that it is almost certainly an iterative process that can be started at either place, and will require bouncing between the two quite often.

For instance, yes, you can autocomplete column names from tables that you have put in the from. What if you can't find the column you are anticipating there? Go back and rescan the table names hoping you can guess which table should have the column you want? Then go back to autocomplete for columns to see if expected value appears? Or go to a bit more of a global search for columns?

Either way should be fine.

Re: Left to Right Programming

#334

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...

> I was explaining why it is the way that it is.

No one was confused what you were doing.

I'm saying the historical reason for why it is the way it is, doesn't matter. I would hope we design our languages to be maximally clear and useful, not to be maximally full of historical cruft.

There's no accounting for taste, so you're welcome to like whatever you like, but I don't think you liking a backward syntax is particularly persuasive. It sounds more like you're just used to it than that you see any actual benefits to it.

Re: Left to Right Programming

#336

Earlier quoted context omitted.

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.

Fair enough. And like I said, you're argument is certainly better than the article's. I'm not really a fan of list comprehensions, I usually just use for loops. It does seem consistent with Pythons syntax though. For loop is `for item in items` and comprehensions have 'item for item in items'.

Nim has a macro in the standard library that allows you to use the actual for loop syntax as a comprehension.

  let primeSquares = collect:
    for n in 1..100:
      if n.isPrime():
        n * n

Re: Left to Right Programming

#337
post #283

Earlier quoted context omitted.

> That it does get a lot of love strongly suggests that there are reasons for that. Reasons, sure, but whether those reasons correlate with things that matter is a different question altogether. Python has a really strong on-ramp and, these days, lots of network effects that make it a common default choice, like Java but for individual projects. The rub is that those same properties—ones that make a language or codeb…

I'm not a hater, but also not the biggest fan of bash. What do you consider its pros and cons? Pros: easy to interact with different tools, included in many Unix OSs, battle tested. Cons: complex stuff gets messy, with weird syntax, hard to do logic, hard to escape everything correctly

Pro - there is still not another language (generalizing to "shell" here) that allows you to easily write a series of commands and/or pipelines as concisely and understandably as shell.

This is the biggest reason to use shell - if your task is shaped like a command line session with a bit of looping or a few conditionals, shell is perfect.

If you start nesting loops or conditionals in shell, then start considering another language.

Re: Left to Right Programming

#338
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…

I've always liked the `select...from` order because it helps me understand the goal before reading the logic. In other words, I want to end up with this, and here's how I want to go about getting it.

Re: Left to Right Programming

#339

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…

Is the q solution equivalent? In doing a plus scan, isn't the last element always going to be the largest? To find the largest subarray sum, I would think you'd want to split into a matrix along the `null`s first and then plus reduction and then a max of those results.

Say what you will about clarity, but my mind sort of glossed over the intention in the python and rust code, focusing instead on the syntax, while the q code made me consider what was actually happening.

Re: Left to Right Programming

#340

Earlier quoted context omitted.

I can’t think of an example where I knew the columns I wanted to select before I knew which table I wanted to select them from.

Did you ever not do things like select name, min(price) from product join product_price on product.id = product_price.product_id where you start with "I need a product name and minimum price" before thinking about where they come from? The more one uses SQL to filter for, the more you'll think about what you want to achieve vs how (which comes after): in a sense, the SELECT is your function return type declaration, a…

Nope.
Post reply on HN