5 ms·

After reading https://github.com/nudgepad/space/issues/54#issuecomment-21297690 https://github.com/nudgepad/space/issues/54#issuecomment-212... , I don't see ho

After reading https://github.com/nudgepad/space/issues/54#issuecomment-21297690 https://github.com/nudgepad/space/issues/54#issuecomment-212... , I don't see how your method is superior to the existing BIND zonefile syntax. It requires one to keep significantly more state in one's head while editing the file and (because the meaning of the data in the file depends on where it is in the file) makes drive-by one-off editing much harder. (Being able to "echo '@ 60 IN A 1.1.1.1' >> my.zonefile.zone" is pretty convenient.)

breck 13y ago
Thanks for the comment. I'm sure there's a much better DSL than the one I proposed, perhaps that takes into account the ability to append to the file. My theorem though, is that there exists a Space DSL that is 10--100x better than the current BIND syntax. In other words, you can accomplish everything that BIND does, using a syntax that is general/universal. The latter part is what gives you the 10x-100x improvement over BIND. Learning BIND provides you almost no benefit in other domains, and worse, mastering other languages is irrelevant when you encounter BIND. Why am I so confident in this? We've been applying Space in all sorts of domains, and time and again it comes up that it works in any domain, better than the existing specific languages. The benefit if you know how to use Space--and knowing Space takes less than 20 minutes to master it for a programmer since there are 3 rules, 2 syntax characters (space and newline), and it is impossible to have a syntax error--you then can easily read and write code that works across all sorts of domains--HTML, CSS, Makefiles, BIND, HTTP---et cetera. I'm a seasoned programmer (15,000 hours experience), and looking at BIND makes me groan. Now, the DSL I whipped up I'm sure is not the DSL that could replace BIND--I took less than 7 minutes to come up with that one and my knowledge of BIND/DNS is only partially--but I'm highly confident that it is relatively close and with a few tweaks you could create a DSL that is better than the status quo. Which is pretty amazing because this is so level that your work would improve the Internet and DNS in a significant way.
- simoncion 13y ago
  Frankly, I don't understand what's so complicated about HOST TTL [CLASS] TYPE RDATA Even the SOA record's RDATA is pretty simple: AUTHORITATIVE_NAMESERVER ADMIN_EMAIL_ADDR (SERIAL_NUMBER REFRESH_INTERVAL UPDATE_RETRY_INTERVAL EXPIRE_INTERVAL NXDOMAIN_CACHE_INTERVAL)
- breck 13y ago
  Great comment, simoncion. Let's define a simple empirical test to compare "X" to "Y" in terms of complexity: How long would it take for a person to write code that reads and writes code in format "X"? How long would it take for a person to write code that reads and writes code in format "Y"? Let's call the current status quo of Bind/Zone "X". My prediction, is there exists a Space based DSL that is functionally equivalent to X, let's call it "Y", that measures an order of magnitude better than X in terms of the complexity measure I defined above. And why is this important? If it were a lot easier to write code that reads and writes code that operates at one of the lowest levels of the Internet, it would unleash a wave of innovation that is hard to predict the magnitude of.
  - simoncion 13y ago
    I'm certainly not one to dismiss someone's hobby project; if it's a thing that is fun to work on, more power to you. You might even get a really useful result out of tinkering with it! I'm having a hard time imagining anything that's simpler than this p-code parser for a simple BIND-style zone file: if syntax error is encountered, abort with error read host read ttl optionally read class read type load expected rdata format for type read rdata if record read was duplicate data, abort with error Things get slightly more complicated when you add in $KEYWORDS, but not all that much. Anyway, if you can find a format that's an order-of-magnitude easier to work with than this, my hat's off to you. (If I were the sort of person that regularly found these sorts of things, I'd own an apartment building, rather than renting space in one. ;) )
  - breck 13y ago
    Great code example simoncion! Thanks for taking the time to write up that comment. You're example does indeed show a simple reader of BIND-style zone files. But, to write that, you brought to the table an understanding of BIND that I'm sure took you a long time to develop. A good Space DSL does not require a lot of domain knowledge to pick up. In other words, while the current BIND zone format uses punctation to indicate meaning, which then requires domain knowledge to read/write (or a textbook by your side), a good Space DSL is self documenting. So, my example using things like A and CNAME and TTL would be bad. Better would be something like this: breckyunits.com ip4 123.123.123.123 ip6 ::ffff:192.0.2.128 updateEvery 3600seconds
