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

261–270 of 372 posts

Re: Left to Right Programming

#261

Post by jibal »

xelxebar wrote: post #252
jibal wrote: post #219

Earlier quoted context omitted.

Failure to understand something is not a virtue. That it does get a lot of love strongly suggests that there are reasons for that. Of course it has flaws, but that alone doesn't tell us anything; only comparisons do. Create a comprehensive pro/con list and see how it fares. Then compare that to pro/con lists for other languages.

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

Re: Left to Right Programming

#262

Post by dragonwriter »

MonkeyClub wrote: post #245
hnlmorg wrote: post #231

Earlier quoted context omitted.

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

> JavaScript has been a backend language long before the web was the dominant platform. I don't think this holds. JavaScript was created as a frontend language specifically for web browsers. It wasn't until 2009 with the introduction of Node.js that JavaScript became a viable option for backend development. The web was already the dominant platform by then.

> It wasn't until 2009 with the introduction of Node.js that JavaScript became a viable option for backend development.

JavaScript was used for backend development since the late 1990s via the Rhino engine (the backends wouldn't be pure JS generally but a mix of JS and Java; Rhino was a JS engine for the JVM with Java interop as a key feature.)

Re: Left to Right Programming

#263

Post by jibal »

9rx wrote: post #249
jibal wrote: post #219

Earlier quoted context omitted.

Failure to understand something is not a virtue. That it does get a lot of love strongly suggests that there are reasons for that. Of course it has flaws, but that alone doesn't tell us anything; only comparisons do. Create a comprehensive pro/con list and see how it fares. Then compare that to pro/con lists for other languages.

> Of course it has flaws, but that alone doesn't tell us anything; only comparisons do. Comparisons won't tell us anything. If Python were the only programming language in existence, that doesn't imply that it would be loved. Or, if we could establish that Python is the technically worst programming language to ever be created, that doesn't imply that wouldn't be loved. Look at how many people in the world love other…

> Comparisons won't tell us anything.

If you insist.

> If Python were the only programming language in existence, that doesn't imply that it would be loved.

I'm not here to defend bizarre strawmen.

> It is unlikely that it is possible for us to truly understand.

If you insist.

Re: Left to Right Programming

#264

Post by nxpnsv »

superbatfish wrote: post #180
itishappy wrote: post #127

Earlier quoted context omitted.

The pipe operator uses what comes before as the first argument of the function. This means in R it would be: result fun1(arg1=1) |> fun2(arg2=2) Python doesn't have a pipe operator, but if it did it would have similar syntax: result = df |> fun1(arg1=1) |> fun2(arg2=2) In existing Python, this might look something like: result = pipe(df, [ (fun1, 1), (fun2, 2) ]) (Implementing `pipe` would be fun, but I'll leave it a…

>Implementing `pipe` would be fun, but I'll leave it as an exercise for the reader. I like exercise: https://gist.github.com/stuarteberg/6bcbe3feb7fba4dc2574a989...

Neat!

Re: Left to Right Programming

#265

Post by nxpnsv »

mb7733 wrote: post #92
nxpnsv wrote: post #78

Earlier quoted context omitted.

I don't know if result = (df .pipe(fun1, arg1=1) .pipe(fun2, arg2=2) ) is much less readable than result fun1(., arg1=1) |> fun2(., arg2=2) but I guess the R thing also works beyond dataframes which is pretty cool

I haven't used R in forever, but is your `.` placeholder actually necessary? From my recollection of pipe operator the value being pipe piped is automatically as the first argument to the next function. That may have been a different implementation of a pipe operator though.

Probably not, I didn’t use R much during the last decade …

Re: Left to Right Programming

#266

Post by yccs27 »

levocardia wrote: post #177
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 pipe operator in R (really, tidyverse R, which might as well be its own language) is one of its "killer apps" for me. Working with data is so, so pleasant and easy. I remember a textbook that showed two ways of "coding" a cookie recipe: bake(divide(add(knead(mix(flour, water, sugar, butter)),eggs),12),450,12) versus mix(flour, water, sugar, butter) %>% knead() %>% add(eggs) %>% divide(12) %>% bake(temp=450, minut…

You'd never write that ugly one-liner. Just write the recipe imperatively:

    dough = mix(flour, water, sugar, butter)
    dough.knead()
    dough = dough.add(eggs)
    cookies = dough.divide(12)
    cookies = bake(temp=450, minutes=12)
Might be more verbose, but definitely readable.

Re: Left to Right Programming

#268

Post by nxpnsv »

itishappy wrote: post #127
nxpnsv wrote: post #78

Earlier quoted context omitted.

I don't know if result = (df .pipe(fun1, arg1=1) .pipe(fun2, arg2=2) ) is much less readable than result fun1(., arg1=1) |> fun2(., arg2=2) but I guess the R thing also works beyond dataframes which is pretty cool

The pipe operator uses what comes before as the first argument of the function. This means in R it would be: result fun1(arg1=1) |> fun2(arg2=2) Python doesn't have a pipe operator, but if it did it would have similar syntax: result = df |> fun1(arg1=1) |> fun2(arg2=2) In existing Python, this might look something like: result = pipe(df, [ (fun1, 1), (fun2, 2) ]) (Implementing `pipe` would be fun, but I'll leave it a…

Thanks!

Re: Left to Right Programming

#269

Post by [deleted] »

jibal wrote: post #263
9rx wrote: post #249

Earlier quoted context omitted.

> Of course it has flaws, but that alone doesn't tell us anything; only comparisons do. Comparisons won't tell us anything. If Python were the only programming language in existence, that doesn't imply that it would be loved. Or, if we could establish that Python is the technically worst programming language to ever be created, that doesn't imply that wouldn't be loved. Look at how many people in the world love other…

> Comparisons won't tell us anything. If you insist. > If Python were the only programming language in existence, that doesn't imply that it would be loved. I'm not here to defend bizarre strawmen. > It is unlikely that it is possible for us to truly understand. If you insist.

[deleted]

Re: Left to Right Programming

#270

Post by lmm »

spapas82 wrote: post #114
xg15 wrote: post #83

I think the most absurd syntax goes to Python again. Python offers an "extended" form of list comprehensions that lets you combine iteration over nested data structures. The irony is that the extensions have a left-to-right order again, but because you have to awkwardly combine them with the rest of the clause that is still right-to-left, those comprehensions become completely unreadable unless you know exactly how t…

The proper way to parse or construct nested list comprehensions as explained in pep 202 is to think like you're using normal for: for a in b: for c in a: use(a,b,c) This would be [use(a,b,c) for a in b for c in a] Everything stays the same except the "use" part that goes in the front (the rule also includes the filters - if).

> The proper way to parse or construct nested list comprehensions as explained in pep 202 is to think like you're using normal for:

A syntax construct that requires you to think in a different syntax construct to understand it is not a good syntax construct.

> Everything stays the same except the "use" part that goes in the front (the rule also includes the filters - if).

Yeah, you consistently have to write the end first followed by the start and then the middle, it's just in most cases there's no middle so you naturally think you only have to flip the syntax rather than having to write it middle-ended like a US date.

Post reply on HN