In the latest years I've seen a trend towards syntax-lightweight languages.

Developers are already well served with their powerful programming languages, able to express very complex concepts and relations with terse syntax. But those high-level languages have very complex grammars, and each token must be carefully placed with respect to their surrounds to make sure that it compiles and expression types are well matched.

There's an unmet need at the other side of the complexity spectrum, with languages that can't express complex concepts, but which accept simple terms expressed with extremely simple syntax and grammar; to the point that non-programmers may be able to create and edit those files. For building documents we first had BBCode and now have Markdown as the emerging standard; but things like templates and simple scripting needs require a language which can express some computations and relations.

Developers first wrote ad-hoc parsers for their configuration files, and are now well served with JSON for structured data serialization. But that format is still too complex for casual use by inexperienced users. Something like eno could work for them in a context where defining data structures and assignment to variables is needed.

What you're seeing there is actually validation :), the lat/lng type is not magically inferred but instead explicitly requested by the code - if it were not valid it would generate a user-friendly, localized error message. Also the underlying document hierarchy that holds the data is validated. So on the contrary it is actually hard not to validate content in eno.

The quirky looking syntax you mention is probably familiar to you from YAML or paper forms ("Name: Joe"), and Markdown ("# Section"), likewise if you have two levels you use "## Subsection".

There's quite a few things that eno solves (there's only so much space on a frontpage, sorry), but if you want one of the more prominent ones: It's considerably hard to win over users without technical background to switch to secure, statically generated content solutions when the most prominent format works like this: http://yaml.org/spec/1.2/spec.html I've explained eno in 5mins to a non-technical intern who is now managing content at a client of mine and in months I haven't heard a single question about how eno works! User empowerment. <3

> What you're seeing there is actually validation :), the lat/lng type is not magically inferred but instead explicitly requested by the code - if it were not valid it would generate a user-friendly, localized error message. Also the underlying document hierarchy that holds the data is validated. So on the contrary it is actually hard not to validate content in eno.

Please make this clear on the website! I think it’s a clever idea.

Also, this has garnered some attention on Lobste.rs [1], if you’re interested to read the discussion there as well.

[1]: https://lobste.rs/s/jno6gb/eno_notation_language_libraries

Thanks for that feedback! I'll see what I can do to communicate the API type concept better, I'm generally struggling to pack all the bandwidth of things into the little available prominent space on the website, but eventually I will get it right for most people I hope. :)

Also thanks for letting me know about the lobste.rs thread, I'll see that I get invited and answer the few not yet-answered points, couldn't get to it yesterday unfortunately amidst all the comment and issue and PR flood here and on github. ;)