Ive been using cobbled together bash aliases for most all the sage commands for years. Good to see someone actually making a better API

> The closest equivalent would be a stupid function that calls a very long running sleep

I disagree. The equivalent would be a thread that's never joined, like a thread with an infinite loop

_

    function blockingSleep(amt) {
        let start = new Date().getTime()
        while (start + amt > new Date().getTime()) {}

    }

This is horrible - I love it.

I did forget you could do this, though I'm fairly sure in the case of a browser (at least it used to) this will block the entire UI.

Thank you for writing that complaint out so I don't have to. It solves nothing.

> the study examined eight males and six females

Last sentence I read of that article

Thanks for acknowledging you didn't read it, I guess? Why comment?

Sounds like a speedrun for angry feedback. Maybe find threads discussing problems with ROS, then post in those threads

I'm always looking for a ROS replacement.

The limitations section at the bottom of the readme is excellent. Good level of detail and self-awareness. More projects need that.

Sadly, while theres a lot of stuff I like, ultimately I don't think this is the ROS replacement the world needs. Specifically because of step 1: clone the repo (or add as submodule).

Its a terrible move, IMO, to not have the pub/sub system be a binary executable or shared object file. ROS's fatal flaw (among many flaws IMO) is requiring every library-user to be able to build from source. I'm glad it doesnt dictate a folder structure, but I'm really sad to see this project continue the trend of needing to build from source.

We will eventually have a binary distribution. I chose not to for this release because it's not the workflow I want to encourage, and due to the management overhead of having to create packages for every combination of hardware/OS we'd like to support with a team of two (also, I need to learn the proper way to install headers with CMake...). I don't want to lock users to my OS of choice, I want to ensure it's easy to do things like turn on "-march=native" for the whole codebase, and I want it to be easy to fork and patch/customize.

I don't get your comment about ROS - in my experience with ROS, most users don't build the distribution from source, they use apt or similar, up until they need to fork it to fix some bug or another (and then cry because you have to muck with apt's repository version syntax to use _your_ version of the package and not upstream). Regardless, I think it is important that users are able to build from source if needed - see above. Why would you like to restrict that?

To not be all negative though; I love the work on making it deterministic, and having first class docker support. ROS is such a crap-shoot when it comes to reproducibility. I mean bag files are great and all, but when its demo time on stage something always behaves inconsistently.

I'm actually not a fan of the "bring your own serializer" design. I think just use one serializer thats fast (like protobuf) and then let other serializers be built on top of that (e.g. JSON). I could be wrong, but thats my hunch of a good system.

I'd like to very much encourage protobuf as the serializer, but supporting others both gives users the freedom to pick their own tradeoffs, and makes it 10x easier to transition from ROS or another framework. We do support JSON output from the serializer layer - I'd rather not do other conversions if possible.

Do you think you'll ever break out the doc-editor into a standalone web component? Ex: Imagine if VS Code reworked its settings.json and used this as a UI instead. Is that within the scope of the project, or is this supposed to only be a monolith app?

By standalone web component do you mean like a React component that you can embed in your own app ? Or something more "bundled" like a VS Code extension ?

In terms of scope, you are thinking of both the "Editor" and the "Schema builder" ?

My initial intention was more to build a monolith app, like a simple version of MS Office for jsons. There are already some strong links between the notions of workspace and document: for example the Link field captures an id of another document or record that you have in your workspace, same for File and Image fields... (I guess a next step in the future would be to incorporate the notions of users & groups...). That could probably be abstracted by having something more plugin-based where you provide to the component your description for "what is another document" or "what is a file".

But I think I got your point as well that, if it is deemed to be a framework, it would be useful to let other platforms or verticalized apps use the same representation !

I've felt your exact pain: I can only give normal people spreadsheets, because they don't know how to interact with any other data structure. It's a serious problem.

I'm super impressed. I love the names (text not string) and extra fields (like the multiple choice and tensor). But I'm a bit concerned about the complexity. Don't answer these, I figured it out, but this is how it felt: how do I make an array (numbered list) vs a named list (object)? I didn't realize the intro document itself was, well, a document. I was thinking it was a typical website with a sidebar. Script, whiteboard, simulator (??) I though json was just a hierarchy. Schema, Interface, raw data, json. Its a lot of jargon. Is a document a type of json object? Is there a fundamental difference between whiteboard file and a document file? Is a whiteboard a type of document? Can a document be a field in a document? When editing an item, do I need to fill out the interface, methods, snapshot, etc. Where is the save/submit button? (I known their isn't one, but I kinda expect a "I'm adding a new field, okay I'm done adding it and want to go back to a table-of–contents view") I think the UI needs to answer these because it feels overwhelming). You probably even explain it in text somewhere, but let's be real; IRL people aren't going to read the docs.

Good news is, I think its easy fixes; hide the templates the first time someone is making something (only let them make a doc). Hide the methods, snapshots, etc too. Wait till they've done some stuff. Change the "x" button to "save" even though its not really saving.

The windowing system is really impressive, and I've always loved the detached tables of MacOS's spreadsheets. But at the moment I think it adds to the overwhelming feeling.

Don't let my criticisms weigh you down though! I would've been happy if this had 1/10th of the features.

Many thanks for your feedback, very useful !

Yes you are right, the complexity at first sight is a problem. The onboarding journey should be clearer, and indeed there is too much jargon to digest before you can really start. That's also probably because it's more the basis of a framework than a concrete product to use as is (hence the rather detailed but probably too long documentation). All the fixes you mentioned would clearly improve this first impression. Thanks !

As the basis for framework I think its amazing. It has everything I would've ever wanted and more.

Even though I critiqued the UX, the UI itself is incredibly polished. Which is a a pretty big deal for a framework. Its also pretty rare for me to see that in hackernews UI demos.

In terms of being/not-being a product; really, the most exciting part (for me) would be having (just) the doc-editor as a web component. I'll ask in a separate reply about that since others might want to know.

OK, thanks for your words !

While, as an academic, I actually don't see glaring flaws in the paper. (For context, the author previously wrote about videogames not increasing violence. "Not correlated" might be his general approach)

As a normal human though; when overwhelming daily evidence disagrees with scientific findings, usually its a flaw or VERY deep misunderstanding of the science.