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

201–210 of 372 posts

Re: Left to Right Programming

#201

Post by dragonwriter »

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

> If you design something to "read like English", you'll likely get verb-first structure

If its imperative, sure. If its declarative and designed to read like English it will be subject first.

Re: Left to Right Programming

#202

Post by necovek »

jimbokun wrote: post #193
taeric wrote: post #106

Earlier quoted context omitted.

My main caveat here, is that often the person starting a select knows what they want to select before they know where to select it from. To that end, having autocomplete for the sources of columns is far far more useful than autocomplete for columns from a source. I will also hazard a guess that the total number of columns most people would need autocomplete for are rather limited? Such that you can almost certainly…

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, and I frequently start my functions with the declaration.

Re: Left to Right Programming

#203

Post by chowells »

Autocomplete-oriented programming optimizes for writing code. I don't think that's a good route to go down. Autocomplete is good for spewing out a large volume of code, but is that what we want to encourage?

I'd much rather optimize for understanding code. Give me the freedom to order such that the most important ideas are up front, whatever the important details are. I'd much rather spend 3x the time writing code of it means I spend half the time understanding it every time I return to it in the future.

Re: Left to Right Programming

#204

Post by necovek »

mamcx wrote: post #137
taeric wrote: post #125

Earlier quoted context omitted.

"I want 'first_name, last_name, and average(grade)' for my report." That is easy enough to state without knowing anything about how the data is normalized. Back when I worked to support a data science team, I actually remember taking some of their queries and stripping everything but the select so that I could see what they were trying to do and I could add in the correct parts of the rest.

Even assuming that this is plausible way a user could think about it (that can be understood) it shows why is bad Think: I have 20 tables with the column `id` "I want 'id,id,id'" is bad UX, and is what here is being argued, then when the syntax guide you: "I want 'FROM a: id'" is better

Current SELECT syntax does allow one to "SELECT user.id as user_id, product.id as product_id..." which can then even autocomplete the FROM for you from your query "declaration" (a-la function declaration, in particular its return type).

Re: Left to Right Programming

#205

Post by conartist6 »

disconcision wrote: post #129
kmoser wrote: post #101

Earlier quoted context omitted.

How is it supposed to compile if you've written something syntactically invalid? You can make the argument that the compiler could interpret it in (perhaps even arbitrary) valid way that constitutes a valid syntax, but that's almost worse: rather than being chided with compiler warnings, you now end up with code that compiles but executes indeterminately.

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.

Re: Left to Right Programming

#206

Post by necovek »

shkkmo wrote: post #189
taeric wrote: post #167

Earlier quoted context omitted.

I'd assume they would ask for "aggregate sales by month to zip codes," or some such. Which, you'd probably get from a reporting table, and not bother trying to do the manual aggregate over transactional data. (That is, OLAP versus OLTP is a very real divide that you can't wave away.) Realistically, I strongly suspect you could take this argument either direction. If you have someone making a query where they are havi…

Your approach only works with massive assumptions about the structure of the data or a very simplistic data structure. SELECT statments don't just use table names, they can use aliases for those table names, views, subqueries, etc. The FROM / JOIN blocks are where the structure of the data your are selecting from is defined. You should not assume you understand what a SELECT statement means until you have read those…

As GP said, you can take this both ways.

I can define the return format of my query in the SELECT statement, then adapt the data structure in the FROM block using subselects, aliases etc — all to give me the shape desired for the query.

If you've ever done complex querying with SQL, you'd know that you'd go back and forth on all parts of the query to get it right unless you knew the relations by heart, regardless of the order (sometimes you'll have to rework the FROM because you changed the SELECT is the point).

Re: Left to Right Programming

#207

Post by necovek »

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

The same reason people are not flocking to the Lisps of the world: mathematical rigour and precision does not translate to higher legibility and understandability.

Python's list /dict/set comprehensions are equivalent to typed for loops: where everyone complains about Python being lax with types, it's weird that one statement that guarantees a return type is now the target.

Yet most other languages don't have the "properly ordered" for loop, Rust included (it's not "from iter as var" there either).

It's even funnier when function calling in one language is compared to syntax in another (you can do function calling for everything in most languages, a la Lisp). Esp in the given example for Python: there is functools.map, after all.

Re: Left to Right Programming

#208

Post by necovek »

Another point to this is that we should switch to writing the numbers in the right order too: 123 should be three-hundred-twenty-one.

This way, as soon as you type "1", it is truly one, you add a "2" and you know that's adding twenty...

IIRC Arabic gets this right!

/s

Re: Left to Right Programming

#209

Post by kragen »

necovek wrote: post #200

In Rust, for..in loops have the same problem: you don't know the type and shape of the thing you are iterating on before you get to the "in" part. "Luckily", it does not allow you to call any methods on the object before you do. Similarly, Python list/dict/set comprehensions are a form of for-loop syntax sugar to easily create particular structure. One can use functools.maps to get exactly the same behavior of Rust e…

That's an interesting idea: maybe instead of `for x, y in points: ...` (Python syntax) we should write `points do |x, y| ...` so the IDE has a maximum amount of type inference information available? That would also suggest writing variable declarations with the variable at the end, as in Forth or Levien's Io. 80 CONSTANT COLUMNS or `80 -> columns;`.

It doesn't look anything like Lisp, though.

Re: Left to Right Programming

#210

Post by kragen »

frou_dh wrote: post #115

In 1990s-born scripting languages, it makes sense that there are plenty design choices that don't mesh well with static-analysis-driven autocompletion, because that was not at all part of the requirements for these languages at the time they were designed!

It was a pretty big deal by the time list comprehensions were added to Python, though, in 02000: https://peps.python.org/pep-0202/

It's true that Python didn't cater to static analysis at all.

Post reply on HN