5 ms·

I started going through the docs. This language starts off with some heft sells - prevent errors, increase test coverage, etc. Then the docs mostly cover things

I started going through the docs. This language starts off with some heft sells - prevent errors, increase test coverage, etc. Then the docs mostly cover things like "you can call an array an array or a list" and stuff that isn't very interesting to me. It doesn't even show methods or things like that. I think 90% of the docs I've read so far should have just been a single page with one liners one after the other, and less interesting stuff that's got more depth should go further back. I don't think showing nested arrays and dictionaries is interesting to me after you've just told me about some super interesting testing / correctness stuff - lead with that! I skipped ahead to Decision Making. I think the example is so strange and contrived - three functions, each returns some number above 100, some logic after that that feels arbitrary? I would do something at least a little more universal like fib. The end of this section states "100% testable" - I'm confused. Why is this testable? I could not write one unit test to have 100% code coverage, not even line coverage. If I, for example, wrote a test that used the code provided, with an assertion assert add(3, 5) == 101 I would not hit f2 or f3, so I'm confused by: "A single unit test is enough to have 100% coverage on functions, always." That unit test was definitely not enough for 100% coverage. I skimmed the rest. For a language that states it's great for testing and preventing errors, I am at a loss as to how one would write a test for it, or handle an error. This looks like a pretty neat language, but you really gave me such a good hook and then no follow through.

rrobukef 6y ago
Since there are no if's (except at the end), every line is executed. Since all if's at the end can be placed on a single line, you have 100% line coverage. I don't think this language is very serious.
- MaxBarraclough 6y ago
  As you say, this doesn't sound right. If you force the programmer to write branch-free code (this appears to be the founding principle of the language [0]), that doesn't mean your boundary-value analysis [1] problems go away, it means you've made them less explicit. As you say, there's full line coverage for tests, but no guarantee of full equivalence-partition coverage. It's quite possible for branch-free code to fail on certain values. ctrl-f for overflow in [2] The 'Showcase' link is broken, the GitHub repo seems to show no examples, and the linked StackOverflow chaos tag is never used in relation to this language, so as you say, I'm not sure how serious this language really is. Fun idea though. (It's entirely possible I'm misusing the term boundary-value analysis. Corrections welcome.) [0] https://chaos-lang.org/docs/11_decision_making https://chaos-lang.org/docs/11_decision_making [1] https://en.wikipedia.org/wiki/Boundary-value_analysis https://en.wikipedia.org/wiki/Boundary-value_analysis [2] https://graphics.stanford.edu/~seander/bithacks.html https://graphics.stanford.edu/~seander/bithacks.html
norswap 6y ago
It would work if you somehow could get the value of `z` (the "return" value of `add` in the example). Then you have a unit test for `add` on its own, and if you also unit test `f1`, `f2` and `f3` (which it calls depending on the value of `z`), you'd have almost full unit test coverage. (You're not testing the conditions that lead to calling one of the `f` functions. Maybe it's chalked up to integration testing?) But yeah, I share much of your frustration. The Decision making section should be the first thing, and it should have a test example. Longer non-trivial programs examples should be contrived to reassure people that this not utterly impractical.

rrobukef 6y ago

Since there are no if's (except at the end), every line is executed. Since all if's at the end can be placed on a single line, you have 100% line coverage. I don't think this language is very serious.

MaxBarraclough 6y ago
As you say, this doesn't sound right. If you force the programmer to write branch-free code (this appears to be the founding principle of the language [0]), that doesn't mean your boundary-value analysis [1] problems go away, it means you've made them less explicit. As you say, there's full line coverage for tests, but no guarantee of full equivalence-partition coverage. It's quite possible for branch-free code to fail on certain values. ctrl-f for overflow in [2] The 'Showcase' link is broken, the GitHub repo seems to show no examples, and the linked StackOverflow chaos tag is never used in relation to this language, so as you say, I'm not sure how serious this language really is. Fun idea though. (It's entirely possible I'm misusing the term boundary-value analysis. Corrections welcome.) [0] https://chaos-lang.org/docs/11_decision_making https://chaos-lang.org/docs/11_decision_making [1] https://en.wikipedia.org/wiki/Boundary-value_analysis https://en.wikipedia.org/wiki/Boundary-value_analysis [2] https://graphics.stanford.edu/~seander/bithacks.html https://graphics.stanford.edu/~seander/bithacks.html

norswap 6y ago

It would work if you somehow could get the value of `z` (the "return" value of `add` in the example). Then you have a unit test for `add` on its own, and if you also unit test `f1`, `f2` and `f3` (which it calls depending on the value of `z`), you'd have almost full unit test coverage. (You're not testing the conditions that lead to calling one of the `f` functions. Maybe it's chalked up to integration testing?) But yeah, I share much of your frustration. The Decision making section should be the first thing, and it should have a test example. Longer non-trivial programs examples should be contrived to reassure people that this not utterly impractical.