71–80 of 87 posts
On another note, the docs are not so good. They're really missing a few real life examples with unit tests.
Earlier quoted context omitted.
I have never worked with Haskell but admire it from afar, and I'm honestly astonished that the REPL works this way. I would assume this would error at the compiler for a normal program, and that the REPL runtime would enforce the same constraints.
You're just shadowing the previous binding with a new one, not actually mutating anything[1]: λ> let foo = 1 λ> let foo = 2 λ> foo => 2 could be rewritten[2] as λ> let foo = 1 in ( let foo = 2 in foo ) => 2 which makes the semantics more clear. This idiom is also quite common in Clojure, another famously immutable-first language: (let [foo 1 foo 2] foo) ;; => 2 In my opinion (predominantly informed by my experience w…
From my experience any sufficiently badly written code is hard to understand even in the local scope. The bar for hard to understand code isn't that high because the complexity of well written code is very close to zero.
Most code that avoids reassignment can be read from top to bottom. Code with local mutation can require backtracking and then the complexity can start exploding but that doesn't necessarily apply to code with mutation across functions. A simple list.add() doesn't cause anyone's brain to melt.
A classic is that someone writes a for loop like this: for(;i All that meaningless complexity has no reason to exist. It doesn't provide any value and it doesn't cost anything to avoid it.
Earlier quoted context omitted.
I'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.
I 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 c…
Earlier quoted context omitted.
No, it only means that you can reassign the name `a` to a different value (i.e. it is a variable, not a constant). It would be mutable if it allowed something like this: > a = 5 > a.add(1) > print a 6 Note that numbers are immutable in most languages anyway. Arrays, hashmaps, and sometimes strings are the data types that are frequently mutable.
Numbers are literally never immutable in any language that isn't designed intentionally for comedy. Variables of a number type may be mutable, but the numbers themselves never mutate. Strings are typically immutable in most languages, but that does vary some (generally surprising people who expect primitives to be immutable).
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, an…
(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.
Earlier quoted context omitted.
Numbers are literally never immutable in any language that isn't designed intentionally for comedy. Variables of a number type may be mutable, but the numbers themselves never mutate. Strings are typically immutable in most languages, but that does vary some (generally surprising people who expect primitives to be immutable).
For a moment I started imagining what a mutable number would be like: > 3 = 5 > print 3 5 The end
Earlier quoted context omitted.
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
Ah, I did not dive that deep. Now I am curious what the impact of deep copies on performance is, and if the language employs any clever optimizations to improve performance.
https://www.amazon.com/Purely-Functional-Structures-Chris-Ok...
This is just moving the control flow to the end of the function right? Switch-case statements also have cyclomatic complexity, right?
Maybe some unix pros here can tell me, why the occultist package manager not installed via sudo, but the language itself is? It seems like an unnecessary security risk to run sudo on a random download.
But all the aliases need to go. What's the point of having three aliases for an import statement other than to confuse new programmers. It seems like one of those ideas that seems good on paper, to include words from first languages, but in the end it'll just end up confusing everybody.