Comment by sgrove | Hacker News Reader

Comment by sgrove | Hacker News Reader

Parent Full thread

How much work is it to add a new language if you have to get it into your own format? We use some esoteric languages (Clojure and Reason/OCaml) so I don't expect Optic to support our use case any time soon, but I'd be curious for e.g. Python/Ruby.

Also, a couple of other question that come to mind:

1. Jared Forsyth gave a great talk on avoiding breaking changes as a library author by using code-mods - would Optic be able to wrap up some of the changes it makes to my library code as a code-mod that I could ship with a new version of my code to auto-upgrade all my dependents? That could significantly help with some of the higher-churn libraries (some people are iffy about this though).

2. Have you considered using something closer to lsp for the editor protocol? Emacs support would be nice, and that'd be a good way to jumpstart the implementation.

3. It actually doesn't look too bad to implement the plugin for e.g. even without lsp (https://useoptic.com/docs/authoring/adding-optic-support-for...). Looking at the 'search' event though, why use `///` instead of picking up `cmd-f` (or `C-s` in emacs)? I was a bit confused about the interaction model.

Optic looks pretty interesting, best of luck!

All you have to do is pick an existing parser that works well and map the output AST to Optic's AST. I'm exploring building an Antlr extension so any grammar in their library could output in Optic's AST but that's still not implemented. Every AST have a notion of type, range, and properties which can either be primitives, arrays of child nodes, or individual child nodes. We have Python and Ruby on our roadmap for the next couple of weeks.

1. We've been exploring migrating one Optic skill to a newer version. So far it seems promising for the cases you'd expect a code-mod to help with, but if you completely change the API and deprecate some stuff it can point out the changes but won't be able to help you -- no magic here.

2. I looked into language servers (lsp) but the implementation was a lot more involved and I found bugs in some of the IDEs that claim to have full lsp support. As the protocol matures and we add more functionality to Optic I expect to see lsp become our main avenue for IDE/Optic interactions.

3. We wanted to make it really natural to ask Optic a question. We thought '///' would be unique and easy to remember, but we're open to changing it. It's nice that '///' also evaluates as a comment too because before we used it sometimes characters in your search would cause the AST parse to fail. We're open to any ideas here -- a lot of users have said it's funky.

Reply on news.ycombinator.com