[HN Gopher] Complexity Considerations
       ___________________________________________________________________
        
       Complexity Considerations
        
       Author : bradrn
       Score  : 8 points
       Date   : 2022-01-01 13:15 UTC (9 hours ago)
        
 (HTM) web link (www.red-lang.org)
 (TXT) w3m dump (www.red-lang.org)
        
       | bradrn wrote:
       | I've editorialised the title very slightly to highlight what I
       | thought was the most interesting part of the article, a
       | meditation on complexity, scaling, libraries and the role of
       | language ecosystem in software development. Key quote:
       | 
       | > It used to be that you could take a FORTRAN, COBOL, Lisp, VB,
       | Pascal/Delphi, Access/PowerBuilder, dBase/Clipper/Paradox, or
       | even a Java developer, drop them into a project, and they could
       | work from a solid core, learning the team's custom bits and any
       | commercial tools as they went. With JS leading the way, but not
       | alone in this, a programmer can only rely on a much smaller core,
       | relative to how many libraries are used.
       | 
       | > Because those libraries, and the choices to use a particular
       | combination of them were not designed to work together, there is
       | no guarantee (or perhaps hope) of consistency to leverage. It's
       | worse if you came from a history of other tools that were based
       | on different principles or priorities, because you have to
       | unlearn, breaking the patterns in your mind. Or you convince
       | people to use what you did before, even if there is overlap with
       | tools already in use.
       | 
       | I am but a lowly hobbyist programmer, writing little programs for
       | my own amusement, yet this assessment rings true to me. I am
       | happiest when writing my own code and solving my own problems,
       | not when I am wrestling with a half-consistent library or trying
       | to interoperate between two vaguely contradictory platforms. I
       | start writing an interpreter for string processing, which I do in
       | my favourite language Haskell... but then I want to give it a GUI
       | (requiring Unicode support!), which I have to do in Qt using
       | C++... and that means I have to figure out the FFI between the
       | two -- easier than you might think, but still somewhat painful...
       | and then before I know it I'm spending my time writing code to
       | convert from C strings to Haskell strings, rather than actually
       | solving the problems I wanted to solve. Thankfully such things
       | haven't completely taken over the project yet, but I expect it
       | will only get worse as the projects get bigger. A single good
       | language with a single coherent ecosystem would be amazing, and
       | Red seems closer to that goal than any other project I've seen.
        
       ___________________________________________________________________
       (page generated 2022-01-01 23:01 UTC)