LJSON
Languages and libraries
serialization format
SHOW HN2015
How HN took it
3 positive, 1 neutral or asking, 1 mixed, 6 critical, out of 11 comments about the project. Thread score -0.14.
Idea: 3 for, 2 againstExecution: 0 for, 2 againstDesign: 0 for, 2 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Interesting idea and implementation
From 3 comments
I think it's a lovely idea, with an interesting implementation. Obligatory HN style comment: It might be wise to strengthen the description from "pure" functions to "pure and…
archgrove on HNNeat concept. It reminds me of how JSON started - as just a string representation of a javascript object and parsing JSON was as simple as evaling it. Once it picked up steam, it…
statictype on HNThis is something I'd wanted to do, and I'm glad someone else had the same idea. Lots of exciting possibilities. Something important that needs doing is strictly defining the…
TazeTSchnitzel on HN
Objections
Does not guarantee termination; non-terminating functions can be encoded
From 1 comment
There is no protection against non-termination. For example, an user could give you this function: ``` f = (function (x){ return x(x); }) ``` Now, if you call…
LightMachine on HN
Exotic terms and native JS constructs can fool the stringifier
From 2 comments
Fun project. From examining the source code, they are using the technique that can be considered a kind of higher order abstract syntax (HOAS). In particular, LJSON can be fooled…
lambdapie on HNActually there are other problems that are caused by the fact that you're not really doing HOAS, but something even more difficult, namely trying to infer the function by passing…
lambdapie on HN
JavaScript is a poor base language; strict typing needed
From 1 comment
This would be interesting, except JavaScript is a terrible language for this. At the minimum I think you'd want all the arguments and return values to be strictly typed.…
IgorPartola on HN
Too restrictive to be useful beyond trivial examples
From 1 comment
Without being able to call pure functions within pure functions, what use is this beyond the trivial simple examples? Couldn't it be possible to pass a "this" argument as the…
vortico on HN
Requests
Strictly define the JavaScript subset used
From 1 comment
This is something I'd wanted to do, and I'm glad someone else had the same idea. Lots of exciting possibilities. Something important that needs doing is strictly defining the…
TazeTSchnitzel on HN
Add type hints or a type system
From 2 comments
This would be interesting, except JavaScript is a terrible language for this. At the minimum I think you'd want all the arguments and return values to be strictly typed.…
IgorPartola on HNThere is no protection against non-termination. For example, an user could give you this function: ``` f = (function (x){ return x(x); }) ``` Now, if you call…
LightMachine on HN
Strengthen description to pure and terminating
From 1 comment
I think it's a lovely idea, with an interesting implementation. Obligatory HN style comment: It might be wise to strengthen the description from "pure" functions to "pure and…
archgrove on HN
Questions
Better way to mark end of call list than null
From 1 comment
Very good catch. Any suggestion how I could improve the usage of null for determining the end of a call list?
LightMachine on HN
What stops client code from using globals
From 1 comment
I definitely see some uses to it as a way to pass client code to the server safely. What would stop the client from using global variable though?
d0m on HN