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

341–350 of 372 posts

Re: Left to Right Programming

#341

Post by corank »

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

Re: Left to Right Programming

#343

Post by jonnycomputer » 

    len(list(filter(lambda line: all([abs(x) >= 1 and abs(x)  0 for x in line]) or all([x
Well, point taken about the ordering, but there are many more legible ways to have written that code. Not everything has to be a one liner.

even:

    def f(diffs):
        cond = lambda line: all([1  0 for x in line]) or all([x

Re: Left to Right Programming

#344

Post by shkkmo »

necovek wrote: post #206
shkkmo wrote: post #189

Earlier quoted context omitted.

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…

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.

Re: Left to Right Programming

#345

Post by throwitaway1123 »

sebws wrote: post #300
Sammi wrote: post #273

Earlier quoted context omitted.

This is a non starter for anything you want to publish online, as it breaks tree shaking which will cause size bloat and therefore slow loading.

I don't think this is true. The example from the esbuild docs uses `import * as lib from './lib.js'` in an example for tree shaking. https://esbuild.github.io/api/#tree-shaking Although there are associated issues but they may be specific to esbuild. https://github.com/evanw/esbuild/issues/1420

Yes, as you pointed out, not only can bundlers tree shake namespace imports, but they're literally used in the esbuild documentation to demonstrate the concept of tree shaking.

The issue you linked to is referring to the case in which you import a namespace object and then re-export it. Bundlers like webpack and rollup (which vite uses in production) can tree shake this pattern as well, but esbuild struggles with it.

If you're using esbuild instead of this:

  import * as someLibrary from "some-library"
  someLibrary.someFunction()
  export { someLibrary }
You can still do this:

  import * as someLibrary from "some-library"
  someLibrary.someFunction()
  export * from "some-library"
  export { default as someLibraryDefault } from "some-library"
Tree shaking works as expected for downstream packages using esbuild in the second case, which someone else in the linked issue pointed out: https://github.com/evanw/esbuild/issues/1420#issuecomment-96...

Re: Left to Right Programming

#346

Post by mamcx »

taeric wrote: post #143
mamcx wrote: post #137

Earlier quoted context omitted.

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.

That is what the syntax allow. And is the user that need to "patch" the meaning using other things like alias, renames or hopefully, proper names for fields (by the way "id, id, id" happens a lot in the wild!)

Is like "to control mutation I only need to append "mut" to the name!

Re: Left to Right Programming

#347

Post by jodrellblank »

sgarland wrote: post #314
marzell wrote: post #301

Earlier quoted context omitted.

> Per the SQL standard, you can't use column aliases in WHERE clauses, because the selection (again, relational algebra) occurs before the projection. Except this works in most major vendor SQL implementations. And they all support relation aliases in SELECT... Seems the standards have long fell behind actual implementations.

To clarify, I mean you can’t do this: SELECT id AS foo FROM MyTable WHERE foo = 1; Similarly, you can’t do this: SELECT id FROM MyTable WHERE id = MAX(id); Because in both cases, when the WHERE predicate is being executed, the engine doesn’t yet know what you’re asking it to find - for the former, SELECT hasn’t yet been called, so the alias isn’t applied; for the latter, the aggregation happens after filtering, so it…

You apparently can in SQLIte though: https://sqlfiddle.com/sqlite/online-compiler and query:

    SELECT LOWER(Name) as LName FROM Product where LName like '%frame%';

Re: Left to Right Programming

#348

Post by smilliken »

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

It's the exceptional codebase that's nice to work with when it gets large and has many contributors. Most won't succeed no matter the language. Language is a factor, but I believe a more important factor is caring a lot.

I'm working on a python codebase for 15 years in a row that's nearing 1 million lines of code. Each year with it is better than the last, to the extent that it's painful to write code in a fresh project without all the libraries and dev tools.

Your experience with Python is valid and I've heard it echoed enough times, and I'd believe it in any language, but my experience encourages me to recommend it. The advice I'd give is to care a lot, review code, and keep investing in improvements and dev tools. Git pre commit hooks (just on changed modules) with ruff, pylint, pyright, isort, unit test execution help a lot for keeping quality up and saving time in code review.

Re: Left to Right Programming

#349

Post by marzell »

sgarland wrote: post #314
marzell wrote: post #301

Earlier quoted context omitted.

> Per the SQL standard, you can't use column aliases in WHERE clauses, because the selection (again, relational algebra) occurs before the projection. Except this works in most major vendor SQL implementations. And they all support relation aliases in SELECT... Seems the standards have long fell behind actual implementations.

To clarify, I mean you can’t do this: SELECT id AS foo FROM MyTable WHERE foo = 1; Similarly, you can’t do this: SELECT id FROM MyTable WHERE id = MAX(id); Because in both cases, when the WHERE predicate is being executed, the engine doesn’t yet know what you’re asking it to find - for the former, SELECT hasn’t yet been called, so the alias isn’t applied; for the latter, the aggregation happens after filtering, so it…

You absolutely can in many engines, for instance in Snowflake... with the small exception that in all supporting engines you actually need to use HAVING instead of WHERE in your second example (because it compares an aggregation, otherwise WHERE is fine).

You can also use "correlated column aliases" (I can't recall the proper name) i.e.

    SELECT
        id AS foo,
        foo || '_1' as foo_n,
        right(foo_n, 1) as foo_ordinal
    FROM MyTable
    WHERE foo = 1;
Again, if this isn't all part of SQL standards, the reality is that a lot of engines have semi-standard (sometimes very proprietary too) ways of handling these now common patterns. For real-world use cases, the standards are unfortunately becoming increasingly irrelevant. I think it would be better in the long term to use standards, but if they can't keep up with actual usage then they will just get ignored.
Post reply on HN