You’d expect the longest and most costly phase in the life cycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay th
  • bbarker@lemmy.ml
    1·
    2 years ago

    I generally take your point, though I believe FP can be applied to most domains with some benefit - it is just that existing, prevalent FP languages may not always be well suited for the job. In HPC for instance, there are a few interesting options:

    • For both games and HPC, Futhark may be of interest: “Futhark is a small programming language designed to be compiled to efficient parallel code. It is a statically typed, data-parallel, and purely functional array language in the ML family, and comes with a heavily optimising ahead-of-time compiler that presently generates either GPU code via CUDA and OpenCL, or multi-threaded CPU code.”

    • Sadly I can’t find it right now, but there was research language designed with the idea of separating the implementation from the specification, in such a way that the implementation could still be verified to conform to the specification; the specification was much more than a typical function signature as I recall. Basically you would write the function specification in a functional style, and then be able to have multiple implementations (e.g. for different hardware) conforming to that specification. I want to say this was from Standford but may be wrong about that.

    • ttmrichter@lemmy.ml
      1·
      2 years ago

      Futhark is of interest as a future direction, chiefly as a supplementary language for sub-pieces of a larger, performance-intensive program. Note that its creators, however, explicitly state:

      Futhark is not intended to replace existing general-purpose languages. The intended use case is that Futhark is only used for relatively small but compute-intensive parts of an application.

      This is not a negative point, incidentally! I personally use a lot of languages in my work because I find it’s better to use a tool honed to near-perfection for a particular use case than it is to employ another tool that does something not quite the same with lower quality. I wish more programmers learned more tools so they stopped doing the programming equivalent of hammering nails with a large wrench.