- mindslight 13y ago
  First, what makes you think your 'Space' format has "no syntax" ? What do you think keywords and whitespace are? You've just replaced 'A' with 'ip', and presumably 'CNAME' with 'address' (which is actually much less descriptive). You've also added a keyword to specify the TTL of individual records, rather than an optional positional parameter. More importantly, semantics are always more involved than syntax. By the time you understand how DNS works (which will take one basically an afternoon of playing), the few idiosyncrasies of zone file syntax are trivial. Each line is pretty much a textual description of the records that are sent over the wire, with a little punctuation and directives to set defaults for the file. PS if you're looking to do anything programmatic, install PowerDNS instead - it can use a database for your zone info.
  - breck 13y ago
    Right, there is a syntax. No punctuation, is what I should say. Again, the DSL I gave is not optimal. It would take a few iterations. My argument is that the few idiosyncrasies of zone file syntax are not trivial. Road signs are trivial. Hundreds of millions of people can see a sign and get it right away. My argument is that DNS could be trivial, and my prediction is a Space based DSL will emerge that makes it so.
    - eropple 13y ago
      ...But why do I care? Like, why would I use this? Yes, it takes an hour or so to understand simple DNS and it can certainly take weeks or even years to really understand complex DNS...but it's not the zone file format that makes this hard, it's that DNS is hard. "More efficient" doesn't make me care because it's already efficient enough that the bottleneck in DNS is elsewhere. Being more useful, doing things I can't already do, makes me care. So why should I care?
      - breck 13y ago
        DNS creates an alias from a name to the implementation. This is really powerful for a set of reasons. One, humans think with a combinatorially larger language than numbers, so having to work with addresses like 723.123.322.123 would be painfully slow. "Apple.com" is much easier. Two, you can refactor the implementation without changing the interface. Ie, you can build a whole new Apple server, but just change the alias, and not have to teach the whole world to now go to Apple2.com. It's pretty neat. The whole thing should be pretty simple. However, it's not. If it were simple, you would see a lot of programmers interacting with DNS on a more meaningful level (than just buying domains and changing A records and CNAME records according to steps they Googled and not according to an understanding of how DNS works). Each DNS record could just be an object encoded in Space. Doing so would allow you to start innovating at a core part of the Internet, instead of on a tower of cryptic stacks. IE: record domain apple.com ip4 723.123.322.123 ip6 21:21:213:213:::213 expires 2/23/2013 createdBy Tim Cook mirrors 1 723.123.322.322 2 123.123.322.322
- vidarh 13y ago
  Sorry, to me this is absolutely nonsense. Your keywords is also syntax. That there are only two "syntax characters" is not an advantage - it forces you to make the grammar for your DSL's vastly more verbose by using keywords for all kinds of situations that could otherwise easily be expressed with syntax. As a (programming) language geek that cares deeply about syntax and writes compilers for fun, the very idea is abhorrent to me. It sounds like COBOL for the new millennium. And that you "groan" from looking at BIND zone files tells me that you don't understand the underlying data model, rather than that the zone files are complicated - they map very well to the data model, and there are very few caveats with the format. (The one big one that tends to trip people up is the full stop vs. no full stop at end of host names). Further, I think you still are confused about the importance of zone files here: If you don't like them, don't use them. Use software that gives you a nice fussy interface instead. Zone files are only still important because people still pick software that uses zones files. A new format here would change pretty much nothing: Those who run bind will not change software because of a file format change; people run Bind because it has a track record, and is well understood. People switch from Bind because they have different needs. Many of those who pick something else pick DNS servers that don't even store records in files, or in other formats, so a replacement for the zone file format is irrelevant to them.
  - breck 13y ago
    > Further, I think you still are confused about the importance of zone files here: You are right. To be honest I don't know off the top of my head how many protocols/encodings are currently used to make DNS work. I know I have an /etc/hosts file on my machine. I know there are zone files on DNS servers. In the past I've downloaded those massive files from places like Verisign et cetera that contain all the records. I know dig does some stuff. My point is all that is unnecessary. The whole thing could be made much simpler, if done in an object oriented way using Space as the encoding. Say I wanted to go to google.com. My browser could check the local domains.space file to see if there's a google.com match. If not, it could then send a space message to my ISP's (or other) DNS server: question google.com And get a response: question google.com answer 123.123.123.123 My point is you could apply this clean, simple, object oriented, punctuationless system across the entire DNS stack.

