I fully expect to get down voted here, but I really hope the damage is minimal. Please be gentle since inside my link is a valid point pertinent to this post, which summarizes my thoughts concisely. :-)
The author sees other languages and frameworks as implementation details and wants developers to get rid of them and actually define solutions to problems. What he misses is, that these technologies are actually the language you use to define solutions.
He argues, that his tool uses a declarative style to define the solution. There are other solutions which do the same. (lordbusiness already provided the xkcd, so i will skip this.) In my experience, declarative is great when it works, until you grow out of it and have to fight it.
I already wanted to comment something like that on the first thread he started but hesitated. With a linkbaiting title like this I feel they finally deserved it :)
Thank you for the useful remarks. It depends on the nature of your task, doesn't it?
In most cases, a solution relating (real-life) actors, processes and objects they handle can (and will) be described in plain text. In an Enterprise environment, this may be part of the project specification. However, the actual implementation will be specified as source code. To an extent this may even apply to purely technical projects.
In a larger team, creating this specification of a project is typically part of a project manager's job. However, in a smaller team or start-up, these roles may merge and are not as clearly defined. This is especially true, if the team is focussed on both building a product and working with (potential) customers.
And of course, it's up to you to decide whether Kozo will be useful for you once it is released. ;)
I fully expect to get down voted here, but I really hope the damage is minimal. Please be gentle since inside my link is a valid point pertinent to this post, which summarizes my thoughts concisely. :-)