Left to Right Programming

Here's a summary of the themes and opinions expressed in the Hacker News discussion:

The Ideal of Valid Code as You Type

A significant portion of the discussion revolves around the concept of code being valid at every stage of typing. This property is seen as highly beneficial for editor tooling and guidance, leading users towards correct code.

• "Programs should be valid as they are typed." This recurring quote encapsulates this ideal.
• chrismorgan elaborates: "Syntactically, especially, which requires (necessary but not sufficient) either eschewing delimitation, or only inserting opening and closing delimiters together."
• The author's argument for this principle is reiterated: "When you’ve typed text, the program is valid. When you’ve typed text.split(" "), the program is valid. Since the program is valid as you build it up, your editor is able to help you out."
• However, others point out the practical challenges: "But the reality is that we often jump around, filling in some things while leaving other things unfinished until we get back to them." kmoser states this, with nottorp and AnimalMuppet agreeing on the non-sequential nature of coding.
• disconcision mentions approaches like "structured editing or error correcting parsing" to address this, as well as their own project, Hazel.org, which aims to "always correct the code enough to be ran/typechecked, but insert placeholders/decorations to telegraph the parse structure."

The Impact and Efficacy of LLM Code Autocompletion

The emergence of LLMs like Copilot is a major topic, with users debating their usefulness and impact on traditional coding practices.

• taeric initially questions: "I'm curious on how much of this is basically overcome by the new tools? As much as vibe coding annoys me, I can't argue against how good autocomplete from these LLMs can be."
• However, the sentiment is not universally positive. mrguyorama expresses frustration: "So far any "autocomplete" from an LLM has only served to insanely disrupt my screen with fourtey lines of irrelevant nonesense that cannot be turned off... and has only served to be less useful than non-LLM based autocompletes were."
• slowmovintarget questions the continued importance of ergonomics: "In the age of CoPilot and agent coders I'm not so sure how important the ergonomics still are, though I dare say coding an LSP would certainly make one happy with the argument."
• The idea that LLMs might "paper over our awful intuitions" is raised by nathan_compton, leading to concerns about being "stuck with bad syntax like python forever."

Readability: Left-to-Right vs. Inside-Out and the Role of Syntax

A core debate centers on how code should be read for optimal understanding, with a strong preference for linear, left-to-right flow versus more complex, nested, or "inside-out" reading patterns.

• taeric expresses a preference for linear readability: "I do prefer my code to be readable left to right and top to bottom. This, typically, means the big 'narrative' functions up top and any supporting functions will come after they were used."
• xigoi agrees: "Left-to-right is also much easier to wrap your head around. Just imagine the data going on a conveyor belt with a bunch of machines instead of having to wrangle a nested tree."
• Conversely, scuff3d notes the challenge to this view: "A not insignificant number of functional languages disagree. You often read functional code from the inside out, which basically means you're reading right to left as you move up function calls."
• chrismorgan provides a detailed comparison of Python list comprehensions and Rust iterators, finding the Rust version "significantly easier to read" in a specific case due to its linear flow compared to Python's nested structure.
• Regarding Python comprehensions, jibal criticizes the order: "the output expression comes before the context that establishes its meaning. This is not just a problem for autocomplete, but people often report difficulties understanding complex comprehensions."
• necovek defends comprehensions, comparing them to for loops: "Comprehensions are similarly 'bad' as for loops, except they are more powerful and allow more expression types early [in terms of what you have to type first]. ... It's like discussion of RPN or infix for calculations."

The Ergonomics and Suitability of Python's Syntax

Python's specific syntax, particularly list comprehensions and import statements, comes under scrutiny, highlighting ongoing debates about its design choices and suitability for different programming styles.