breck 13y ago

Thanks for the comment. I'm sure there's a much better DSL than the one I proposed, perhaps that takes into account the ability to append to the file. My theorem though, is that there exists a Space DSL that is 10--100x better than the current BIND syntax. In other words, you can accomplish everything that BIND does, using a syntax that is general/universal. The latter part is what gives you the 10x-100x improvement over BIND. Learning BIND provides you almost no benefit in other domains, and worse, mastering other languages is irrelevant when you encounter BIND. Why am I so confident in this? We've been applying Space in all sorts of domains, and time and again it comes up that it works in any domain, better than the existing specific languages. The benefit if you know how to use Space--and knowing Space takes less than 20 minutes to master it for a programmer since there are 3 rules, 2 syntax characters (space and newline), and it is impossible to have a syntax error--you then can easily read and write code that works across all sorts of domains--HTML, CSS, Makefiles, BIND, HTTP---et cetera. I'm a seasoned programmer (15,000 hours experience), and looking at BIND makes me groan. Now, the DSL I whipped up I'm sure is not the DSL that could replace BIND--I took less than 7 minutes to come up with that one and my knowledge of BIND/DNS is only partially--but I'm highly confident that it is relatively close and with a few tweaks you could create a DSL that is better than the status quo. Which is pretty amazing because this is so level that your work would improve the Internet and DNS in a significant way.

simoncion 13y ago
Frankly, I don't understand what's so complicated about HOST TTL [CLASS] TYPE RDATA Even the SOA record's RDATA is pretty simple: AUTHORITATIVE_NAMESERVER ADMIN_EMAIL_ADDR (SERIAL_NUMBER REFRESH_INTERVAL UPDATE_RETRY_INTERVAL EXPIRE_INTERVAL NXDOMAIN_CACHE_INTERVAL)
breck 13y ago
Great comment, simoncion. Let's define a simple empirical test to compare "X" to "Y" in terms of complexity: How long would it take for a person to write code that reads and writes code in format "X"? How long would it take for a person to write code that reads and writes code in format "Y"? Let's call the current status quo of Bind/Zone "X". My prediction, is there exists a Space based DSL that is functionally equivalent to X, let's call it "Y", that measures an order of magnitude better than X in terms of the complexity measure I defined above. And why is this important? If it were a lot easier to write code that reads and writes code that operates at one of the lowest levels of the Internet, it would unleash a wave of innovation that is hard to predict the magnitude of.
- simoncion 13y ago
  I'm certainly not one to dismiss someone's hobby project; if it's a thing that is fun to work on, more power to you. You might even get a really useful result out of tinkering with it! I'm having a hard time imagining anything that's simpler than this p-code parser for a simple BIND-style zone file: if syntax error is encountered, abort with error read host read ttl optionally read class read type load expected rdata format for type read rdata if record read was duplicate data, abort with error Things get slightly more complicated when you add in $KEYWORDS, but not all that much. Anyway, if you can find a format that's an order-of-magnitude easier to work with than this, my hat's off to you. (If I were the sort of person that regularly found these sorts of things, I'd own an apartment building, rather than renting space in one. ;) )
- breck 13y ago
  Great code example simoncion! Thanks for taking the time to write up that comment. You're example does indeed show a simple reader of BIND-style zone files. But, to write that, you brought to the table an understanding of BIND that I'm sure took you a long time to develop. A good Space DSL does not require a lot of domain knowledge to pick up. In other words, while the current BIND zone format uses punctation to indicate meaning, which then requires domain knowledge to read/write (or a textbook by your side), a good Space DSL is self documenting. So, my example using things like A and CNAME and TTL would be bad. Better would be something like this: breckyunits.com ip4 123.123.123.123 ip6 ::ffff:192.0.2.128 updateEvery 3600seconds
