4 ms·

Running code at compile time seems pretty powerful; mostly for tests.

by Joof 12y ago

lycos1 12y ago
I really liked that feature. Also being able to write check functions for your function.
lostcolony 12y ago
Powerful, yes, for tests, I'm not so sure. If it stops the compilation when a test breaks, that forces you to fix it, but it also would irritate the crap out of me, since I'd want to test the code changes before refactoring the tests (I'm not a fan of TDD, at least when it comes to fixing bugs in code; let me fix the bug, then figure out what, if any, test broke (if none, add a test for that bug). I can't imagine it's particularly useful in game development either, when there can be a huge disconnect between something seeming correct at the program logic level, but massively broken visually; writing a test to make sure that that animation is smooth isn't easily doable). If it doesn't stop the compilation on breaking the tests...it's not really any different than any other continuous integration style tool (or even a make script that adds a call to test after compiling), except that the tests are being run as the code is compiled, forcing you to wait the extra time even when experimenting. And it's unclear what code is intended for tests, versus other uses of the facility (such as DSLs and language extensions).
- steveklabnik 12y ago
  The compiler currently bails upon encountering the first error, he said this was a feature, not a bug.
  - brandonbloom 12y ago
    I guess that he considers this a feature for two reasons: 1) He's used to the atrociously poor error recovery of typical C++ compilers. You almost always get different errors after you've fixed the first error. 2) His language's semantics enforce sequential compilation, such that it's not reasonably possible to continue evaluating in the face of many or most errors. #1 is a consequence of not designing for error recovery from the beginning. He's going to run in to a problem when people want squiggly red underlines in their IDE. As projects grow in size, #2 is going to breakdown quickly without a good separate compilation unit story.
    - jblow 12y ago
      Come on guys, think about it! It is trivial to make your test routine log the error but return true so that the compiler doesn't stop.
      - brandonbloom 12y ago
        I'm totally fine with #2, if you do have a good separate compilation unit story. I'm fact, it's how many lisps work, and it works out quite well. However, I wasn't talking just about your compile time asserts for #1. There's also syntax errors, undefined identifiers, missing or extra arguments, etc, etc. That stuff is hard to get right if you want to report many independent errors. It gets much easier if you can change your language, so don't wait too long to take a swing at it.

Running code at compile time seems pretty powerful; mostly for tests.

by Joof 12y ago

Running code at compile time seems pretty powerful; mostly for tests.

lycos1 12y ago

I really liked that feature. Also being able to write check functions for your function.

lostcolony 12y ago

Powerful, yes, for tests, I'm not so sure. If it stops the compilation when a test breaks, that forces you to fix it, but it also would irritate the crap out of me, since I'd want to test the code changes before refactoring the tests (I'm not a fan of TDD, at least when it comes to fixing bugs in code; let me fix the bug, then figure out what, if any, test broke (if none, add a test for that bug). I can't imagine it's particularly useful in game development either, when there can be a huge disconnect between something seeming correct at the program logic level, but massively broken visually; writing a test to make sure that that animation is smooth isn't easily doable). If it doesn't stop the compilation on breaking the tests...it's not really any different than any other continuous integration style tool (or even a make script that adds a call to test after compiling), except that the tests are being run as the code is compiled, forcing you to wait the extra time even when experimenting. And it's unclear what code is intended for tests, versus other uses of the facility (such as DSLs and language extensions).

steveklabnik 12y ago
The compiler currently bails upon encountering the first error, he said this was a feature, not a bug.
- brandonbloom 12y ago
  I guess that he considers this a feature for two reasons: 1) He's used to the atrociously poor error recovery of typical C++ compilers. You almost always get different errors after you've fixed the first error. 2) His language's semantics enforce sequential compilation, such that it's not reasonably possible to continue evaluating in the face of many or most errors. #1 is a consequence of not designing for error recovery from the beginning. He's going to run in to a problem when people want squiggly red underlines in their IDE. As projects grow in size, #2 is going to breakdown quickly without a good separate compilation unit story.
  - jblow 12y ago
    Come on guys, think about it! It is trivial to make your test routine log the error but return true so that the compiler doesn't stop.
    - brandonbloom 12y ago
      I'm totally fine with #2, if you do have a good separate compilation unit story. I'm fact, it's how many lisps work, and it works out quite well. However, I wasn't talking just about your compile time asserts for #1. There's also syntax errors, undefined identifiers, missing or extra arguments, etc, etc. That stuff is hard to get right if you want to report many independent errors. It gets much easier if you can change your language, so don't wait too long to take a swing at it.