4 ms·

From a relatively short glance, I don't see any mention of what problem this is trying to solve. Data interchange? Storage? Consumption/production? I see some

From a relatively short glance, I don't see any mention of what problem this is trying to solve. Data interchange? Storage? Consumption/production? I see some excitingly magical looking type "inference" happening though. That ruby code is sure that the value associated with Malaga is a lat/long pair is it? Not a temperature range, etc.? So, some very optimistic approach to types, no real way to validate content, and some quirky looking syntax (<key>: <value>, but also #<section>\n<key>: <value> apparently? If I have more than two levels?) I'm not sure what this is for. I am pretty sure that those people using it are going to run up against a whole thrilling raft of edge cases...

TuringTest 8y ago
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.
simonrepp 8y ago
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 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
- john-aj 8y ago
  > 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 https://lobste.rs/s/jno6gb/eno_notation_language_libraries
  - simonrepp 8y ago
    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. ;)

TuringTest 8y ago

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.

simonrepp 8y ago

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 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

john-aj 8y ago
> 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 https://lobste.rs/s/jno6gb/eno_notation_language_libraries
- simonrepp 8y ago
  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. ;)