Hot takes, as someone else says:<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/1-files-packages-imports.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/1...</a> : You might want to consider using Go syntax whenever it is not a problem. 'import "package" as foo' rather than 'import foo "package"' is just pointless change, unless there's more to the "as" statement later.<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/3-arguments.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/1...</a> : Whoa, I have to type the name of all the arguments I want to use to every function on every invocation? That's a level of noise I'm not interested in. In <a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/4-default-arguments.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/1...</a> it is claimed this is necessary to support default arguments, but see Python's function argument invocations. (And be sure you see <i>all</i> of it; for instance, it is little known that you can:<p><pre><code> >>> def f(x):
... return x * 2
...
>>> f(x = 2)
4
</code></pre>
that is, even a positional parameter can be passed by name if you insist.)<p>Coming back after reading on, I see you let Eq and Sum and such get by without argument names. Generally a language should not reserve privileges for itself that it does not grant to its users without a really good reason.<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/4-default-arguments.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/1...</a> : I literally have no idea how you are using the word "monadic" in this section; it is neither the proper mathematical term, nor the very close Haskell term, nor any subsequent misunderstanding I've ever seen of the Haskell term ported into other languages, nor can I particularly connect it to the philosophical meaning, nor do I (glancing ahead) see any other documentation for it. My search was not exhaustive, but taking such liberties with a term like that sets off a lot of flags for me.<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/5-intermediate-steps.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/1...</a> : This is, IMHO, a rather dirty hack around trying to copy the way pure Haskell code can implement definitions without much concern for order, while at the same time having side effects in the code. That "DoubleGreeting" on the bottom is getting really ugly (and I mean in terms of the semantics of what is being represented there, not the surface syntax layer), and it's still in the sample code, where things should be looking artifically fake-pretty because the real-world hasn't intruded yet. It's a solution to a problem that shouldn't have been introduced in the first place.<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/3-types-and-values/6-structures.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/3...</a> : I expect "repeated assignment" will be difficult to follow with nested structures. Also, what happens if I move yearOfBirth below the repeated "occupations"? My point here is not that there isn't an answer; it's that I can come up with 3 or 4, which is the real problem.<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/3-types-and-values/7-varieties.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/3...</a> : Variety is a bad name for this concept. It's too close to the well-defined "variant" term and causes serious concept clash in my head. "Function object" or something, maybe. "Closure" might work, haven't studied it closely enough to be sure.<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/3-types-and-values/7-varieties.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/3...</a> : This appears to mean that the "null" value is forced into all types, which makes this, surprisingly, even worse than Go itself on this front, which at least has a few types of values that can't be null.<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/3-types-and-values/9-equality-and-hashing.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/3...</a> : At scale, you can't provide a generic hashing function. It's appealing, but it really can't be done. At best you can provide an interface. Don't even provide a default implementation. Java has had a long history of problems with that.<p>General comment: Using the functions for flow control is OK, but combining that with arbitrarily-reorderable function argument parameters is crazy. Anyone who writes If(else: ..., when: ..., then: ...) is just insane anyhow, so don't even allow it in the syntax/grammar, because it <i>will</i> happen. It seems to me you basically have an imperative language trying to look functional, while I see little to nothing "functional" about it, and you'd be better off just being an imperative language and take advantage of structured programming's implicit control flow <-> source code layout correspondence. You're paying the price for some things you're not successfully taking advantage of.<p><a href="https://github.com/kocircuit/kocircuit/blob/master/lessons/5-debugging-and-logging/1-logging-with-show.md" rel="nofollow">https://github.com/kocircuit/kocircuit/blob/master/lessons/5...</a> : Re: arg0, arg1, arg2, etc., another solution to a problem that should simply have not been introduced.<p>My summation is that even in the examples, I'm seeing a lot of little quibbles stack up and become some big problems, and that's before I'm trying to actually code in this. I'd suggest some more thinking about the language's goals, and ensuring that every feature is in harmony with that goal and everything not necessary for it has been cut, because that is not where this language is right now.