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

351–360 of 372 posts

Re: Left to Right Programming

#351

Post by hansvm »

baalimago wrote: post #214

You don't need to be bothered with minute details such as syntax for counting string length anymore, you just need to know what you want to do. I mention this since OP is bringing up LSP's as an argument for why certain language's design is suboptimal. "Count length of string s" -> LLM -> correct syntax for string-count for any programming language. This is the perfect context-length for an LLM. But note that you don…

I don't think that meaningfully engages with the author's point.

If you already know how to compute `len` on some arbitrary syntax soup then the difference is just a minor annoyance where you have to jump back in your editor, add a function call and some punctuation, and jump back to where you were to add some closing punctuation. It's so fast you'd never bother with an LLM, so despite real and meaningful differences existing the LLM discussion point isn't relevant.

If you don't know how to compute `len` on some arbitrary syntax soup, I don't see how crafting an ideal prompt in a "full (very isolated) context" is ever faster than tab-completing things which look like "count" or "len."

Re: Left to Right Programming

#352

Post by juancn »

0x696C6961 wrote: post #93
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 doesn't seem like it would be all that difficult to allow that form in a backwards compatible way. Why hasn't this happened?

Not sure. It seems a fairly basic syntax change and it could even be easily made backwards compatible.

Now we need to get the ANSI SQL committee to standardize it ANSI SQL 2027 or some such.

Re: Left to Right Programming

#353

Post by Izkata »

shkkmo wrote: post #344
necovek wrote: post #206

Earlier quoted context omitted.

As GP said, you can take this both ways. I can define the return format of my query in the SELECT statement, then adapt the data structure in the FROM block using subselects, aliases etc — all to give me the shape desired for the query. If you've ever done complex querying with SQL, you'd know that you'd go back and forth on all parts of the query to get it right unless you knew the relations by heart, regardless of…

> As GP said, you can take this both ways. You can, but one of those ways is objectively worse for the reasons explained in this thread and in the article. When you have to read a query out of order to understand it then something is wrong with the structure of the query language.

And the objectively worst way is to put the SELECT in the middle, because it ignores the relationship between the query and the rest of the code that interacts with it, making it more difficult to read - and reading the code is done a lot more than writing the code.

Re: Left to Right Programming

#354

Post by hnlmorg »

sureglymop wrote: post #247
hnlmorg wrote: post #240

Earlier quoted context omitted.

> But what if there end up being too many options? That would suggest the file object needs to be refactored and split. > What's next, a fuzzy finding search box for all possible functions? Contextually relevant ones based on the code you've already written? IDEs already provide both those options.

I understand, I think I moreso wanted to hint that there may still be more room for exploration when it comes to things like this. However, while I agree, I do want to challenge you to explain/show if and why this is the case (I know that you wrote "suggest"): > That would suggest the file object needs to be refactored and split.

I don’t want to overly generalise because there aren’t such things as absolutes with programming. But this was the thinking behind my comment:

If you have dozens of methods then that might be an indicator that your object is too large in size and thus consumes too much memory even for simple tasks.

It also might be a symptom that you’re trying to do too much with that object so perhaps some methods should be generalised, if possible.

Or maybe the object is already too generalised and what you actually need is a more specific object that inherits some of the initial objects design?

It might be that some of those methods should have been private, or even functions.

Ultimately, it could be an indicator that the object is either badly designed or has evolved to the point that it’s now ready for a refactor.

But it could also be the most optimal way to approach that problem too. In some situations. However it’s a good point to pause and reflect on whether the pain/reward threshold has been crossed.

Re: Left to Right Programming

#355

Post by mamcx »

sgarland wrote: post #147
mamcx wrote: post #134

Earlier quoted context omitted.

> 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

You are correct in that is the notation used, but that is not how it goes internally!

Re: Left to Right Programming

#356

Post by sorrythanks »

kmoser wrote: post #101
astrange wrote: post #46

Earlier quoted context omitted.

I agree with this, but it leads to another principle that too many languages violate - it shouldn't fail to compile just because you haven't finished writing it! It should fail in some other non-blocking way. But some languages just won't let you do that, because they put in errors for missing returns or unused variables.

How is it supposed to compile if you've written something syntactically invalid? You can make the argument that the compiler could interpret it in (perhaps even arbitrary) valid way that constitutes a valid syntax, but that's almost worse: rather than being chided with compiler warnings, you now end up with code that compiles but executes indeterminately.

Perhaps we are talking about programming with holes:

https://hazel.org/

Re: Left to Right Programming

#357

Post by AdieuToLogic »

corank wrote: post #341
AdieuToLogic wrote: post #181

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…

As I understand it this is precisely why in Haskell and OCaml standard libraries we get lots of things like map : (a -> b) -> a list -> b list instead of map : a list -> (a -> b) -> b list The main argument (data to be operated on) is positioned last, after the others which are more like parameters that tune the function. It's to allow chaining these things up left to right like Unix pipes: map f l |> filter g |> ...

Great point.

The technique of currying method parameters such that the last one is the input to the operation also makes chaining Kleislis[0] quite nice, albeit using a bind operator (such as `>>=`) instead of the Thrush combinator operator (`|>`).

0 - https://bartoszmilewski.com/2014/12/23/kleisli-categories/

Re: Left to Right Programming

#358

Post by ChadNauseam »

necovek wrote: post #207
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

The same reason people are not flocking to the Lisps of the world: mathematical rigour and precision does not translate to higher legibility and understandability. Python's list /dict/set comprehensions are equivalent to typed for loops: where everyone complains about Python being lax with types, it's weird that one statement that guarantees a return type is now the target. Yet most other languages don't have the "pr…

> Yet most other languages don't have the "properly ordered" for loop, Rust included (it's not "from iter as var" there either).

The relative order of the variable being iterated on and the loop variable name is not relevant to OP's complaint. OP only requires that the expression which uses the loop variable comes after both, which is the case in Rust.

Re: Left to Right Programming

#359

Post by account42 »

dleeftink wrote: post #49
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…

PSQL (and PRQL) use this ordering, and a similar pipe/arrow notation has recently been added to BigQuery. Check out the DuckDB community extensions: [0]: https://duckdb.org/community_extensions/extensions/psql.html [1]: https://duckdb.org/community_extensions/extensions/prql.html

An unfortunate name when PSQL is already a commonly used shorthand (including the official client command name) for a competing SQL-based database engine.

Re: Left to Right Programming

#360

Post by rspencer »

adregan wrote: post #339
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…

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…

It is equivalent because it's not a plus-scan but a (0^+)-scan which resets every time it hits a null (there's a more in depth explanation here https://robertandrewspencer.com/aoc_2022_1/ )

Perhaps q did both force you to consider what was happening, and hide it from you...

Post reply on HN