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

231–240 of 372 posts

Re: Left to Right Programming

#231

Post by hnlmorg »

robmccoll wrote: post #188
hnlmorg wrote: post #96

Earlier quoted context omitted.

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.

JavaScript has been a backend language long before the web was the dominant platform.

And one of the, admittedly many, reasons why web technologies like Electron and React Native exist is because it’s easier to find JavaScript developers vs Kotin, Qt or whatever.

So youre not wrong but you’re also downplaying the network effect that led to the web becoming dominant. And a part of that was because developers didn’t want to learn something new.

Re: Left to Right Programming

#232

Post by sshine »

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…

SELECT ... FROM ... WHERE ...: S Q L

FROM ... SELECT ... WHERE ...: Q S L

Re: Left to Right Programming

#233

Post by teo_zero »

atq2119 wrote: post #186
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'.

> reverse assignment statements to capture the results

Interesting idea! However, I'm not sure I would prefer

"Mix water, flour [...] and finally you'll get a pie"

to

"To make a pie: mix water, flour [...]"

Re: Left to Right Programming

#234

Post by 9rx »

balfirevic wrote: post #184
sgarland wrote: post #79

Earlier quoted context omitted.

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

Re: Left to Right Programming

#236

Post by 9rx »

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

> If you'd like your own version of a parser, here's Postgres' [0].

Funnily enough, if you pull up a version of Postgres' parser prior to the 1995 release, you'll find that it puts the relation first.

Re: Left to Right Programming

#238

Post by rjbwork »

noosphr wrote: post #166
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

Because everything that tries to fix it is just as painful in different ways. I've had the displeasure of working in codebases using the style of programming op says is great. It's pretty neat. Until you get a chain 40 deep and you have to debug it. You either have to use language features, like show in pyspark, which don't scale when you need to trace a dozen transformations, or you get back to imperative style loop…

Debugger tooling is helpful here. Rider's debugger easily shows every intermediate result set in long chained LINQ method call chains.

Re: Left to Right Programming

#239

Post by masklinn »

necovek wrote: post #202
jimbokun wrote: post #193

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…

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

Re: Left to Right Programming

#240

Post by hnlmorg »

sureglymop wrote: post #212

It's nice if after typing `file.` you see what functions you can use. But what if there end up being too many options? What's next, a fuzzy finding search box for all possible functions? Contextually relevant ones based on the code you've already written?

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

Post reply on HN