3 ms·

Ultimately it’s all data. The difference between this and lisp is just a bunch of extra characters and noise in the stream. What is really the meaningful diffe

Ultimately it’s all data. The difference between this and lisp is just a bunch of extra characters and noise in the stream. What is really the meaningful difference between this and an s-expression language? “” and {}, really. It’s a different way to serialize the same thing. So I’d argue a lot of the criticism is valid. We do, as an industry, tend to run in circles.

sebmellen 5y ago
The most important difference to me is that this is usable within already extant JSON Schemas that can be patched up or added to.
pydry 5y ago
>What is really the meaningful difference between this and an s-expression language? Turing completeness. >So I’d argue a lot of the criticism is valid. I'd argue they should have paid more attention in college. This is far from a superficial difference. You might as well call HTML a programming language. Seriously.
- rvense 5y ago
  >>What is really the meaningful difference between this and an s-expression language? >Turing completeness. S-expressions in and of themselves are obviously not Turing complete. This language could easily have been encoded in S-expressions, just like Lisp can be encoded as JSON. (Like, trivially, as lists with quoted strings instead of atoms, or using whatever object-based syntax.)
  - pydry 5y ago
    Well, the most famous example most definitely is. There's thousands of ways this could have been encoded. Why that one specifically?
- remram 5y ago
  Correct me if I'm wrong, but not every s-expression language is Turing-complete, you need the ability to define functions which is not a given. This project doesn't have functions (or loops) seemingly on purpose (and their addition would make this weird language just as Turing-complete).
  - deleted 5y ago
    [deleted]
deleted 5y ago
[deleted]
forgotmypw17 5y ago
I think it's just a natural law that information tends to "crystallize" into certain patterns, and we're just the implementors of those repeating patterns. :)
athrowaway3z 5y ago
I remember years ago when i first came to hackernews there was a project very similar to this. An engineer blog proud of the AST they encoded as JSON. I had only a vague idea of what an AST was, but the highest upvoted comment was clearly saying: This is dumb, we have dedicated formats for turning text into ASTs. ( i.e. a programming language ). In the past decade+? i have learned what an AST is and have now twice, in a professional setting, prevented an engineer from re-inventing this very concept. If i had to choose if hackernews is a place where smug snark comments crack down on re-inventing known concepts or a happy place where every idea is a good one i will choose the former. And once every blue moon we get to laugh and look back at snarky comments such as this: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224
- incrudible 5y ago
  Yes, we have programming languages. Lots of them. Most are distinguished by what you can do with them. Few are distinguished by what you can not do with them. This is one of the few projects addressing the latter problem space.
- samatman 5y ago
  I don't understand this at all. JSON is a serialization format. So say you have an in-memory AST, and you want to serialize it: why not use JSON? If you don't want or need to serialize it, then of course don't use JSON. I can make up plenty of other reasons not to, but they're variations on some other format being better for the application, not JSON being inadequate in any way. I'd probably use JSON myself, and I don't care for it much. Or are we talking about building up an AST in JSON directly rather than taking some parser output and serializing it? Ok that's... not an AST then, it's a programming language with JSON compatible syntax, and yes I would try and prevent that from getting implemented as well.
brundolf 5y ago
The difference is the collection of extremely powerful parsers, tooling, language support, etc that already exist for this syntax. There's a proper Content-Type header, blazing-fast native parsing in web apps, you could store it directly in MongoDB or the like without an extra serialization/parse step, you could query it with jq. Heck, you could statically-check these expressions using TypeScript. Lispers are always pointing out how the parenthesis-and-whitespace notation is just incidental; how s-expressions are really something deeper that isn't bound to a specific syntax, and how this is a strength. The OP is a demonstration of that strength.
joshuamorton 5y ago
https://github.com/joshuamorton/tidbits/blob/master/lispy.py#L6 https://github.com/joshuamorton/tidbits/blob/master/lispy.py...

sebmellen 5y ago

The most important difference to me is that this is usable within already extant JSON Schemas that can be patched up or added to.

pydry 5y ago

>What is really the meaningful difference between this and an s-expression language? Turing completeness. >So I’d argue a lot of the criticism is valid. I'd argue they should have paid more attention in college. This is far from a superficial difference. You might as well call HTML a programming language. Seriously.

rvense 5y ago
>>What is really the meaningful difference between this and an s-expression language? >Turing completeness. S-expressions in and of themselves are obviously not Turing complete. This language could easily have been encoded in S-expressions, just like Lisp can be encoded as JSON. (Like, trivially, as lists with quoted strings instead of atoms, or using whatever object-based syntax.)
- pydry 5y ago
  Well, the most famous example most definitely is. There's thousands of ways this could have been encoded. Why that one specifically?
remram 5y ago
Correct me if I'm wrong, but not every s-expression language is Turing-complete, you need the ability to define functions which is not a given. This project doesn't have functions (or loops) seemingly on purpose (and their addition would make this weird language just as Turing-complete).
- deleted 5y ago
  [deleted]

deleted 5y ago

[deleted]

forgotmypw17 5y ago

I think it's just a natural law that information tends to "crystallize" into certain patterns, and we're just the implementors of those repeating patterns. :)

athrowaway3z 5y ago

I remember years ago when i first came to hackernews there was a project very similar to this. An engineer blog proud of the AST they encoded as JSON. I had only a vague idea of what an AST was, but the highest upvoted comment was clearly saying: This is dumb, we have dedicated formats for turning text into ASTs. ( i.e. a programming language ). In the past decade+? i have learned what an AST is and have now twice, in a professional setting, prevented an engineer from re-inventing this very concept. If i had to choose if hackernews is a place where smug snark comments crack down on re-inventing known concepts or a happy place where every idea is a good one i will choose the former. And once every blue moon we get to laugh and look back at snarky comments such as this: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224

incrudible 5y ago
Yes, we have programming languages. Lots of them. Most are distinguished by what you can do with them. Few are distinguished by what you can not do with them. This is one of the few projects addressing the latter problem space.
samatman 5y ago
I don't understand this at all. JSON is a serialization format. So say you have an in-memory AST, and you want to serialize it: why not use JSON? If you don't want or need to serialize it, then of course don't use JSON. I can make up plenty of other reasons not to, but they're variations on some other format being better for the application, not JSON being inadequate in any way. I'd probably use JSON myself, and I don't care for it much. Or are we talking about building up an AST in JSON directly rather than taking some parser output and serializing it? Ok that's... not an AST then, it's a programming language with JSON compatible syntax, and yes I would try and prevent that from getting implemented as well.

brundolf 5y ago

The difference is the collection of extremely powerful parsers, tooling, language support, etc that already exist for this syntax. There's a proper Content-Type header, blazing-fast native parsing in web apps, you could store it directly in MongoDB or the like without an extra serialization/parse step, you could query it with jq. Heck, you could statically-check these expressions using TypeScript. Lispers are always pointing out how the parenthesis-and-whitespace notation is just incidental; how s-expressions are really something deeper that isn't bound to a specific syntax, and how this is a strength. The OP is a demonstration of that strength.

joshuamorton 5y ago

https://github.com/joshuamorton/tidbits/blob/master/lispy.py#L6 https://github.com/joshuamorton/tidbits/blob/master/lispy.py...