Just a quick update on isomorf.io, we are bootstrapping the projections on the platform itself and so soon you will be able to design and implement your own. Stay tuned.
HN user
aaron_kent
founder at isomorf.io
contact: info@isomorf.com
This sort of translation is definitely part of our syntactic sugar mission. If anyone wants to beta test particular languages for us just reach out.
Sorry about that. There should be a little X on the chat window that will close it.
Interesting. Thanks for the feedback. I think you are probably right that it sounds cool and appealing as a dev, but it's likely not a great use of resources in the short term.
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!
Not yet but that is the plan!
Happy the blog post helped. One update is that we've moved to an entirely keyboard-based model for editing, so there is only minimal mouse work now. More details here if you are interested: https://blog.isomorf.io/an-experiment-in-structured-code-edi...
Our old friend spiralganglion! Good to see you here. And thanks for the tip.
There are more thorough descriptions on our blog if that is a preferred medium: https://blog.isomorf.io/
Real-world examples are in the works! Side effects and integration use-cases will be a part of our beta release. If you have specific integrations you are interested in, let us know. Thanks!
Thanks for the feedback. We will definitely have a way to hide those verbose namespaces.
Interesting, thanks! We will maybe make that an option in the future for those who prefer text vs icons.
Sorry about that! We are experiencing significantly higher load than we are used to, but working on a fix presently.
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
Yeah, we use the beaker to mean unit tests. We like the icons because they keep the layout dense, but if the meanings aren’t clear that is good feedback for us
Some detail on isomorf.io editor:
https://blog.isomorf.io/an-experiment-in-structured-code-edi...
https://blog.isomorf.io/the-economics-of-semantic-coding-7e8...
FYI, this led to the creation of https://www.reddit.com/r/nosyntax/
No worries, we were able to get accounts. It seems like an awesome community! We posted and have gotten a great response. Lots of encouragement and good feedback. There was even some talk of Intentional Programming and Charles Simonyi, which I'm sure you'll appreciate. Happy to extend you an invitation if you want one.
https://lobste.rs/s/kiva0w/structured_cloud_ide_designed_aro...
Thanks. Hadn't heard of that one. Seems like we need an invite. Would you be up for inviting us?
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 (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.