Live data from Hacker News

Left to Right Programming

graic.net

51–60 of 372 posts

Re: Left to Right Programming

#51

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 find myself writing a very simple style of python that avoids list comprehensions and so on when working in a shared code base. For a language where there is supposed to be only one way to do things, there are an awful lot of ways to do things. Don’t get me wrong, writing a list comprehension can be very satisfying and golf-y But if there should be one way to do things, they do not belong.

I find list and dict comprehensions are a lot less error prone and more robust than the “manual” alternatives.

I would say unless you have a good reason to do so, features such as meta classes or monkey patching would be top of list to avoid in shared codebases.

Re: Left to Right Programming

#53
post #8

I miss the F# pipe operator ( https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... ) in other languages. It's so natural to think of function transform pipelines. In other languages you have to keep going to the left and prepend function names, and to the right to add additional args, parens etc ...

[deleted]

Re: Left to Right Programming

#54
That's fine for doing algebra in pure functions, but what about destructive commands or interactive scenarios?

For example, using "rm" on the command line, or an SQL "delete". I would very much like those short programs to be invalid, until someone provides more detail about what should be destroyed in a way that is accident-resistant.

If I had my 'druthers, the left-to-right prefix of "delete from table" would be invalid, and it would require "where true" as a safety mechanism.

Re: Left to Right Programming

#55
post #30

Earlier quoted context omitted.

> But it also makes the code harder to scan than Python. Quick readability at a glance seems like the bigger win than just better autocomplete. It depends a lot on what you’re accustomed to. You get used to whichever style. Just like different languages use different sentence order: subject, object and verb appear in all possible orders in different languages, and their speakers get along just fine. There are some si…

On the other hand, in Rust you often have to add something like .unwrap().unwrap().into:: >>() which kind of ruins the elegance :P

It indeed doesn't look elegant, however I've never in my experience seen a usage like this. Do you have any reference where you might have seen this kind of usage.

Re: Left to Right Programming

#56
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…

Yes, C#'s DSL that compiles to SQL (LINQ-to-SQL) does the same thing, `from` before the other clauses, for the same reason that it allows the IDE code completion to offer fields while typing the other clauses.

Re: Left to Right Programming

#57
post #5

> Programs should be valid as they are typed. That would be nice if devs always wrote code sequentially, i.e. left to right, one character at a time, one line at a time. But the reality is that we often jump around, filling in some things while leaving other things unfinished until we get back to them. Sometimes I'll write code that operates on a variable, then a minute later go back and declare that variable (perhap…

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.

I feel that's a use case for compiler flags that convert warnings to errors or vice-versa, where the same source-code can either be "good enough to experiment with" or "not ready for release" depending on the context.

Re: Left to Right Programming

#58

Earlier quoted context omitted.

The author's argument is a strong argument against the way Lisp does it, at least for most code, as Lisp tends to put the verb to the left and nouns to the right so your IDE has no idea what nouns you are working with until you've picked the verb.

Pretty much every functional language is verb-initial, as are function calls as well as statements in most mainstream languages. Verb-final languages like PostScript and Forth are oddballs. Embedded verbs are a thing of course, with the largest contribution coming from arithmetic expressions with infix operators, followed by certain common syntax like "else" being in the of an "if" statement, followed by things like…

Right, his argument is in favor of the "fluent" syntax like

  table.where(...).select(...)
that is typical in many OO interfaces, though you sometimes see a pipe syntax which would be autocomplete friendly in languages like Clojure

https://clojuredocs.org/clojure.core/-%3E

or F#

https://stackoverflow.com/questions/12921197/why-does-the-pi...

Re: Left to Right Programming

#59
post #5

> Programs should be valid as they are typed. That would be nice if devs always wrote code sequentially, i.e. left to right, one character at a time, one line at a time. But the reality is that we often jump around, filling in some things while leaving other things unfinished until we get back to them. Sometimes I'll write code that operates on a variable, then a minute later go back and declare that variable (perhap…

It's definitely a minor annoyance for me that IDEs assume that I type things in a different order than I really do.

Re: Left to Right Programming

#60
post #30

Earlier quoted context omitted.

On the other hand, in Rust you often have to add something like .unwrap().unwrap().into:: >>() which kind of ruins the elegance :P

It indeed doesn't look elegant, however I've never in my experience seen a usage like this. Do you have any reference where you might have seen this kind of usage.

This is not meant to be taken literally, I was making fun of how Rust often requires a lot of punctuation and thinking about details of memory allocation.
Post reply on HN