Conversation

Notices

1. Embed this notice
   arclight (arclight@oldbytes.space)'s status on Wednesday, 05-Apr-2023 00:17:28 JST arclight

   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?

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Wednesday, 05-Apr-2023 00:17:24 JST Paul Cantrell

     in reply to

     @arclight
     Scattered quick thoughts:

     Performance has long been the deciding variable. It is ever less so, but Racket performance loosely speaking is still more Java-like than C/Rust/Swift-like. That may be your whole answer.

     You don’t mention any statically typed languages. They come with different performance and correctness tradeoffs. Why they’re also not used in this domain is a very interesting question.

   • Embed this notice
     arclight (arclight@oldbytes.space)'s status on Wednesday, 05-Apr-2023 00:17:26 JST arclight

     in reply to

     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.

   • Embed this notice
     Paul Cantrell (inthehands@hachyderm.io)'s status on Wednesday, 05-Apr-2023 00:17:40 JST Paul Cantrell

     in reply to

     @arclight

     LabVIEW is arguably functional, or at least functional-adjust. FRP and “synchronous” languages that model algos as directed graphs along whose edges data flows concurrently are IMO underexplored and might be promising for the work you describe.