4 ms·

> Really, anything from the book Turtle Geometry would have a challenging time in a lot of functional languages. https://github.com/sergv/turtle-geometry https

> Really, anything from the book Turtle Geometry would have a challenging time in a lot of functional languages. https://github.com/sergv/turtle-geometry https://github.com/sergv/turtle-geometry Is an implementation of the book Turtle Geometry in Scheme. A Lisp dialect. > Which is not that most functional languages are bad. Just they don't usually even try to abstract over the graphical. I hate that folks see how well the abstract over functions and assume that is all programming is. There is an entire section of SICP dedicated to graphical abstraction using functions and function composition.

taeric 4y ago
Yeah, that isn't surprising, in that the book even mentions using LISP. However, this is a touch of a goal post shift with what folks typically mean by modern functional programming. (Which, to be fair, was always far more nebulous than folks admitted.) Specifically, though, this is my point. The turtle geometry abstraction is very imperative, by nature. It is still declarative, at a high level. But it is not functional. Despite that, it can be implemented in one of the classic functional languages. (Though, lisp's origins are far more imperative than you would think.)
- tankorsmash 4y ago
  Not quite turtle, but Elm (a pure FP) has something prettier, a full 3d renderer https://package.elm-lang.org/packages/ianmackenzie/elm-3d-scene/latest/ https://package.elm-lang.org/packages/ianmackenzie/elm-3d-sc... Demo: https://ianmackenzie.github.io/elm-3d-scene/examples/1.0.0/multiple-shadows.html https://ianmackenzie.github.io/elm-3d-scene/examples/1.0.0/m...
  - taeric 4y ago
    Does this have examples of a fractal that I just couldn't find? The outputs are certainly pretty, but I'm not entirely clear where this fits into what I was trying to say. :( That is, my argument is ultimately that for some things, having a section of code that is more imperative is actually far shorter than trying to accomplish the same thing otherwise. It is akin to changing coordinates. Some things are trivially conveyed with polar coordinates. Just as some are made much more difficult in that setting.

taeric 4y ago

Yeah, that isn't surprising, in that the book even mentions using LISP. However, this is a touch of a goal post shift with what folks typically mean by modern functional programming. (Which, to be fair, was always far more nebulous than folks admitted.) Specifically, though, this is my point. The turtle geometry abstraction is very imperative, by nature. It is still declarative, at a high level. But it is not functional. Despite that, it can be implemented in one of the classic functional languages. (Though, lisp's origins are far more imperative than you would think.)

tankorsmash 4y ago
Not quite turtle, but Elm (a pure FP) has something prettier, a full 3d renderer https://package.elm-lang.org/packages/ianmackenzie/elm-3d-scene/latest/ https://package.elm-lang.org/packages/ianmackenzie/elm-3d-sc... Demo: https://ianmackenzie.github.io/elm-3d-scene/examples/1.0.0/multiple-shadows.html https://ianmackenzie.github.io/elm-3d-scene/examples/1.0.0/m...
- taeric 4y ago
  Does this have examples of a fractal that I just couldn't find? The outputs are certainly pretty, but I'm not entirely clear where this fits into what I was trying to say. :( That is, my argument is ultimately that for some things, having a section of code that is more imperative is actually far shorter than trying to accomplish the same thing otherwise. It is akin to changing coordinates. Some things are trivially conveyed with polar coordinates. Just as some are made much more difficult in that setting.