aaron_kent's comments

Thanks! We've seen your mentions, and we appreciate your enthusiasm. We clearly have similar visions for next generation development stacks.

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?

Would love to chat further about these ideas and get some feedback: aaron.kent <at> isomorf.io

Thanks!

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.

Thanks!

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)

Hello! I’m Aaron one of the co-founders of isomorƒ. Sorry our site was down when you visited. We’ve actually just pushed a new demo (https://isomorf.io/#!/demos) and we would love feedback on it ([email protected])! We are planning a public beta soon and we’re looking for participants (https://isomorf.io/#!/sign-up).

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.