HN user

aaron_kent

20 karma

founder at isomorf.io

contact: info@isomorf.com

Posts4
Comments25
View on HN

Those sorts of general syntactic sugars are something we've put a lot of work into. (Currently if statements, for loops, for comprehensions, ternary operations, etc are all just sugar and don't affect the underlying source.) We also plan to expose the underlying format on the platform and let users write their own transforms. So people can invent and share their own intuitive or concise representations and have them applied everywhere immediately (and also shared with other users).

Thanks!

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!

Thanks! Learning is certainly an application we've considered. We have found significant interest in structured editing paradigms from those newer to coding and those who find the code-as-text paradigm frustrating/limiting. But we certainly aren't setting out to change the minds of people proficient and happy with text editing.

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

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?

“What next?” 9 years ago

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 (feedback@isomorf.com)! 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.