[HN Gopher] The Yin and Yang of Programming
___________________________________________________________________
The Yin and Yang of Programming
Author : herodotus
Score : 18 points
Date : 2025-02-24 15:31 UTC (3 days ago)
(HTM) web link (billwadge.com)
(TXT) w3m dump (billwadge.com)
| MrMcCall wrote:
| > The answer is that bright Yang - iteration - has its own dark
| side, its own Yin. The presence of side effects (among other
| things) makes the programs hard to understand, verify, or modify.
|
| There are no "side-effects", only effects. The question is, "Have
| you planned and implemented their cascades according to the
| design requirements?"
|
| Change is all that matters in our digital logic manipulation
| business, and the only bottom-line results of any consequence are
| the bits that have been changed, plus the where, how, and why
| they did.
|
| The overall theme of the article presents an interesting and
| well-considered perspective, but my already knowing that all
| recursive algorithms have an equivalent iterative version is
| enough for me to be more interested in the traversals than the
| mechanism used to perform them.
|
| I want my data to flow in specifically precise ways. Choosing the
| proper tooling is an essential part of a project's work's
| earliest stages, and different folks succeed using different
| tools.
|
| [addendum: learned a cool new word today: eduction := the act of
| drawing out or bringing into view]
| lindig wrote:
| I like the idea mentioned in the article of exploring limited
| higher-order functions: functions that can only take functions as
| argument that themselves are not taking functions as arguments.
| But what simplification does this buy (in the implementation of
| such a language) over a language that is fully functional? It is
| not explained in the article.
| wduquette wrote:
| "But they treat functions as second-class objects that e.g. can't
| be returned as results." Returning a lambda in Java is really no
| big deal.
| wduquette wrote:
| "Java and C, for example, have elaborate while and for
| statements." OK, I'll give you the `for` statement; it's
| remarkably complicated when you look at it. But I don't see how
| you can call the `while` loop elaborate.
| JoelMcCracken wrote:
| Don't forget "do while", and the various control statements
| they support.
| cmontella wrote:
| Bill Wadge ruined my life! I stumbled upon his book on his
| language Lucid in the library when I was in grad school, and it
| opened up my eyes about different programming models. It inspired
| me to try making my own programming language and I've been doing
| it ever since!
|
| Going on 10 years now, no sign of losing interest. Don't read his
| book if you have an interest in the thing you're doing; it'll
| turn you into a compiler dev and you'll never do your interest
| again.
| noelwelsh wrote:
| I must confess, I have never been clear on the difference between
| iteration and recursion, or more specifically what differentiates
| a tail recursive loop from an iteration. Usage of iteration in
| the context of, say, an iterative solution technique such as
| gradient descent or an iterated function system feels very much
| like a (tail) recursion.
| eddd-ddde wrote:
| Recursion without optimizations requires a possibly unbounded
| stack. Tail call optimization allows optimizing certain
| recursive functions in a way that no nested stack frames are
| needed.
|
| So from a purely functional point of view, tail recursion and
| iteration are essentially a bijection.
___________________________________________________________________
(page generated 2025-02-27 23:00 UTC)