Notices by arclight (arclight@oldbytes.space)

@blogdiva @gulovsen My favorite bit of trivia about AIRPLANE! is that they originally tried to get Pete Rose as the Roger Murdock character. Filming was delayed until summer and Rose was out so they approached Kareem who was arguing with his accountant about if he could afford a really expensive Oriental rug. "If I do this movie, can I buy the rug?" The rest is history.

This parallels the casting in Zero Hour where Elroy "Crazylegs" Hirsch was cast in the same role (AIRPLANE! is a scene-for-scene parody of Zero Hour). Hirsch was a college football star and athletic director at the University of Wisconsin, alma mater of Abrams and the Zucker brothers.

@shriramk I hate these problems because there's always some implied or assumed formula. The unsatisfying (but IMO correct) answer is: As presented, there is not enough information to solve this problem.

One solution they may be looking for is:
2, 12, 36, 80, 150, 240, 356, ...

Made it partway through a more complex Godot tutorial and I'm getting hung up on the UI and near identical property (inspector) windows. It's still more memorable than Unity but still rather miserable. That probably goes away with familiarity; the basic tutorial I'm using is generally good but it's falling apart when describing actions without explicitly showing the navigation to where in the UI those actions take place. Too much "how do I get back to window <x>?"

I have an unfortunate and periodic question about functional languages and their appropriate problem domains. More specifically, what makes them unsuitable for physical modelling? Looking at instructional texts, scientific and engineering codes, etc, there's little evidence that functional programming has been used widely or successfully in this domain and I've never found a coherent explanation of the techniques advantages or disadvantages in this domain.

Much of this comes down to my limited experience so I'm actively trying to work against that. Still, with all the hype around FP, the way functional features are uncomfortably crowbarred into every facet of computing, I don't find them helpful at all in solving the problems I regularly face in my problem domain. They seem diversionary, obtuse, and simply inappropriate and I'm trying to sort out why; is this my perception or are there material technical reasons for this 'impedance mismatch' between FP and the practice of engineering?

Those who know me from the Birbsite have seen this question from me before. It's very much not an "I hate FP" question. I've done a little work with LISP and Racket, enough to see how they work basically. Technical codes don't typically deal with recursive data structures or boundless data structures like streams. Operations on fixed size arrays are far more common; APL's approach is far clearer than that of LISP. While matrix math is a critical aspect of technical code, it's typically a very tiny portion of the overall code - far more code is devoted to intermediate calculations, physical property or phenomena calculations than to matrix multiplication, inversion, conditioning, etc.

Mastodon is a new community I can ask so I'm asking again to find out what I'm missing.

It's "port most of your profile from the Birbsite to Mastodon" day. I still need to 'splode that into an actual introduction. One step at a time.

@brouhaha @b0rk Note that ACM has Buchholz's post mortem of Project Stretch ("Planning a Computer System") available in PDF form: https://amturing.acm.org/Buchholz_102636426.pdf It's from an era where you could still choose how many bits went into a byte or word, design your own floating point representation, etc.