[HN Gopher] Array-programming the Mandelbrot set
       ___________________________________________________________________
        
       Array-programming the Mandelbrot set
        
       Author : jcmorrow
       Score  : 36 points
       Date   : 2025-11-07 04:38 UTC (4 days ago)
        
 (HTM) web link (jcmorrow.com)
 (TXT) w3m dump (jcmorrow.com)
        
       | joshcsimmons wrote:
       | Mega-cool. This is a totally different way to think about it.
       | Uiua seems intimidating, I had never heard of it before.
        
         | jcmorrow wrote:
         | 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.
        
       | IshKebab wrote:
       | > 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.
        
         | jcmorrow wrote:
         | 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.
        
           | RodgerTheGreat wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2025-11-11 23:00 UTC)