Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

news.ycombinator.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

#61

Post by simonrepp »

maccio92 wrote: post #18

Why would I use a field set instead of a section? They seem functionally identical, is it meant to be a semantic decision?

Well spotted, good question!

It's also been asked in another thread on HN, I'm quoting myself here: "eno has neither indentation nor closing tags of any sort, that means if you use a section to group some values, you need to start another section to end the previous one (no closing tags!), that's why there are fieldsets, which allow short groupings that automatically end with the next field/list/fieldset."

Hope this explains it :)

Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

#62

Post by mamcx »

simonrepp wrote: post #51
fernly wrote: post #36

Earlier quoted context omitted.

This! As the introduction doc coyly says, > so as a user we usually just concern ourselves with editing the values and a friendly developer takes care of specifying the names for us. :) The friendly developer gets the job of conveying -- somehow -- that values for landline: and mobile: have to be valid tel#s (but must they have the country prefix?) while "hire date:" must be in the form yyyy mm dd only... and also ge…

Conveying what types to enter is not an eno-specific problem, as a user without schema or code access you don't know which types a blank YAML/TOML file expects either! Asides the absolutely valid meta solutions (e.g. in-file comments, clear key naming, documentation) there is an additional way this is approached in eno: If you use the type loaders provided by the API (say 'my_var = document.url('website')'), and prop…

How about type inference? You can look at rebol/red/tcl for inspiration, that already look like a config format but have a defined way to types:

https://randomgeekery.org/2004/12/26/rebol-datatypes/

http://www.re-bol.com/rebol.html

Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

#63

Post by simonrepp »

mamcx wrote: post #62
simonrepp wrote: post #51

Earlier quoted context omitted.

Conveying what types to enter is not an eno-specific problem, as a user without schema or code access you don't know which types a blank YAML/TOML file expects either! Asides the absolutely valid meta solutions (e.g. in-file comments, clear key naming, documentation) there is an additional way this is approached in eno: If you use the type loaders provided by the API (say 'my_var = document.url('website')'), and prop…

How about type inference? You can look at rebol/red/tcl for inspiration, that already look like a config format but have a defined way to types: https://randomgeekery.org/2004/12/26/rebol-datatypes/ http://www.re-bol.com/rebol.html

I appreciate the input :) but the thing is that the typing concept in eno as it is now is essentially what makes eno eno. Every application that uses eno decides for itself what types it supports and requires, and that in turn is how eno manages to be so simple and usable on the language level, even for completely non-technical people who normally feel uncomfortable with the idea of editing their content as raw text files.

If I would add types and type inference again, then I would essentially arrive at YAML and TOML again, and I don't want to reinvent them. ;)

But if I actually misunderstood you there, please let me know and do clarify!

Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

#64

Post by danso »

CJefferson wrote: post #49
shakna wrote: post #45

Earlier quoted context omitted.

Python 2 is EOL in just over a year. Why would anyone write for a piece of software that will be completely unsupported in 18 months?

Because, it is installed on Macs, as I said. I don't want to have to teach people how to install python 3, when they already have python 2, which is fine. Also, redhat had promised support for a while yet, and I expect spoke to keep it working until they replace with Python 3 (or remove python altogether?)

Who are you teaching to use Python and a bleeding-edge library like the OP's? You're not teaching them how to install Python virtualenvs, or how to install homebrew?

Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

#65

Post by mamcx »

simonrepp wrote: post #63
mamcx wrote: post #62

Earlier quoted context omitted.

How about type inference? You can look at rebol/red/tcl for inspiration, that already look like a config format but have a defined way to types: https://randomgeekery.org/2004/12/26/rebol-datatypes/ http://www.re-bol.com/rebol.html

I appreciate the input :) but the thing is that the typing concept in eno as it is now is essentially what makes eno eno. Every application that uses eno decides for itself what types it supports and requires, and that in turn is how eno manages to be so simple and usable on the language level, even for completely non-technical people who normally feel uncomfortable with the idea of editing their content as raw text…

I get that, but I wonder how give a base set of types, that avoid small incoherences.

JSOn is a good example:

https://www.tutorialspoint.com/json/json_data_types.htm

Is so spartan that everyone need to encode dates somehow, to make a simple example. I think this are the base types (also, my experience with RDBMs and building a relational lang now, and always having troubles with cvs, json, and others formats in ETL kind-of-task):

- String

- Floats. Can be split Ints/Floats but stick to just Float is ok. However, make it Float64.

- Date(Time). And be ISO. Not ambiguity.

- Boolean

- Decimal64. This is a pet peeve of mine. A lot of data in the business space is about money, and floats are not ok. What if like in rebool $3.2 is decimal?

Then the composites.

ie: This is json + dates/decimal. And make a single encoding (utf8?).

Is insane that, for example, you save a CVS in excel and open it again and excel get lost, and can't parse it fine.

Apart from this, url, email, host, website, phone, cellphone, city, country, state are so common that maybe with a import like "!schema:common-fields" or something.

Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

#66

Post by simonrepp »

TheAceOfHearts wrote: post #23

It seems bizarre that you wouldn't create a C version of this library. If you create a C version, everyone can write bindings and consume it from their favorite language. I think maybe you can do that with Rust code, but it's typical to write the canonical version in C. Your benchmarks are flawed, as they only compare between different implementations using the same language. If you really care about performance, it…

That road (C or Rust parsing core through bindings) will likely be taken, but for the initial development and jump-starting the ecosystem it was important for me to start with implementations that can be quickly experimented with and iterated and not spend a lot of extra time on dealing with segfaults, memory leaks, the different binding mechanisms on different platforms, etc. As things stand now, people are provided with multiple, fully functioning, pure implementations that already are faster than the majority of YAML/TOML parsers. In the coming months and years there will be plenty of time to make things even faster. :)

For me caring about performance also means caring about performance on all platforms, why not after all? You can take the tabular benchmark data I provide and paste it together, or use the raw data that is also available as eno files in the repository to compare language against language too (which I initially also did but later dropped because same-language comparison for libraries made more sense to me), if you want the quick run down as far as I remember it: mostly javascript parsers lead the ranking, ruby parsers are a bit behind and just slightly ahead of Python.

Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative

#68

Post by someguydave »

danso wrote: post #40
someguydave wrote: post #29

no python 2 support means no python support

Python 2's end of life is in 1 year, 4 months. https://pythonclock.org/

This is a meaningless deadline, given that nobody is actually paid to support Python. Third party vendors will support it for years to come.
Post reply on HN