[HN Gopher] The Spherical Cows of Programming
       ___________________________________________________________________
        
       The Spherical Cows of Programming
        
       Author : whobre
       Score  : 28 points
       Date   : 2025-10-19 15:18 UTC (7 hours ago)
        
 (HTM) web link (programmingsimplicity.substack.com)
 (TXT) w3m dump (programmingsimplicity.substack.com)
        
       | SoulMan wrote:
       | 2025-20-29 ?
        
         | TomatoCo wrote:
         | Looks like the first digit of each part of the date was
         | incremented by 1. I think it's meant to say 1025-10-19.
        
           | JadeNB wrote:
           | A rare pre-William the Conqueror essay on functional
           | programming.
        
             | mkoubaa wrote:
             | I've always known the Green Knight was something of a time
             | traveler. Knew too much.
        
             | indigoabstract wrote:
             | Had the battle at Hastings went the other way, the state of
             | functional programming might have been much different,
             | methinks.
             | 
             | Alas, 'tis not meant to be.
        
       | bos wrote:
       | This is a bizarre essay by someone who understands neither
       | functional programming nor the history of computers.
       | 
       | > To be kind, we've spent several decades twisting hardware to
       | make the FP spherical cow work "faster", at the expense of
       | exponential growth in memory usage, and, some would argue, at the
       | expense of increased fragility of software.
       | 
       | There is not one iota of support for functional programming in
       | any modern CPU.
        
         | muststopmyths wrote:
         | TFA actually refers to "other spherical cows", not just FP.
         | 
         | Doesn't makes any point very coherently, but it's not
         | exclusively about FP though that gets mentioned a lot.
        
           | KerrAvon wrote:
           | "spherical cow" seems to be a bizarre, pointless substitution
           | for "encapsulation" or "object oriented programming"
           | depending on the context.
        
             | jagged-chisel wrote:
             | It's a theoretician's trope. "Identical and spherical" is
             | the baseline state of the objects in a system one wishes to
             | model. There's are several jokes with this as the
             | punchline.
             | 
             | An executive is retiring. He's been very fond of horse
             | races, but has been very responsible throughout the years.
             | Now with some free time on his hands, he spends more time
             | than ever at the tracks and collects large amounts of data.
             | He takes his data, along with his conviction that he's
             | certainly onto something, to a friend in research at a
             | nearby university. He convinces his friend to take a look
             | at his data and find a model they can use to win at
             | betting. After many delays, and the researcher becoming
             | more disheveled over months of work, he returns to the
             | retired executive to explain his model. He begins "if we
             | assume all the horses are identical and spherical..."
        
             | forgetfulness wrote:
             | That author uses it to mean "model", as he calls a variety
             | of programming models "spherical cows".
             | 
             | Well, for sure, a core tenet of computer science is that
             | all models of computing are equally powerful in what inputs
             | they can map to what outputs, if you set aside any other
             | details
        
               | wk_end wrote:
               | He uses it to mean all sorts of things. He describes
               | "string interpolation" as a "spherical cow".
        
           | kgwgk wrote:
           | > TFA actually refers to "other spherical cows"
           | 
           | What does that mean in the context of the comment you reply
           | to - which includes the literal quote about "twisting
           | hardware to make the FP spherical cow work faster"? The
           | article may not be exclusively about FP but nobody said it
           | was.
        
           | JumpCrisscross wrote:
           | > _TFA actually refers to "other spherical cows", not just
           | FP_
           | 
           | I'm genuinely curious if anyone can derive a consistent
           | definition of what the author thinks a spherical cow is.
        
         | imtringued wrote:
         | The definition of spherical cow is also butchered beyond
         | recognition.
         | 
         | Spherical cows are about simplifying assumptions that lead to
         | absurd conclusions, not simplified models or simplified
         | notation in general.
         | 
         | Calling functional programming a spherical cow when you mean
         | that automatic memory management is a simplifying assumption,
         | is such a gross sign of incompetence that nobody should keep
         | reading the rest of the blog.
        
           | JumpCrisscross wrote:
           | > _Spherical cows are about simplifying assumptions that lead
           | to absurd conclusions_
           | 
           | There aren't any commonly-accepted conclusions from spherical
           | cows because the bit is the punch line. It's a joke a physics
           | 101 student makes when toughing through problems that assume
           | away any real-world complexity and thus applicability.
           | 
           | Spherical cows, in the real world, are pedagogical tools
           | first, approximations second, and mis-applied models by
           | inexperienced practitioners third.
           | 
           | "Hello World" is a spherical cow. Simplifying assumptions
           | about data are spherical cows. (And real dairy farmers
           | implicitly assume flat cows when using square feet to
           | determine how much room and grazing area they need per head.)
        
           | dragontamer wrote:
           | Spherical cows?
           | 
           | The joke as I recall it, was a physics student who brags that
           | he can predict the winner of any horserace, so long as all of
           | the horses were perfectly spherical perfectly elastic horses.
           | 
           | I'm actually not sure where cows came in, but maybe there's a
           | different version of the joke out there.
        
             | seanhunter wrote:
             | The spherical cow joke generally goes that a farmer has
             | some problems with his cows (maybe it's how much milk
             | they're producing I don't remember) and so his daughter
             | says "you should ask my boyfriend to help - he's a
             | physicist and really clever". So the farmer asks the
             | boyfriend and he says "Well, assume the cows are
             | spherical..."
             | 
             | The joke being because when you do mechanics you generally
             | start modelling any problem with a lot of simplifying
             | assumptions. In particular, that certain things are
             | particles- spherical and uniform.
        
               | ngcc_hk wrote:
               | The article posted seems a waste of time. This is a
               | remedy https://youtu.be/6oLvgxLFMKo?si=m38yRNygsLniS3Q9
        
           | jibal wrote:
           | Spherical cows are very much about simplified models--that's
           | what modeling a cow as a sphere is all about.
        
         | seanhunter wrote:
         | Totally agree. In addition, one of his examples (Mars
         | Pathfinder) has absolutely nothing to do with functional
         | programming or simplifying assumptions of any kind. The mars
         | pathfinder problem was caused by a priority inversion on a
         | mutex - exactly the sort of thing that all programmers rightly
         | consider hard and that things like software transactional
         | memory in FP would prevent. Here's the famous email "What
         | Really Happened on Mars?" which was written by the a pathfinder
         | software engineer and explains the issue
         | 
         | https://dataverse.jpl.nasa.gov/dataset.xhtml?persistentId=hd...
         | 
         | Even by the standards of substack TFA is an extraordinarily
         | poor blogpost.
        
         | foobarian wrote:
         | This would probably apply better in the ~80s after all the hard
         | work building Lisp/Forth machines
        
         | andersmurphy wrote:
         | Yeah the whole article is absurd. Functional programming is not
         | even remotely mainstream. So not sure who is twisting?
        
         | hinkley wrote:
         | You'd have to cross your eyes pretty hard but SIMD and GPUs.
         | 
         | But for the classic ALU, I can't think of anything. Anything
         | that helps FP was probably meant to help with text processing
         | and loops in general.
        
         | quamserena wrote:
         | > There is not one iota of support for functional programming
         | in any modern CPU.
         | 
         | But there is a ton of support for speeding up imperative,
         | serial programs (aka C code) with speculative execution, out-
         | of-order execution, etc.
        
         | Scubabear68 wrote:
         | Trying to be as kind as possible in my interpretation of the
         | article, my take was that the author got stock on the
         | "spherical cow" analogy early on and couldn't let it go. I
         | think there are nuggets of good ideas here which generally
         | tries to talk to leaky abstractions and impedance mis-matches
         | in general between hardware and software, but the author was
         | stuck in spherical cow mode and the words all warped toward
         | that flawed analogy.
         | 
         | This is a great example of why rewrites are often important, in
         | both English essays and blogs as well as in software
         | development. Don't get wedded to an idea too early, and if
         | evidence starts piling up that you're going down a bad path, be
         | fearless and don't be afraid of a partial or even total rewrite
         | from the ground up.
        
         | Yoric wrote:
         | Agreed, it's really weird.
         | 
         | To the best of my understanding, the author describes the
         | structured imperative programming style used since the 70s as
         | "functional" because most languages used since the 70s offer
         | functions. If so, it makes sense to describe hardware is
         | optimized for what the author calls "functional programming",
         | since hardware has long been optimized for C compilers. It also
         | makes sense to describe callbacks, async, then, thread-safety
         | as extensions of this definition if "functional programming",
         | because yes, they're extensions of structured imperative
         | programming.
         | 
         | There are a few other models of programming, including what
         | people actually call functional programming, or logical
         | programming, or synchronous programming, or odder beasts such
         | as term rewriting, digraphs, etc. And of course, each of them
         | has its own tradeoffs.
         | 
         | But all in all, I don't feel that this article has anything to
         | offer to readers.
        
         | karmakaze wrote:
         | The most credit I could give is that the post itself is a
         | spherical approximation of the subject and the point being made
         | is that they discovered async dataflow programming and think
         | it's underrepresented. _I 've only seen it compared it to
         | command-line pipes for explanation of the concept, not
         | understanding implementation characteristics._
         | 
         | I agree that code tends to be overrepresented--we don't 'data
         | golf'. Even non-async dataflow oriented programs are much
         | easier to follow, which happens to play exceptionally well with
         | FP.
        
         | mananaysiempre wrote:
         | If you squint so hard that SSA is functional programming[1] and
         | register renaming is SSA, modern CPUs are kind of functional,
         | but that of course has nothing to do with functional
         | programming done by the user, it's just the best way we know to
         | exploit the state of the art in semiconductors to build CPUs
         | that execute (ostensibly) serial programs.
         | 
         | [1] https://www.cs.princeton.edu/~appel/papers/ssafun.pdf
        
       | bitwize wrote:
       | I would say "sequential execution of CPU instructions" and "O(1)
       | memory access" are two major spherical cows in computing.
       | Probably the biggest, though, is the "fast, reliable network". We
       | build systems that treat networked resources as if they were
       | local: always there and instantly available. Heck, most of our
       | stuff wouldn't even run without the database being online, and
       | that's usually provided over the network.
        
         | Yoric wrote:
         | You are, of course, right, although I'd say that it's fairly
         | unusual for the "sequential execution of CPU instructions"
         | abstraction to leak.
         | 
         | The wrongfully assumed "O(1) memory access" (or worse,
         | wrongfully assumed O(1) data structure access even when the
         | data structure actually isn't O(1)) showed up more frequently
         | in my experience. And I still don't understand how we keep
         | writing code that assumes "fast, reliable network" when we're
         | reminded every day that code is neither fast nor reliable.
        
           | bitwize wrote:
           | > You are, of course, right, although I'd say that it's
           | fairly unusual for the "sequential execution of CPU
           | instructions" abstraction to leak.
           | 
           | On x86. x86 and x86-64 usually do a good job of enforcing
           | memory access order _as if_ the instructions were executed
           | sequentially. Other architectures, not so much. On PowerPC
           | you had to put explicit memory barriers guaranteeing a
           | certain access order with the  'eieio' instruction. ARM
           | processors feature similar weak memory order, but the Apple
           | M1 and later feature a special mode that guarantees strong
           | x86-64 memory order, to make emulation for programs written
           | for Intel Macs easier.
        
       | KerrAvon wrote:
       | Calling random things "spiritual cows" is a fine comedy bit, but
       | has no place in a professional environment where you have to be
       | able to communicate with others to achieve a common goal. TFA is
       | just shitposting in blog form. Not sure if the author realizes
       | that.
        
         | jagged-chisel wrote:
         | Did ... did you mean "spiritual"? Because, depending on
         | culture, spiritual cows would indeed be a fine comedy bit.
        
         | ok123456 wrote:
         | Spherical. "Spherical cows" is a common expression in physics
         | that means an oversimplified model (e.g., modeling a cow as a
         | sphere).
         | 
         | https://en.wikipedia.org/wiki/Spherical_cow
        
           | hinkley wrote:
           | I'm also having trouble figuring out why mentioning _sacred_
           | cows would be a problem in business. Other than potential
           | career suicide for handling the news poorly.
        
       | DiggyJohnson wrote:
       | I'm more DevOps but we have issues wear we discuss the spherical
       | cow of build pipelines like we have a handful of static
       | environments in the same cloud account with the same permissions
       | and database requirements that does not stand up to encountering
       | the actual requirements where we have destructible and static
       | environments, an environment in a different cloud account for our
       | customer to review per contract requirements, and a prod
       | environment with heavy security and data protection requirements
       | hosted by a entirely different cloud vendor with bad
       | infrastructure support resources.
        
         | DiggyJohnson wrote:
         | This might be my longest run on sentence since I learned to
         | write lol
        
       ___________________________________________________________________
       (page generated 2025-10-19 23:01 UTC)