20 karma · joined October 6, 2013
contact: info@isomorf.com
In terms of applications, our initial work has been to export functions as microservices onto existing platforms (e.g., Lambda). We've also explored downloading code as either native artifacts (e.g., maven) or as command-line apps. We are also playing around with adding integrations for ReactJS to support web applications. Where we focus our deployment efforts is one of our current big questions, and one where we are most interested in community feedback.
In terms of the abstraction, you are quite right that the examples we've shown are very trivial, really just to convey the concepts. The more interesting work will probably be sharing much more complex functions, or sharing the built app/services themselves (which could be made transparent within the platform itself).
Definitely reach out if you have more thoughts or feedback!
We wrote up some thoughts on the economics of structured editing on our blog: https://blog.isomorf.io/the-economics-of-semantic-coding-7e8....
For those interested in this field, there is an emerging subreddit: r/nosyntax
https://blog.isomorf.io/an-experiment-in-structured-code-edi...
https://blog.isomorf.io/the-economics-of-semantic-coding-7e8...
https://lobste.rs/s/kiva0w/structured_cloud_ide_designed_aro...
We'd love to get your feedback and discuss in more detail! We think that even beyond the non-plaintext representation, an IDE married with storage can enable a lot of powerful analytical features and services.
Do you have any recommendations for where else we can find a good audience for this? Any other communities talking about this direction for dev tools?
While we customized syntax in the tour & sandbox to closely match familiar languages, the way code is rendered is totally configurable: the underlying ASTs are passed through a rendering layer with keywords/symbols/etc populated. So adding new syntaxes is pretty easy. We will add those to the list!
Also worth mentioning is that right now renderers are defined by us as part of the webapp, but ultimately they will be loaded as isomorƒ code, allowing users of the platform to design and share new ways to interact with code.
As far as the optimizations: we transpile the code to different target runtime languages where we can automatically instrument different optimizations. Currently our microservice runtime is Scala code and we can add a cache layer around any function application or a parallelization queue around any map-like operations on iterable types (e.g., List).
The application deployment UI let's you pick the points of optimization (a top level function for a cache, or map-like application for a parallelization). Then you can pick the tier of optimization implementation you want (e.g., local in-memory map vs remote Redis instance; local thread-based parallelization vs remote actor-based cluster parallelization)
Your descriptions of projectional editing and intentional programming very much resonate with the vision we are pursuing. We agree that structured editing can create much more efficient paradigms for refactoring, reuse, and stability. Why do we search for code based on text rather than real function signatures and even input/output examples? Why do we need to change languages just to use new control structures? Why do we accept the coarse granularity of file level commits? Why are things like parallelization/caching part of code rather than ex-post runtime configuration? Why does deployment need to involve endless command line idiosyncrasies
This is definitely a complex problem, but we feel a paradigm shift is necessary to make a step change in software development efficiency. We’d love to discuss further.