• taeric dislikes Python comprehensions: "I oddly hate comprehensions in python. I have yet to get where I can type those directly."
• scuff3d agrees: "I'm not really a fan of list comprehensions, I usually just use for loops."
• This leads to broader comments on Python's philosophy: dragonwriter clarifies "The Zen of Python" regarding "one way to do it": "That's not what the Zen says, it says that there should be one -- and preferably only one -- obvious way to do it."
• danielPort9 expresses a strong negative opinion: "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."
• Pxtl offers a historical perspective: "Python was established as a fun and sensible language... and has been coasting in that success ever since. Lists comprehensions were added... 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."
• In contrast, instig007 and mb7733 find Python to be a good scripting language, especially with type annotations.

The Utility of Pipe Operators and Functional Composition

The discussion frequently returns to the benefits of pipe operators as seen in languages like F#, R, and proposals for JavaScript, highlighting their utility for readable, sequential data transformation.

• hawk_ misses the F# pipe operator: "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..."
• aquafox sees the pipe operator as a "killer app" for data science in R: "It makes writing data science code, where the data are transformed by a series of different steps, so much more readable and intuitive."
• levocardia uses a cookie recipe analogy to demonstrate the readability improvement: mix(...) %>% knead() %>% add(...) %>% divide(...) %>% bake(...) is much clearer than nested function calls.
• Python doesn't have a native pipe operator, but users discuss workarounds like .pipe() methods in pandas or implementing custom pipe functions.
• The lack of a finalized pipe operator in JavaScript is also lamented.

Readability and Order in SQL Queries

A significant portion of the thread discusses the ordering of clauses in SQL, with many advocating for a FROM clause first, arguing it improves human understanding and IDE support.

• juancn argues that 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 suggested order is FROM -> SELECT -> WHERE.
• gzmarzly suggests PRQL as a language that uses this form.
• pjmlp and dleeftink mention PSQL and BigQuery adopting similar ordering.
• taeric counters that users often know the desired output (SELECT) before the data sources (FROM), making editor autocompletion for selected columns more useful initially.
• debazel strongly disagrees with starting with SELECT, stating, "You can almost never finish a select statement before you have inspected the tables, so why not just start there immediately?" They note that most colleagues start with SELECT * FROM mytable and then revise the SELECT part.
• mamcx argues that even if people think about the desired output first, it's "bad UX" if the syntax is not guided, and FROM a: id is better than I want 'id,id,id'.
• jimbokun questions how one would know the column name without knowing the table, contrasting this with the "property.object" syntax of many languages.
• necovek suggests that the SELECT statement is akin to a function's return type declaration, which they often write first.

The Broad Impact of Familiarity and Ecosystem (Python, JavaScript)

The discussion touches on why certain languages have thriving ecosystems and user bases, often driven by historical factors, network effects, and developer familiarity, rather than purely technical merit.

• hnlmorg and robmccoll discuss JavaScript's dominance, with hnlmorg citing "the network effect" and developers' reluctance to learn new things, while robmccoll points to the web's ubiquity.
• MonkeyClub disputes the timeline of JavaScript's backend rise, stating it only became viable with Node.js in 2009 when the web was already dominant.
• xelxebar suggests Python's "strong on-ramp and... lots of network effects" make it a common default, but this can add friction for expert users.
• jibal and 9rx engage in a meta-discussion about whether "love" for a language is based on rational comparison or something less understood, with jibal suggesting that widespread adoption "suggests there are reasons for that."

Challenges in Language Standardization and Evolution

The thread also highlights the difficulties in evolving languages and standards, leading to stagnation or the need for workarounds.

• orthoxerox explains that SQL's slow adoption of features is due to it being a "whole language family of separate languages grudgingly adopting new features introduced by the notoriously slow standardization committee."
• The discussion of the JavaScript pipeline operator's stalled progress at TC-39 (Technical Committee 39) is an example of "eternal bikeshedding" hindering language evolution.
• Philpax expresses concern about Python's package management issues being tied to "VC-backed project[s]" like uv, even while acknowledging uv's significant improvements.