• solrize@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    17 days ago

    This is kinda cool and while the original Ada compilers were slow, does anyone know if Ada was inherently harder to compile than PL/I which was pretty capable at the time?

    Ada had a severe conceptual limitation, the program library that seemed to prevent separate compilation of Ada files. Ada buffs know the history of GNAT working around the limitation by using the actual program source files as the library.

    I do think Ada 2012 (like C++11) brought about a huge change in Ada style and maybe culture. So Ada83 is mostly historical. Ada83 programs from that era that I’ve tried still compile and work just fine though. That’s more than I can say about Python.

    • AdaOPM
      link
      fedilink
      arrow-up
      2
      ·
      13 days ago

      Ada is good at compiling files separately. Slowdowns can occur in name resolution, for example in the statement Proc (Fun_1 (Fun_2 (Fun_3 (Fun_4 (Var))))); if you have function names overloaded, the number of combinations the compiler has to consider grows exonentially with the number of nesting levels. So it may take time to find the right combination. I think the Ada 83 compilers were slow because of their experimental status, when the authors tried to implement all the features of the language without worrying about performance. The computer capabilities of those years were minuscule.

      In this frontend, they stored the parse tree in the file system: Diana