4 ms·
As far as I understand after reading the docs for 5 minutes, this section is the core original idea behind the language: https://chaos-lang.org/docs/11_decisio
by golergka 7y ago
As far as I understand after reading the docs for 5 minutes, this section is the core original idea behind the language:
https://chaos-lang.org/docs/11_decision_making https://chaos-lang.org/docs/11_decision_making
> Decision making(a.k.a. control structures) in Chaos language is only achievable on function returns for the sake of zero cyclomatic complexity.
This looks as original and language-defining as Rust's borrow checker. I really wish authors changed their docs accordingly. Everything else is pretty standard on a conceptual level, but this still has me thinking whether it's a work of pure genius, a joke language or both.
- curryst 7y agoThat doesn't seem possible. A function with no flow control statements has a cyclomatic complexity of 1. I.e. function retVal(x) { return x } has a cyclomatic complexity of 1 because there is 1 path through. Even ignoring that issue, even if the control flow statement is in the return, it still has a cyclomatic complexity of 2. I.e. function isEqual(x, y) { return x == y } still has a cyclomatic complexity of 2, you're just hiding it. The actual logic flow in terms of nodes is ``` if (x == y) { return true } else { return false } ``` It's entirely possible for a single line to have a cyclomatic complexity of more than 1. Ternaries, for example, would have a cyclomatic complexity of 3.
- mertyildiran 7y agoYes, you are correct. The very intuitive approach we took on decision making is the key point of the language. I came up with this idea of designing a language with no "if" after dealing with various untestable codebases for years. They were literally untestable because of the technical debt caused by the extensive amount of "if" usage in the function bodies, especially the guard clauses makes it 1 "if" minimum for almost every functions. So at the end I have exhausted because of the if(s) and decided to create a language that forces you to have minimum technical debt.
- jandrese 7y agoI'm still not convinced it doesn't just sweep the complexity under the rug. Ultimately you still need to branch unless you only want the language to do pure mathematical computation or something like that. Only now every branch needs to be hidden in a function call.
- pmontra 7y agoI have a large Elixir project with less than 10 branches (if then else) and they were written by other developers. Conditional logic is done either in pattern matching in function definitions (and some guard) or case/cond or with/else. I guess case/cond can be implemented with the return mechanism of Chaos. Maybe it's going to feel weird, maybe not. There is no pattern matching and I got the feeling that's going to complicate things but again, it can be emulated to some degree but the return mechanism. Instead of def a(0), do: "a" def a(1), do: "b" def a(_n), do: "c" Probably we'll be writing str def a(n) num x = n end { x == 0 : "a" x == 1 : "b" default: "c" } Having to define that x variable feels like a waste of code and reasoning on x instead of n (the argument of the function) is a pity. Maybe the function body can be empty. I didn't install the language. I wonder how that scales on real world cases, for example matching the internals of some complex data structure.
- curryst 7y agoPattern matching is still branching. An elegant way of expressing it, but it is branching none the less.
- imtringued 7y agoI am now wondering what the benefit of Chaos' approach is. Chaos is making some pretty substantial tradeoffs. Going with conventional pattern matching (as part of the declaration) isn't such a big leap.
- klyrs 7y ago> This looks as original and language-defining as Rust's borrow checker. I'm not so sure it's original; many compilers work on ASTs whose nodes are a sequence of non-branching operations terminated by a branch. Though people don't use these internal representations as "programing languages" but afaik they technically are.