mindslight 13y ago
First, what makes you think your 'Space' format has "no syntax" ? What do you think keywords and whitespace are? You've just replaced 'A' with 'ip', and presumably 'CNAME' with 'address' (which is actually much less descriptive). You've also added a keyword to specify the TTL of individual records, rather than an optional positional parameter. More importantly, semantics are always more involved than syntax. By the time you understand how DNS works (which will take one basically an afternoon of playing), the few idiosyncrasies of zone file syntax are trivial. Each line is pretty much a textual description of the records that are sent over the wire, with a little punctuation and directives to set defaults for the file. PS if you're looking to do anything programmatic, install PowerDNS instead - it can use a database for your zone info.
- breck 13y ago
  Right, there is a syntax. No punctuation, is what I should say. Again, the DSL I gave is not optimal. It would take a few iterations. My argument is that the few idiosyncrasies of zone file syntax are not trivial. Road signs are trivial. Hundreds of millions of people can see a sign and get it right away. My argument is that DNS could be trivial, and my prediction is a Space based DSL will emerge that makes it so.
  - eropple 13y ago
    ...But why do I care? Like, why would I use this? Yes, it takes an hour or so to understand simple DNS and it can certainly take weeks or even years to really understand complex DNS...but it's not the zone file format that makes this hard, it's that DNS is hard. "More efficient" doesn't make me care because it's already efficient enough that the bottleneck in DNS is elsewhere. Being more useful, doing things I can't already do, makes me care. So why should I care?
    - breck 13y ago
      DNS creates an alias from a name to the implementation. This is really powerful for a set of reasons. One, humans think with a combinatorially larger language than numbers, so having to work with addresses like 723.123.322.123 would be painfully slow. "Apple.com" is much easier. Two, you can refactor the implementation without changing the interface. Ie, you can build a whole new Apple server, but just change the alias, and not have to teach the whole world to now go to Apple2.com. It's pretty neat. The whole thing should be pretty simple. However, it's not. If it were simple, you would see a lot of programmers interacting with DNS on a more meaningful level (than just buying domains and changing A records and CNAME records according to steps they Googled and not according to an understanding of how DNS works). Each DNS record could just be an object encoded in Space. Doing so would allow you to start innovating at a core part of the Internet, instead of on a tower of cryptic stacks. IE: record domain apple.com ip4 723.123.322.123 ip6 21:21:213:213:::213 expires 2/23/2013 createdBy Tim Cook mirrors 1 723.123.322.322 2 123.123.322.322
vidarh 13y ago
Sorry, to me this is absolutely nonsense. Your keywords is also syntax. That there are only two "syntax characters" is not an advantage - it forces you to make the grammar for your DSL's vastly more verbose by using keywords for all kinds of situations that could otherwise easily be expressed with syntax. As a (programming) language geek that cares deeply about syntax and writes compilers for fun, the very idea is abhorrent to me. It sounds like COBOL for the new millennium. And that you "groan" from looking at BIND zone files tells me that you don't understand the underlying data model, rather than that the zone files are complicated - they map very well to the data model, and there are very few caveats with the format. (The one big one that tends to trip people up is the full stop vs. no full stop at end of host names). Further, I think you still are confused about the importance of zone files here: If you don't like them, don't use them. Use software that gives you a nice fussy interface instead. Zone files are only still important because people still pick software that uses zones files. A new format here would change pretty much nothing: Those who run bind will not change software because of a file format change; people run Bind because it has a track record, and is well understood. People switch from Bind because they have different needs. Many of those who pick something else pick DNS servers that don't even store records in files, or in other formats, so a replacement for the zone file format is irrelevant to them.
- breck 13y ago
  > Further, I think you still are confused about the importance of zone files here: You are right. To be honest I don't know off the top of my head how many protocols/encodings are currently used to make DNS work. I know I have an /etc/hosts file on my machine. I know there are zone files on DNS servers. In the past I've downloaded those massive files from places like Verisign et cetera that contain all the records. I know dig does some stuff. My point is all that is unnecessary. The whole thing could be made much simpler, if done in an object oriented way using Space as the encoding. Say I wanted to go to google.com. My browser could check the local domains.space file to see if there's a google.com match. If not, it could then send a space message to my ISP's (or other) DNS server: question google.com And get a response: question google.com answer 123.123.123.123 My point is you could apply this clean, simple, object oriented, punctuationless system across the entire DNS stack.