5 ms·

AoC problems often benefit from knowledge of lexers, parsers, and other text processing gymnastics. People who’ve made compilers and interpreters are both attr

AoC problems often benefit from knowledge of lexers, parsers, and other text processing gymnastics. People who’ve made compilers and interpreters are both attracted to the problem solving element of AoC and good at solving those problems. Beyond that, making your own compiler or language is fun — more people should try it. These are great starting points: https://craftinginterpreters.com/ https://craftinginterpreters.com/ https://compilerbook.com/ https://compilerbook.com/

sph 4y ago
You just need Lisp then, and you can have all your DSLs you want for the problem at hand, instead of writing a new tokenizer, lexer, parser, interpreter every time. ;-)
- modernerd 4y ago
  Coalton is a good option to explore if you fancy trying AoC with Lisp: https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
- trenchgun 4y ago
  I disagree
  - sph 4y ago
    OK, you've convinced me.
- pierrebai 4y ago
  The problem, as far as AoC is concerned, is that Lisp tend to produce lisp-like DSL, so won't match AoC specs. Then again AoC specs are simple enough that you can still get away with using Lisp. Obviously, the OP targeted their language for AoC because, come on, whoever would want to have the ability to swap the precedence and meaning of operators? That would be a fresh hell that would make early-90s abuse of operator overloading in C++ seem like a joyful time.
- emmanueloga_ 4y ago
  I was very excited about lisp and "live" environments... I spent a while playing with various lisps, specially Clojure and ClojureScript. I still had to restart the REPLs from time to time! I came to the conclusion I enjoy more a language with near 0 startup time as opposed to live environments. Extremely loose typing is not a good compromise for me... but I also came to dislike the "straight jacket" of extremely strict types systems (like Haskell's and friends!). I think these days Golang is a good compromise between practicality and safety. It's fast, cross platform, it now supports generics (since 1.18) and it is overall OK to work with. I feel it falls in an OK sweetspot of features.
  - lispm 4y ago
    > near 0 startup time as opposed to live environments depends what you do, but many Lisp-based live environments have a near 0 startup time in a terminal. Try SBCL (a version of Common Lisp providing fast native compilation, incremental and batch) for example. SBCL also saves all memory (on demand) and can restart it, so one is in the same environment in milliseconds. https://sbcl.org https://sbcl.org
    - emmanueloga_ 4y ago
      TL;DR: golang tooling and environment (libraries, open source projects, ppl, etc) is way better than SBCL's. I did play with SBCL a bunch, and other a bit more "esoteric" lists too! [0]. I just feel like langs that are not in some form of top ten and with big corporate sponsoring are pretty much always super behind when it comes to tooling. You can get one or two or three AMAZING golang IDEs to work with (VS Code with Vim plugin is what I use). For SBCL, it HAS to be emacs. And I have mixed feelings about emacs, even when using Evil mode. 0: https://extemporelang.github.io/ https://extemporelang.github.io/
      - lispm 4y ago
        Personally I prefer the interactive development style of SBCL. Thus I would easily prefer SBCL and GNU Emacs over VS Code, especially given that VS Code uses telemetry to spy on its users.
emmanueloga_ 4y ago
On a related note, I would pay good money for "Crafting Interpreters Part II: Implementing Debuggers and Adding Visual Studio Code support for your language".

sph 4y ago

You just need Lisp then, and you can have all your DSLs you want for the problem at hand, instead of writing a new tokenizer, lexer, parser, interpreter every time. ;-)

modernerd 4y ago
Coalton is a good option to explore if you fancy trying AoC with Lisp: https://github.com/coalton-lang/coalton https://github.com/coalton-lang/coalton
trenchgun 4y ago
I disagree
- sph 4y ago
  OK, you've convinced me.
pierrebai 4y ago
The problem, as far as AoC is concerned, is that Lisp tend to produce lisp-like DSL, so won't match AoC specs. Then again AoC specs are simple enough that you can still get away with using Lisp. Obviously, the OP targeted their language for AoC because, come on, whoever would want to have the ability to swap the precedence and meaning of operators? That would be a fresh hell that would make early-90s abuse of operator overloading in C++ seem like a joyful time.
emmanueloga_ 4y ago
I was very excited about lisp and "live" environments... I spent a while playing with various lisps, specially Clojure and ClojureScript. I still had to restart the REPLs from time to time! I came to the conclusion I enjoy more a language with near 0 startup time as opposed to live environments. Extremely loose typing is not a good compromise for me... but I also came to dislike the "straight jacket" of extremely strict types systems (like Haskell's and friends!). I think these days Golang is a good compromise between practicality and safety. It's fast, cross platform, it now supports generics (since 1.18) and it is overall OK to work with. I feel it falls in an OK sweetspot of features.
- lispm 4y ago
  > near 0 startup time as opposed to live environments depends what you do, but many Lisp-based live environments have a near 0 startup time in a terminal. Try SBCL (a version of Common Lisp providing fast native compilation, incremental and batch) for example. SBCL also saves all memory (on demand) and can restart it, so one is in the same environment in milliseconds. https://sbcl.org https://sbcl.org
  - emmanueloga_ 4y ago
    TL;DR: golang tooling and environment (libraries, open source projects, ppl, etc) is way better than SBCL's. I did play with SBCL a bunch, and other a bit more "esoteric" lists too! [0]. I just feel like langs that are not in some form of top ten and with big corporate sponsoring are pretty much always super behind when it comes to tooling. You can get one or two or three AMAZING golang IDEs to work with (VS Code with Vim plugin is what I use). For SBCL, it HAS to be emacs. And I have mixed feelings about emacs, even when using Evil mode. 0: https://extemporelang.github.io/ https://extemporelang.github.io/
    - lispm 4y ago
      Personally I prefer the interactive development style of SBCL. Thus I would easily prefer SBCL and GNU Emacs over VS Code, especially given that VS Code uses telemetry to spy on its users.

emmanueloga_ 4y ago

On a related note, I would pay good money for "Crafting Interpreters Part II: Implementing Debuggers and Adding Visual Studio Code support for your language".