Array-programming the Mandelbrot set
jcmorrow.com
Array-programming the Mandelbrot set
1–10 of 23 posts
Re: Array-programming the Mandelbrot set
#2[deleted]
Re: Array-programming the Mandelbrot set
#3Mega-cool. This is a totally different way to think about it. Uiua seems intimidating, I had never heard of it before.
Re: Array-programming the Mandelbrot set
#4Mega-cool. This is a totally different way to think about it. Uiua seems intimidating, I had never heard of it before.
You should definitely check out uiua (https://www.uiua.org/)! Array programming can certainly be intimidating, but I think it's worth doing for a few reasons:
- The "array"-ish solution to a problem is usually a very data-oriented solution. Even if you aren't working in an array-oriented language (and just to be clear, I'm not advocating that people write production code in array languages), "thinking in arrays" helps me come up with more elegant solutions.
- Learning array programming is a little like learning to program all over again. If you really enjoyed the process of learning to program, it lights up those same brain circuits, which I found really enjoyable.
- If you ever want to do any graphics programming the mental model can be very helpful. Array programming really helped me wrap my mind around how shader programs are executed.
Uiua is little unique in that it is also a stack-based language, so learning both paradigms at the same time can definitely be a little challenging, but I think it's well worth it.
Re: Array-programming the Mandelbrot set
#5> As is often the case with array programming, I revisited this last week only to realize I couldn’t read it
> The advantage of array languages in my experience has always been their immediacy.
They seem to have a lot in common with regexes in that regard. Super useful for interactive use cases in editors, search engines, etc. But if you find yourself saving a regex it's at least code smell and probably a red flag.
Some of the array language people seem to think it's sane to write an entire program in regex-lang, which is less red flag and more red banner flying through the sky.
Re: Array-programming the Mandelbrot set
#6> As is often the case with array programming, I revisited this last week only to realize I couldn’t read it > The advantage of array languages in my experience has always been their immediacy. They seem to have a lot in common with regexes in that regard. Super useful for interactive use cases in editors, search engines, etc. But if you find yourself saving a regex it's at least code smell and probably a red flag. S…
100% agree. Even when I am working with J or Uiua enough that I can comfortably read them, I can't really imagine trying to work on a large (even just thousands of lines, let alone larger) project in them. I know that they exist, and I assume that with a team of competent programmers some different mechanisms would evolve to make things easier to understand, but given the choice between Java and uiua, I would much rather maintain a multi-person multi-year project in Java. The verbosity/boilerplate becomes a strength in that setting, rather than a weakness.
Re: Array-programming the Mandelbrot set
#7> As is often the case with array programming, I revisited this last week only to realize I couldn’t read it > The advantage of array languages in my experience has always been their immediacy. They seem to have a lot in common with regexes in that regard. Super useful for interactive use cases in editors, search engines, etc. But if you find yourself saving a regex it's at least code smell and probably a red flag. S…
100% agree. Even when I am working with J or Uiua enough that I can comfortably read them, I can't really imagine trying to work on a large (even just thousands of lines, let alone larger) project in them. I know that they exist, and I assume that with a team of competent programmers some different mechanisms would evolve to make things easier to understand, but given the choice between Java and uiua, I would much ra…
I have experience working with large codebases in K. In practice, most of those codebases don't look dramatically different from any other garden-variety dynamic language. The high-level architectures are similar, and intrinsically-serial business logic still tends to have a lot of named function calls and conditionals. The algorithmic parts, where real work is happening, shrink down to little clusters of operators here and there. Prototypes of new systems and services can be written in a terse, brick-of-code style like some of the K you may find online, but as they get integrated into larger systems they tend to grow comments, descriptive identifier names, and shorter, more diff-friendly lines.
I've never found it hard to come back to reading K after long absences, in no small part because the set of primitives in K is a small fraction of the set in J (or uiua) and the notation, while terse, is more suggestive and legible to me than J's emphasis on digraphs and forks, or the "unicode-soup" of mismatched characters that some modern APL descendants reach for. K is an equally excellent notation for experimenting in a REPL or discussing ideas on a whiteboard.
Re: Array-programming the Mandelbrot set
#8Earlier quoted context omitted.
100% agree. Even when I am working with J or Uiua enough that I can comfortably read them, I can't really imagine trying to work on a large (even just thousands of lines, let alone larger) project in them. I know that they exist, and I assume that with a team of competent programmers some different mechanisms would evolve to make things easier to understand, but given the choice between Java and uiua, I would much ra…
I have experience working with large codebases in K. In practice, most of those codebases don't look dramatically different from any other garden-variety dynamic language. The high-level architectures are similar, and intrinsically-serial business logic still tends to have a lot of named function calls and conditionals. The algorithmic parts, where real work is happening, shrink down to little clusters of operators h…
I think this often boils down to the same criticisms directed to LISP's FORMAT? https://gigamonkeys.com/book/a-few-format-recipes has my favorite take, "While FORMAT's control strings can be cryptic, at least a single FORMAT expression doesn't clutter things up too badly."
Feels like the same would be true for the array languages. Obviously code golfing it all down to be an array manipulation is going to be unreadable. But if you are legit doing manipulations on an array of data, probably going to be pretty hairy in the expanded version, as well. I can see wins from not necessarily naming every intermediate part of the process.
Re: Array-programming the Mandelbrot set
#9Earlier quoted context omitted.
100% agree. Even when I am working with J or Uiua enough that I can comfortably read them, I can't really imagine trying to work on a large (even just thousands of lines, let alone larger) project in them. I know that they exist, and I assume that with a team of competent programmers some different mechanisms would evolve to make things easier to understand, but given the choice between Java and uiua, I would much ra…
I have experience working with large codebases in K. In practice, most of those codebases don't look dramatically different from any other garden-variety dynamic language. The high-level architectures are similar, and intrinsically-serial business logic still tends to have a lot of named function calls and conditionals. The algorithmic parts, where real work is happening, shrink down to little clusters of operators h…
Thanks for sharing that perspective! I have not delved too far into k, though I have been a few times confused and discouraged by the fact that there are different versions of the language that are not compatible with each other, and some are proprietary (if I understand the state of the language correctly). Is there a specific version that is best to learn first?
Edit: I just realized that you are the creator of https://beyondloom.com/tools/specialk.html and https://beyondloom.com/decker/index.html. I just want to say that your work is awesome! I've really enjoyed reading through your website many a time.
Re: Array-programming the Mandelbrot set
#10Earlier quoted context omitted.
I have experience working with large codebases in K. In practice, most of those codebases don't look dramatically different from any other garden-variety dynamic language. The high-level architectures are similar, and intrinsically-serial business logic still tends to have a lot of named function calls and conditionals. The algorithmic parts, where real work is happening, shrink down to little clusters of operators h…
Thanks for sharing that perspective! I have not delved too far into k, though I have been a few times confused and discouraged by the fact that there are different versions of the language that are not compatible with each other, and some are proprietary (if I understand the state of the language correctly). Is there a specific version that is best to learn first? Edit: I just realized that you are the creator of htt…
ngn/k is a performant FOSS implementation of k6, but it has many constraints and limitations that may make composing large programs difficult. It may be the best dialect for tinkering and learning the language. https://codeberg.org/ngn/k
oK is a slow browser-based FOSS implementation of k6, with fun bells and whistles like "iKe", a visual livecoding environment. ngn/k and oK have diverged a bit, but are largely similar: https://github.com/JohnEarnest/ok
Q is a K-derived language built into kdb+; this is probably the most commercially viable dialect to learn, with the best educational materials (I recommend Nick Psaris' Q Tips), but it is proprietary, with (last I checked) free licenses available for personal use.
If you've seen Decker you may also have been exposed to Lil, which is similar in many ways to Q. It is more verbose and less expressive than Q or K, but I've generally heard people say they find it comparatively accessible: http://beyondloom.com/tools/trylil.html