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

271–280 of 372 posts

Re: Left to Right Programming

#271

Post by necovek »

jibal wrote: post #258
necovek wrote: post #251

Earlier quoted context omitted.

That one is a generator[Any], and for others it could be set[Any], list[Any] or dict[Any]. You obviously don't get embedded type information, but you still do get the encapsulating type, which is better than an untyped for loop :) I get that it's about how it's structured and ordered, but that is true for the "for..in" loops in every language as well: you first set the variable, and only then get the context — this j…

"that is true for the "for..in" loops in every language as well" No, not at all. The output expression is arbitrary ... it might be f(x, y, z) where all of those are set later. You're confusing the output expression with the loop variable, which is also stated in the comprehension and may or may not be the same as the output expression or part of it. "The same model as the for loops in the language", where the langua…

These are different points.

Just like you state a variable and some operations on it early in a comprehension, you do the same in a for loop: you don't know the type of it.

As you are typing the for loop in, your IDE does not know what is coming in as a context being iterated over to auto-complete, for instance (eg. imagine iterating over tuples with "for k, v in some_pairs:" — your editor does not even know if unpacking is possible).

Basically, what I am saying is that comprehensions are similarly "bad" as for loops, except they are more powerful and allow more expression types early.

C/C++ allow even crazier stuff in the "variable's" place in a for loop. Rust allows patterns, etc.

Typing is mostly a nice addendum I mentioned, that's not the core of my point.

Re: Left to Right Programming

#272

Post by necovek »

jibal wrote: post #258
necovek wrote: post #251

Earlier quoted context omitted.

That one is a generator[Any], and for others it could be set[Any], list[Any] or dict[Any]. You obviously don't get embedded type information, but you still do get the encapsulating type, which is better than an untyped for loop :) I get that it's about how it's structured and ordered, but that is true for the "for..in" loops in every language as well: you first set the variable, and only then get the context — this j…

"that is true for the "for..in" loops in every language as well" No, not at all. The output expression is arbitrary ... it might be f(x, y, z) where all of those are set later. You're confusing the output expression with the loop variable, which is also stated in the comprehension and may or may not be the same as the output expression or part of it. "The same model as the for loops in the language", where the langua…

Note that I am not disputing the order is "inversed": all I am saying is that there are other common language features in most languages where things don't flow the same way, yet nobody finds it a huge problem.

It's like discussion of RPN or infix for calculations: both do the job, one is more rigorous and clear with no grouping/parentheses, yet we manage just fine with infix operators in our programming languages (or maybe not, perhaps all bugs are due to this? :)).

Re: Left to Right Programming

#273

Post by Sammi »

throwitaway1123 wrote: post #130
Zarathruster wrote: post #52

On the other hand, Python does have "from some_library import child_module" which is always nice. In JS we get "import { asYetUnknownModule } from SomeLibrary" which is considerably less helpful.

Alternatively, with namespace imports in JS you can write [1]: import * as someLibrary from "some-library" someLibrary.someFunction() Which works pretty well with IDE autocomplete in my experience. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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.

Re: Left to Right Programming

#274

Post by xelxebar »

jibal wrote: post #261
xelxebar wrote: post #252

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…

"Reasons, sure, but whether those reasons correlate with things that matter is a different question altogether." Thus my word "suggests". Thus the comprehensive pro/con list. I'm not here to defend tiresome strawmen.

It's not so much a matter of exhaustively listing pros and cons, but more a matter of appropriateness to the desired goal or goals IME. I seriously doubt that a comprehensive pro/con list can even be coherent. Is dynamic typing a pro or a con? Depends on to whom and even in what decade you ask. List comprehensions? Interpreted language? First class OOP? Any cost-benefit anaylsis will be highly context-dependent.

> I'm not here to defend tiresome strawmen.

I won't point out that you already tried to (contradiction intended). Perhaps a more interesting discussion would result if we defaulted to a more collaborative[0] stance here?

[0]:https://en.wikipedia.org/wiki/Cooperative_principle

Re: Left to Right Programming

#275

Post by Pxtl »

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…

My other big dream would be allowing multiple WHERE clauses that would be semantically ANDed together because that's what would happen if you filtered a result set twice.

Re: Left to Right Programming

#276

Post by IshKebab »

mb7733 wrote: post #95
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 used to agree with this completely, but type annotations & checking have made it much more reasonable. I still wouldn't choose it for a large project, but types have made it much, much easier to work with others' python code. Python with strict type checking and its huge stdlib is my favourite scripting language now.

I agree, it's not too bad if you enable strict Pyright checking in CI, and you use `uv` and you don't care remotely about performance.

That's quite a lot of ifs though. Tbh I haven't found anything significantly better for scripting though. Deno is pretty nice but Typescript really has just as many warts as Python. At least it isn't so dog slow.

Re: Left to Right Programming

#277

Post by Pxtl »

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

Python was established as a fun and sensible language that was usable and batteries-included at a time when everything else was either expensive or excruciating, and has been coasting in that success ever since. If you'd only coded in bash, C/C++, and late-'90s Java, Python was a revelation.

Lists comprehensions were added to the language after it was already established and popular and imho was the first sign that the emperor might be naked.

Python 3 was the death of it, imho, since it showed that improving the language was just too difficult.

Re: Left to Right Programming

#278

Post by bazoom42 »

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

More likely because this order is closer to typical English sentence structure. SQL was designed to look like English, not relational algebra.

Re: Left to Right Programming

#279

Post by Pxtl »

IshKebab wrote: post #276
mb7733 wrote: post #95

Earlier quoted context omitted.

I used to agree with this completely, but type annotations & checking have made it much more reasonable. I still wouldn't choose it for a large project, but types have made it much, much easier to work with others' python code. Python with strict type checking and its huge stdlib is my favourite scripting language now.

I agree, it's not too bad if you enable strict Pyright checking in CI, and you use `uv` and you don't care remotely about performance. That's quite a lot of ifs though. Tbh I haven't found anything significantly better for scripting though. Deno is pretty nice but Typescript really has just as many warts as Python. At least it isn't so dog slow.

I've pretty much embraced PowerShell for scripting. The language is warty as hell and seems to be entirely made of sharp edges but I've gotten used to it and it does have a lot of excellent ideas.

Re: Left to Right Programming

#280

Post by balfirevic »

9rx wrote: post #234
balfirevic wrote: post #184

Earlier quoted context omitted.

> 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 y…

> You can write the relational algebra operators in any order you want Ultimately, yes, you can express relational algebra in any notation that gets the point across, but the parent is right that π₁(R) is what is commonly used. (R)π₁ not so much. Even Codd himself used the former notation style in his papers, even though he settled on putting the relation first in his query language.

My impression was the parent poster was talking about order of operations like projection and selection, where you might more commonly write:

Π(σ(R)) instead of σ(Π(R))

and not about whether relational algebra uses prefix or postfix notation:

Π(σ(R)) vs. R > σ > Π

SQL's WHERE statement (and others) works totally differently from SELECT in that regard, so it doesn't make much sense to say that "SELECT comes first because relational algebra".

Post reply on HN