31–40 of 87 posts
Seems like we have a fellow Chaos Magick practitioner right here. Funny that the creator named the language "Chaos", the module manager "Occultist" and the modules "Spells". Now I can't dislike it even if I found some of the language features quite alien.
You might even say they are arcane.
Seems like we have a fellow Chaos Magick practitioner right here. Funny that the creator named the language "Chaos", the module manager "Occultist" and the modules "Spells". Now I can't dislike it even if I found some of the language features quite alien.
> I found some of the language features quite alien. You might even say they are arcane.
From 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. ... > At first glance, defining the control structures in this way might seem so unnecessary or inconvenient but this is the pinnacle of writing 100% testable, clean and error-free code in any programming langauge by far.…
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 > 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…
Yes, 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 a…
Cyclomatic complexity is a whole-program property. Your functions are just nodes in the control flow graph, where the real complexity appears. One-branch functions are definitely a good hack, though. :)
From 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. ... > At first glance, defining the control structures in this way might seem so unnecessary or inconvenient but this is the pinnacle of writing 100% testable, clean and error-free code in any programming langauge by far.…
Of course, there are some qualifications one should make regarding such a claim: you have to trust that your specification is "correct", that your hardware is functioning correctly, that the proof checker didn't accept a bogus proof, that the underlying logic (e.g., the calculus of inductive constructions) is consistent, etc. That's a lot of things to trust, but the point is that you don't have to trust yourself.
Earlier quoted context omitted.
The getting started guide demonstrates that arrays are mutable. https://chaos-lang.org/docs/05_arrays
Yet it says [1]: > Arrays and the elements of arrays are also immutable I guess the docs need a bit of rewording. Forcing a deep-copy on variable assignment does not mean the variable itself is immutable. [1] https://chaos-lang.org/docs/07_immutability
> Every variable in Chaos language is immutable by default. --- > kaos> num a = 5 > kaos> a = 7 > kaos> print a > 7 Doesn't that mean a is mutable by default?
Maybe the REPL behaves different than the interpreter? Haskell REPLs tend to work the same way. GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help Prelude> a = 5 Prelude> a = 7 Prelude> print a 7 But yeah, it doesn't seem like there's any support for first class functions either, so perhaps just a bit too much creative license in marketing?
int a = 5;
a = 7;From 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. ... > At first glance, defining the control structures in this way might seem so unnecessary or inconvenient but this is the pinnacle of writing 100% testable, clean and error-free code in any programming langauge by far.…
I agree with the other commenter about the comma in this sentence. But I'd also like to point out that 100% error-free code is possible. There's a whole branch of computer science dedicated to it: formal verification. I personally have used Coq to write certified code in the past, and I'm quite confident that my code was 100% error-free. Of course, there are some qualifications one should make regarding such a claim:…
So, it is not really fair to downplay the chance that you could have a wrong specification, although it would be equally wrong to use that as an excuse to downplay the value of Coq.
Earlier quoted context omitted.
The getting started guide demonstrates that arrays are mutable. https://chaos-lang.org/docs/05_arrays
Yet it says [1]: > Arrays and the elements of arrays are also immutable I guess the docs need a bit of rewording. Forcing a deep-copy on variable assignment does not mean the variable itself is immutable. [1] https://chaos-lang.org/docs/07_immutability