Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Homoiconic Spreadsheets: What, How and Why [video]

youtube.com

Post reply on HN
Print view View original

11–20 of 24 posts

Re: Homoiconic Spreadsheets: What, How and Why [video]

#11

Post by bradrn »

whacked_new wrote: post #9

intriguing presentation! So I have 1 prediction and 1 question. prediction: even though lambdas bring "code programming" into spreadsheets, and it's a huge leap in functionality for the spreadsheet, the dominant programming mode in the spreadsheet will still be interactive programming in the "traditional" spreadsheet sense. I claim this because the mental model of code programming is different from interactive progra…

> We've seen several new spreadsheet implementations pop up in the past years, including ones with built-in programming capability, but none of them really seem like as big of a deal as Gsheets/Excel adding lambdas.

I think this is just because Google Sheets and Excel are used by many orders of magnitude more people than any other spreadsheet product, and so any major change in them is automatically a ‘big deal’.

Re: Homoiconic Spreadsheets: What, How and Why [video]

#12

Post by mindB »

savq wrote: post #7
europeanguy wrote: post #2

You know what language is also homoiconic? Julia.

Saying that is pretty out of context. It's also incorrect. Julia has runtime code generation and hygenic macros, but it's not homoiconic. Clearly, x + 1 is different from Expr(:call, :+, :x, 1)

I tend to agree that Julia and other modern programming languages with hygenic macros aren't "homoiconic". Maybe GP is making a point about the title of this presentation? Read generously, maybe he's criticizing calling this homoiconicity by comparing it to Julia which originally claimed to be homoiconic but removed the claim from its website because of contentiousness[1]?

[1] https://groups.google.com/g/julia-users/c/iKxqn-J9frI/m/QzaS...

Re: Homoiconic Spreadsheets: What, How and Why [video]

#13

Post by skybrian »

bradrn wrote: post #8
somat wrote: post #5

I am not a fan of anonymous functions. I think they are evocative of maths culture tendency to remove and make meaningless names(for example, using greek letters). Yes I know naming things is hard, but names are important, they are critical labels about the inner inner working of the machine. Nothing wrong with functional programing, in fact it is pretty great, But I wish people would name their functions.

On the other hand, sometimes it’s better to avoid naming functions, especially if they’re small and only used once. For instance, if I’m doing something like ‘map (\(x,y) -> (x,y+1))’ to increment the second element of each item in a list (using Haskell syntax), naming the anonymous function won’t necessarily make anything clearer. Or consider this example from my own code: zipWith (\i m -> fmap (i,) m) [0..] Sure, I…

This assumes you're writing generic, mathematical code. Maybe that's common in Haskell, and I agree that there often aren't helpful names in that situation.

But usually, if you're working with a list, it's a list of something specific, and the names should reflect that. If we're doing graphics and those (x,y) points are interpreted as points on a graph, then it's really:

  moveUpOne = (x,y) => (x,y + 1)
  map(moveUpOne, points)
Or maybe it's moveDownOne? Depends on your coordinate system.

Similarly, you're probably prepending to a list for some application-specific reason. The code should use application-specific jargon.

Re: Homoiconic Spreadsheets: What, How and Why [video]

#14

Post by antonvs »

skybrian wrote: post #13
bradrn wrote: post #8

Earlier quoted context omitted.

On the other hand, sometimes it’s better to avoid naming functions, especially if they’re small and only used once. For instance, if I’m doing something like ‘map (\(x,y) -> (x,y+1))’ to increment the second element of each item in a list (using Haskell syntax), naming the anonymous function won’t necessarily make anything clearer. Or consider this example from my own code: zipWith (\i m -> fmap (i,) m) [0..] Sure, I…

This assumes you're writing generic, mathematical code. Maybe that's common in Haskell, and I agree that there often aren't helpful names in that situation. But usually, if you're working with a list, it's a list of something specific, and the names should reflect that. If we're doing graphics and those (x,y) points are interpreted as points on a graph, then it's really: moveUpOne = (x,y) => (x,y + 1) map(moveUpOne,…

In Haskell you can implement moveUpOne as:

    moveUpOne = fmap (+1)
...which uses a map over a functor, in this case a tuple. But once you're familiar with functors, there's not that much benefit in naming something like that, much as you wouldn't typically define `add1 = (+1)`.

Re: Homoiconic Spreadsheets: What, How and Why [video]

#15

Post by savq »

mindB wrote: post #12
savq wrote: post #7

Earlier quoted context omitted.

Saying that is pretty out of context. It's also incorrect. Julia has runtime code generation and hygenic macros, but it's not homoiconic. Clearly, x + 1 is different from Expr(:call, :+, :x, 1)

I tend to agree that Julia and other modern programming languages with hygenic macros aren't "homoiconic". Maybe GP is making a point about the title of this presentation? Read generously, maybe he's criticizing calling this homoiconicity by comparing it to Julia which originally claimed to be homoiconic but removed the claim from its website because of contentiousness[1]? [1] https://groups.google.com/g/julia-users/…

