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

361–370 of 372 posts

Re: Left to Right Programming

#361

Post by xelxebar »

pnt12 wrote: post #283
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…

I'm not a hater, but also not the biggest fan of bash. What do you consider its pros and cons? Pros: easy to interact with different tools, included in many Unix OSs, battle tested. Cons: complex stuff gets messy, with weird syntax, hard to do logic, hard to escape everything correctly

I think you did a good job delineating top complaints people have about shell, but I have to reject the pro/con framing.

Shell operates quite naturally under stream-oriented data-centric design patterns. But that's an architectural familiar to almost nobody in our OOP- and FP-happy industry these days. Try using Python like a relational database language (e.g. SQL), and complex stuff gets messy, the syntax starts feeling hostile, logic becomes obscure, etc. The purported ickyness of shell stems not from shell per se but from trying to force it into a foreign design space.

Principles that work well with shell: Heavily normalize your data; Organize it into line-oriented tables with whitespace-separated fields; Use the filesystem as a blob store; Filenames can be structured data as well; positional parameters form a bona fide list.

> hard to escape everything correctly

IME, all of the really painful escape patterns can always be avoided. You see these a lot when people try to build commands and pass them off to exec. That's mostly unnecessary when you can just shove the arguments in the positional parameters via the set builtin: e.g.

    set -- "$@" --file 'filename with spaces.pdf'
    set -- "$@" 'data|blob with "dangerous" characters'
    set -- "$@" "$etc"
    some_command "$@"
which is functionally equivalent to

    some_command "$@" --file 'filename with spaces.pdf' \
        'data|blob with "dangerous" characters' \
        "$etc"
It also helps to rtfm and internalize the parsing steps that happen between line of input and the eventual execve call.

Re: Left to Right Programming

#362

Post by sriku »

cesarb wrote: post #293
sriku wrote: post #199

This is almost FP vs OOP religious war in disguise. Similar to vim-vs-emacs ... where op comes first in vim but selection comes first in emacs. If you design something to "read like English", you'll likely get verb-first structure - as embodied in Lisp/Scheme. Other languages like German, Tamil use verbs at the end, which aligns well with OOP-like "noun first" syntax. (It is "water drink" word for word in Tamil but "…

> Other languages like German, Tamil use verbs at the end Doesn't German have the main verb on the second position? (For a simple example, "I drink water" would be "Ich trinke Wasser")

In that form yes, but the active "drink water" which is kind of what we'd code like "drink(water)" is "wasser trinken". ... but yeah human languages aren't straightjacketed easily.

Re: Left to Right Programming

#363

Post by disconcision »

conartist6 wrote: post #205
disconcision wrote: post #129

Earlier quoted context omitted.

there are approaches to ensure you always or almost always have syntactic validity, e.g. structured editing or error correcting parsing, though of course it's true that the more permissive the system is the more tortured some of the syntactic 'corrections' must be in extreme cases. the approach we're taking with http://hazel.org (which we approximate but don't fully succeed at yet) is: allow normal-ish typing, always…

Hazel has embedding gaps but they are language and editor specific. BABLR takes Hazel's idea and takes it about 18 steps further, potentially making embedding gaps a feature of every editor and programming language . As long as solutions don't have a way to scale economically they'll be academic, but BABLR makes this not academic anymore.

interesting!! is BABLR yours? is there a page that talks about your error-correcting/embedding-gaps approach? couldn't immediate find one in the docs. btw new version of tylr (hazel's core editing engine) is multi-language from the ground up, with a javascript grammar underway; new version is not yet online though

Re: Left to Right Programming

#364

Post by adregan »

rspencer wrote: post #360
adregan wrote: post #339

Earlier quoted context omitted.

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

Thanks!

Though hopefully, once the idiom is learned, I'll be able to remember it :)

Curious as to why a scan \ rather than a reduction /?

Re: Left to Right Programming

#365

Post by conartist6 »

disconcision wrote: post #363
conartist6 wrote: post #205

Earlier quoted context omitted.

Hazel has embedding gaps but they are language and editor specific. BABLR takes Hazel's idea and takes it about 18 steps further, potentially making embedding gaps a feature of every editor and programming language . As long as solutions don't have a way to scale economically they'll be academic, but BABLR makes this not academic anymore.

interesting!! is BABLR yours? is there a page that talks about your error-correcting/embedding-gaps approach? couldn't immediate find one in the docs. btw new version of tylr (hazel's core editing engine) is multi-language from the ground up, with a javascript grammar underway; new version is not yet online though

It is! Our approach to error correcting is not to error correct. We instead help the user be highly effective while passing through incomplete states but not invalid ones.

Gaps are present in the embedded code representation, e.g. if · is a gap we would represent the result of parsing `console.log(·)` using a "gap tag" (written ``) in a CSTML document that will look like this: https://gist.github.com/conartist6/75dc969b685bbf69c9fa9800c...

Re: Left to Right Programming

#366

Post by tekknik »

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…

It seem like creative use of the map function and some iterators would provide the same functionality as a pipe does

Re: Left to Right Programming

#367

Post by mpweiher »

This was one of the changes I made to Smalltalk syntax for Objective-S[1]:

The pipe "|" as an analog to the cascade ";", but sending to the result, like a normal pipe would. This avoids having to go back and add parentheses when you have a longer expression involving keyword sends.

For example navigating a nested set of dictionaries

    self classDefs at:className.
    (self classDefs at:className) at:which.
    ((self classDefs at:className) at:which) at:methodName.
vs.

    self classDefs at:className.
    self classDefs at:className | at:which.
    self classDefs at:className | at:which | at:methodName.
[1] https://objecttive.st

Re: Left to Right Programming

#368

Post by jodrellblank »

aredox wrote: post #319
sriku wrote: post #199

This is almost FP vs OOP religious war in disguise. Similar to vim-vs-emacs ... where op comes first in vim but selection comes first in emacs. If you design something to "read like English", you'll likely get verb-first structure - as embodied in Lisp/Scheme. Other languages like German, Tamil use verbs at the end, which aligns well with OOP-like "noun first" syntax. (It is "water drink" word for word in Tamil but "…

>where op comes first in vim Doesn't Kakoune reverses that, and it makes so much more sense ? https://kakoune.org/why-kakoune/why-kakoune.html

Is it telling that the name is vi improved (noun verb) rather than improved vi (verb noun)?

Re: Left to Right Programming

#369

Post by Bolwin »

jibal wrote: post #225
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.

Zig is the worst that way.

Which is silly because it could be among the best since it has line by line lime compilation.

I hope someone makes a fork that lets you disable those silly errors in debug mode

Re: Left to Right Programming

#370

Post by mikeen »

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

Google actually started pipe syntax, https://news.ycombinator.com/item?id=41338877

Now it is supported by DuckDB, BigQuery, Spark SQL, Firebolt, and probably others. I use it more and more (with BigQuery).

Post reply on HN