4 ms·

Looks interesting, but again a dynamic specification language. Wonder how long it takes that others too start to switch to statically typed specification langua

by Rochus 3y ago

Looks interesting, but again a dynamic specification language. Wonder how long it takes that others too start to switch to statically typed specification languages which from my point of view are an essential feature for any large system (see e.g. BUSY). And after scanning the documentation I still ask myself what the core benefit of Origami is supposed to be compared to e.g. Meson or Cmake.

HeitorFM 3y ago
Hi Rochus, congratulation on BUSY, and thanks for the comments. Will work on a better comparative explanation soon. Regarding static X dynamic. For this kind of payload i think dynamic will be faster ans easier to work with. Even with big builds we don't have to much variables hammering. And there are big systems built on python and Ruby and JS. Best
- Rochus 3y ago
  Thanks. It's far from perfect, but at least it made it possible to build the Oberon IDE with toolchain and LeanQt all in one batch on all platforms with no requirements other than a C89 and C++98 compiler. > Even with big builds we don't have to much variables hammering Have e.g. a look at the Chromium or Dart VM build; it's huge and very complex; understanding the build system given that most of the relevant information is only available during the build is frightening; I even built my own tool to at least get some orientation using best-effort cross-referencing, see https://github.com/rochus-keller/GnTools https://github.com/rochus-keller/GnTools.
  - HeitorFM 3y ago
    Yeah. The observability of the builds system are bad for all of then in all languages. This GnTools looks really handy. Let me ask. For the BUSY. Have you coded the lexer/parser from scratch ?
    - Rochus 3y ago
      > Have you coded the lexer/parser from scratch Yes. Here is the lexer: https://github.com/rochus-keller/BUSY/blob/main/bslex.c https://github.com/rochus-keller/BUSY/blob/main/bslex.c and here is the parser: https://github.com/rochus-keller/BUSY/blob/main/bsparser.c https://github.com/rochus-keller/BUSY/blob/main/bsparser.c and here is the language specification: http://software.rochus-keller.ch/busy_spec.html http://software.rochus-keller.ch/busy_spec.html I also developed and checked the EBNF in parallel using my EbnfStudio tool; this tool could also generate a parser, but since I'm using much of the Lua VM infrastructure a manual parser implementation was more straight-forward .
      - HeitorFM 3y ago
        Impressive. Gona take a detailed look later. Thanks for the references. And congratulations on the hero effort again !

by Rochus 3y ago

HeitorFM 3y ago

Hi Rochus, congratulation on BUSY, and thanks for the comments. Will work on a better comparative explanation soon. Regarding static X dynamic. For this kind of payload i think dynamic will be faster ans easier to work with. Even with big builds we don't have to much variables hammering. And there are big systems built on python and Ruby and JS. Best

Rochus 3y ago
Thanks. It's far from perfect, but at least it made it possible to build the Oberon IDE with toolchain and LeanQt all in one batch on all platforms with no requirements other than a C89 and C++98 compiler. > Even with big builds we don't have to much variables hammering Have e.g. a look at the Chromium or Dart VM build; it's huge and very complex; understanding the build system given that most of the relevant information is only available during the build is frightening; I even built my own tool to at least get some orientation using best-effort cross-referencing, see https://github.com/rochus-keller/GnTools https://github.com/rochus-keller/GnTools.
- HeitorFM 3y ago
  Yeah. The observability of the builds system are bad for all of then in all languages. This GnTools looks really handy. Let me ask. For the BUSY. Have you coded the lexer/parser from scratch ?
  - Rochus 3y ago
    > Have you coded the lexer/parser from scratch Yes. Here is the lexer: https://github.com/rochus-keller/BUSY/blob/main/bslex.c https://github.com/rochus-keller/BUSY/blob/main/bslex.c and here is the parser: https://github.com/rochus-keller/BUSY/blob/main/bsparser.c https://github.com/rochus-keller/BUSY/blob/main/bsparser.c and here is the language specification: http://software.rochus-keller.ch/busy_spec.html http://software.rochus-keller.ch/busy_spec.html I also developed and checked the EBNF in parallel using my EbnfStudio tool; this tool could also generate a parser, but since I'm using much of the Lua VM infrastructure a manual parser implementation was more straight-forward .
    - HeitorFM 3y ago
      Impressive. Gona take a detailed look later. Thanks for the references. And congratulations on the hero effort again !