He could be making that comparison, but I read the comment as "I use Julia btw", and that's what I took issue with. I wrote a comment to dismiss it and save face for Julia programmers.

Re: Homoiconic Spreadsheets: What, How and Why [video]

#16

Post by whacked_new »

bradrn wrote: post #11
whacked_new wrote: post #9

intriguing presentation! So I have 1 prediction and 1 question. prediction: even though lambdas bring "code programming" into spreadsheets, and it's a huge leap in functionality for the spreadsheet, the dominant programming mode in the spreadsheet will still be interactive programming in the "traditional" spreadsheet sense. I claim this because the mental model of code programming is different from interactive progra…

> We've seen several new spreadsheet implementations pop up in the past years, including ones with built-in programming capability, but none of them really seem like as big of a deal as Gsheets/Excel adding lambdas. I think this is just because Google Sheets and Excel are used by many orders of magnitude more people than any other spreadsheet product, and so any major change in them is automatically a ‘big deal’.

True. And they are used by orders of magnitude more people because they have proven their usefulness with the masses

Stating the obvious, but it's a good reminder, because I asked the question anyway. For the mass market, it's a UX problem before it's a product problem before it's a tech problem.

Re: Homoiconic Spreadsheets: What, How and Why [video]

#17

Post by tpoacher »

somat wrote: post #5

I am not a fan of anonymous functions. I think they are evocative of maths culture tendency to remove and make meaningless names(for example, using greek letters). Yes I know naming things is hard, but names are important, they are critical labels about the inner inner working of the machine. Nothing wrong with functional programing, in fact it is pretty great, But I wish people would name their functions.

in the right context, greek letters were actually supposed to represent meaningful names. especially with Greek historically treated as the lingua franca for science.

the fact that most people abuse greek letters for this purpose says more about most people than about the utility of greek letters in formulae.

(but otherwise, yes, I agree with the more general point)

Re: Homoiconic Spreadsheets: What, How and Why [video]

#18

Post by skybrian »

antonvs wrote: post #14
skybrian wrote: post #13

Earlier quoted context omitted.

This assumes you're writing generic, mathematical code. Maybe that's common in Haskell, and I agree that there often aren't helpful names in that situation. But usually, if you're working with a list, it's a list of something specific, and the names should reflect that. If we're doing graphics and those (x,y) points are interpreted as points on a graph, then it's really: moveUpOne = (x,y) => (x,y + 1) map(moveUpOne,…

In Haskell you can implement moveUpOne as: moveUpOne = fmap (+1) ...which uses a map over a functor, in this case a tuple. But once you're familiar with functors, there's not that much benefit in naming something like that, much as you wouldn't typically define `add1 = (+1)`.

That's significantly less readable since you can't see that you're working with ordered pairs that have x and y coordinates. Don't hide the data structure.

Re: Homoiconic Spreadsheets: What, How and Why [video]

#19

Post by elzr »

Hi all, I'm Eli Parra & I gave this talk at ReClojure 2022 in December 3, 2022. Very happy to see this here in HN!

A bit of personal background of the talk: my work over the years has involved making internal tools for fast-moving, small organizations and that's how I fell in love with spreadsheets. They are the best canvas I know of to whip up custom, user-friendly interfaces in a couple of hours. These prototypes often then go on to be intensely used for months and even years with organic growth & minimal maintenance.

Spreadsheets are often seen with condescension by technical people & they've grown a heavy patina of drudgery over the decades. But to me they represent creative freedom & the easiest interface to computation we've yet found, so successful it's nearly invisible. I gave this talk because I'm starting to find answers to what makes them so successful and have ideas of how they might evolve.

My key points in the talk:

* Spreadsheets matter. Used by billions of people, they're the main way to go beyond being a point-and-click user and start programming. I frame spreadsheets as level 2 in a scale for interfaces that Gordon Brander imagines in this essay: https://subconscious.substack.com/p/a-kardashev-scale-for-in...

* Spreadsheets are changing. In 2022 Excel & Google Sheet got lambdas and reached level 3 in Brander's scale. The talk is a stab at what a level-4 spreadsheet might be, how you could translate QUOTE & EVAL into spreadsheets.

* Spreadsheets have an essence, what Alan Kay described as "the value rule" back in 1984: a cell can read from any other but can only write to itself. This is the founding, simplifying constraint of spreadsheets, akin to how structured programming outlawed go-to’s in code.

* Spreadsheets are time-less. The consequence of the value rule is that there is no time in spreadsheets. There are no unfolding sequences or loops or conditionals, execution happens in a subjective instant after a user change and only then.

* Spreadsheets are easy because they're time-less & space-full. They do without the trickiest part of computation (invisible unfolding time) and include a native, idealized space, the biggest aid to computation we’ve found: an interactive grid you embody & reference through cells. As opposed to ”normal" control-flow programming that goes wild with time & has abstract data structures for space.

* Homoiconicity can be practical! When translated to spreadsheets, homoiconicity looks very related to copy-paste, links, transclusion & component/instances.

To sum up: Spreadsheets are old but they've never been "finished", they've keept evolving and they merit a new look.

Post reply on HN