undefined | Better HN

story

0 pointsUncleMeat5y ago0 comments

Linear text is easier to represent. Same reason why we don't lay out programs in some sort of graph structure but instead write text from top to bottom.

"To taste" is usually reserved for salt or some sort of textual element (like thinning a soup with water). Sometimes it involves pepper. Rarely will it involve other spices, though I don't think that's a terrible idea since most everybody has old ground spices so 2tsp will taste very different between kitchens.

You can't make a recipe amazingly precise for home cooks because equipment is wildly different and ingredient quality is wildly different. This is just a property of home recipes. Serious kitchens have things like salt done in precise weight ratios.

0 comments

TeMPOraL5y ago

> Linear text is easier to represent. Same reason why we don't lay out programs in some sort of graph structure but instead write text from top to bottom.

Oh, but you actually do! You write your programs in form of trees (abstract syntax ones), and those trees generally represent directed and usually acyclic graphs of dependencies. For example:

  (defun foo (x y) (+ x y))
  (defun bar (x) (foo x x))

  (foo (42 (bar 12)))

Is a tree of tokens (with an implicit root node). It's obvious when you write in a language like Lisp; most popular languages only obscure this by a layer of syntactic sugar, but you're still writing trees.

And the reason we don't lay out programs as visual, interactive graphs[0] is because text is faster to work with using digital tools. It's faster to type the structure than click it into being[1], it's easier to grep through it, to diff it, etc. But that has nothing to do with linear flow of text - linear flow is a limitation that we do our best to work around.

[0] - Except we sometimes do, see: LabVIEW, UnrealEngine's Blueprints, Luna Lang, shader editors in just about every modern 3D application, ...

[1] - Though structural editors exist; see e.g. Paredit mode for Emacs, which lets you do edit operations on the tree your code represents, moving and splicing branches around while ensuring the tree structure is never damaged.

UncleMeatOP5y ago

> Oh, but you actually do! You write your programs in form of trees (abstract syntax ones), and those trees generally represent directed and usually acyclic graphs of dependencies.

Implicitly. This isn't actually represented graphically as a tree. You still have code in linear segments. You just know how to parse the text into its tree structure. The fact that code is actually parsed into an AST doesn't mean anything here. Pointing this out is just showing off. I'm happy to talk about programs as graphs (my PhD is in PL) but for the purposes of understanding how people write programs we write them as linear text.

> And the reason we don't lay out programs as visual, interactive graphs[0] is because text is faster to work with using digital tools.

Yes. And similarly, if you are publishing a recipe book the laying out text is easier than gantt charts.

> [1] - Though structural editors exist; see e.g. Paredit mode for Emacs, which lets you do edit operations on the tree your code represents, moving and splicing branches around while ensuring the tree structure is never damaged.

Yes we all know. There's been decades of research in this space. And basically nobody in real life uses them.

j / k navigate · click thread line to collapse