An experimental software development environment(isomorf.io)
isomorf.io
An experimental software development environment
https://isomorf.io/
66 comments
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!
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!
The landing page leaves everything to be desired if you have no idea what this is about in the first place.
I really like the idea of sharing snippets of code. I'm so tired of implementing common functions, especially the ones that are tricky to get right.
I find this exciting and fascinating in all kinds of ways. There's a huge amount of potential here, and the kinds of IDE improvements I've wanted for years.
Unfortunately, I also found the UI so difficult that I gave up. When I got to the Sandbox (note: clicking the different tour stage links to jump ahead doesn't seem to work) I tried editing the "doubleMe" function, and deleted the expression "x * 2". Then I spent five minutes just trying to re-enter that expression in a way that Isomorf would like, but to no avail.
I understand the desire to establish unambiguous semantics at coding time, but it feels like you're forcing the user to do extra work for it. Perhaps if/when I get used to the editor, it'll save me time in the long run. Right now it feels like I'm hamstrung.
All that said, the overall concept still looks fascinating, and I hope it succeeds. Good luck!
Unfortunately, I also found the UI so difficult that I gave up. When I got to the Sandbox (note: clicking the different tour stage links to jump ahead doesn't seem to work) I tried editing the "doubleMe" function, and deleted the expression "x * 2". Then I spent five minutes just trying to re-enter that expression in a way that Isomorf would like, but to no avail.
I understand the desire to establish unambiguous semantics at coding time, but it feels like you're forcing the user to do extra work for it. Perhaps if/when I get used to the editor, it'll save me time in the long run. Right now it feels like I'm hamstrung.
All that said, the overall concept still looks fascinating, and I hope it succeeds. Good luck!
I can definitely sympathize with your viscereal frustration with getting a trivia expression entered, especially for an already proficient coder. This tradeoff is actually part of the subject of the most recent blog post [1]. Any kind of tool that presents a non-text-based experience (be that VIM, Photoshop, or whatever) does unfortunately require a little time studying the commands and building some muscle memory.
You might also check out the post on general editing [2].
Thanks for the feedback!
[1] https://medium.com/p/the-economics-of-semantic-coding-7e8fd1... [2] https://medium.com/p/an-experiment-in-structured-code-editin...
You might also check out the post on general editing [2].
Thanks for the feedback!
[1] https://medium.com/p/the-economics-of-semantic-coding-7e8fd1... [2] https://medium.com/p/an-experiment-in-structured-code-editin...
Is it implemented in itself? :-)
I would not recommend this objective (at least not for a few years). The reason I actually think it is important to comment on this is that I've seen the pattern a lot where IDE or language devs strive too early to build their own product in their product. While in theory this is useful, in practice I think it's better to wait 5 to 10 years before doing that. Otherwise it's too much of a hard problem and leads to many premature optimizations and resource allocation while taking the focus off of solving other people's problems.
This tool seems to me like it would be fantastic for building and managing strongly typed, 100% code coverage, reliable bug-free microservices. Lots of other tools help you build microservices, but they help you build BUGGY microservices. I think solving the problem of building reliable microservices could be huge.
But this product itself is not a microservice, instead it's an advanced IDE and backend with a lot of different components. So while it would be cool to use isomorf to build parts of isomorf, I'd vote you delay going for this goal for a long while.
This tool seems to me like it would be fantastic for building and managing strongly typed, 100% code coverage, reliable bug-free microservices. Lots of other tools help you build microservices, but they help you build BUGGY microservices. I think solving the problem of building reliable microservices could be huge.
But this product itself is not a microservice, instead it's an advanced IDE and backend with a lot of different components. So while it would be cool to use isomorf to build parts of isomorf, I'd vote you delay going for this goal for a long while.
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.
Or maybe another way to put it: lots of successful languages and IDEs are implemented in themselves, but lots of unsuccessful ones are too. I think I've seen some folks believe achieving that beautiful recursive milestone will be a silver bullet, but rarely (if ever) does it turn out that way. It's a nice thing to have and a great way to dogfood your product but not necessarily that important.
Not yet but that is the plan!
Usability failure:
https://imgur.com/a/FgB1r
I can't click on next in the tour without triggering the chat feature.
https://imgur.com/a/FgB1r
I can't click on next in the tour without triggering the chat feature.
Sorry about that. There should be a little X on the chat window that will close it.
I like the very detailed demo.
But please god, the UI is in iconese with many missing tooltips. I hate this trend in UIs. I have no idea what the buttons do, and I am scared to touch them. (and it's a webapp, so it will change in 6 months).
What does a half full beaker have to do with software development?
But please god, the UI is in iconese with many missing tooltips. I hate this trend in UIs. I have no idea what the buttons do, and I am scared to touch them. (and it's a webapp, so it will change in 6 months).
What does a half full beaker have to do with software development?
A half full beaker is usually for unit tests, right?
Usually for whom? I would have assumed it meant "experiment" or possibly "solution".
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
> but if the meanings aren’t clear that is good feedback for us
You should provide tooltips regardless of whether the meanings are generally clear.
You should provide tooltips regardless of whether the meanings are generally clear.
Yes, more tooltips would be useful, and perhaps shorten the hover time for them to appear. Thanks.
Props for accepting feedback!
A decent number of people's brains just don't assign meaning to images. I'm one of them. As an example, I've been using an iPhone for several years. I still routinely click on the Notes icon instead of the Reminders icon, as well as, the Maps icon instead of the Weather icon whenever I'm rushing and don't take time to read and say the app name in my head.
I'm not sure if it's tied into being an auditory learner, but I know I'm not alone.
A decent number of people's brains just don't assign meaning to images. I'm one of them. As an example, I've been using an iPhone for several years. I still routinely click on the Notes icon instead of the Reminders icon, as well as, the Maps icon instead of the Weather icon whenever I'm rushing and don't take time to read and say the app name in my head.
I'm not sure if it's tied into being an auditory learner, but I know I'm not alone.
Interesting, thanks! We will maybe make that an option in the future for those who prefer text vs icons.
Adding tooltips to all icons would go a long way.
Our old friend spiralganglion! Good to see you here. And thanks for the tip.
Thanks for the pun :)
I noticed an "error" in your icons. The icon for "dependencies" of a function is a left->right spreading tree, but should be a right->left condensing tree to suggest to left->right language speakers that the dependencies are coming together rather than going apart. Similarly, the responsibilities icon should be switched to be a left->right spreading tree to show that the function is going out and being used in many different places.
I would have never guessed
Beautifully done, but ergonomically "no way to code" for me.
Could be pretty neat if you focus on learners. Once mildly proficient, one'll want the speed and flow of typing and freely operating on lines/blocks/selections in an unconstrained text file.
Could be pretty neat if you focus on learners. Once mildly proficient, one'll want the speed and flow of typing and freely operating on lines/blocks/selections in an unconstrained text file.
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
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
drilling into this a second -- and as someone who has been using vi for about 37 years -- why do you take this as a truth? Consider, e.g., intellij.
[deleted]
Holy cow the site takes forever to load, the demo takes forever to load. I hope that's not representative of actual use, but I wasn't patient enough to wait and find out.
Sorry about that! We are experiencing significantly higher load than we are used to, but working on a fix presently.
The exciting possibility isn't switching Python/Lisp/Java syntax (most people will pick one and stick with it), but being able to add language features and see your program immediately get more concise.
For example, Javascript added `bar${foo}`, but my code still has lots of 'bar' + foo. It'd be sweet to just click a checkbox and see my code get smaller on screen, without changing the underlying source code.
So what I really want is an editor that takes verbose languages and collapses common idioms into concise syntax.
For example, Javascript added `bar${foo}`, but my code still has lots of 'bar' + foo. It'd be sweet to just click a checkbox and see my code get smaller on screen, without changing the underlying source code.
So what I really want is an editor that takes verbose languages and collapses common idioms into concise syntax.
This is called 'projectional editing', an idea that to my knowledge goes back to the 60s.
A projectional editor shows you both the original source code, and alternate representations (or, 'projections') of it. Given the right plugins and config, these alternate projections could happen to be more intuitive to grasp/edit than the original source code. One plugin could, for example, remove all the unnecessary semicolons. Another, could remove all the unnecessary punctuations and project the code in an indentation-significant way or vice-versa. Your idea to replace all the `'bar' + foo`s with ``bar{foo}``s would also be possible.
It's easy to imagine much more advanced use-cases. A sufficiently advanced editor could detect calls to FRP libraries, and project the data flow as a visual graph (picture all the `flatMaps()` and `scanLatest()s` as nodes on that graph). Or, given access to compile-time type info (via a typescript-style language-server), it could overlay the type of a value with the missing fields being shown as slots to be filled.
I can imagine such an editor to mostly "obsolete" the idea of a single syntax for each language in the first place. Like the language but not the syntax? Roll your own syntax! Just configure your own editor plugins. No one would have to know. No one would have to agree with your "taste." Not even your git repo [0]. (See /r/nosyntax/ for more ideas)
A projectional editor can also be implemented in the runtime, ala Smalltalk. In that case, the language itself is designed from the bottom up to accommodate such DX and opens many more possibilities.
A Clojure Conj talk called "... forgotten Lisp UX" explores the history of this idea in the context of lisp [1]. The author is also on Patreon doing exciting things in this field (https://www.patreon.com/shaunlebron).
---
[0] the editor may store some metadata next to the code that'd be committed to the repo, but the code itself would still be saved in the original syntax. [1] Inspiring a future Clojure editor with forgotten Lisp UX - Shaun Lebron https://www.youtube.com/watch?v=K0Tsa3smr1w
A projectional editor shows you both the original source code, and alternate representations (or, 'projections') of it. Given the right plugins and config, these alternate projections could happen to be more intuitive to grasp/edit than the original source code. One plugin could, for example, remove all the unnecessary semicolons. Another, could remove all the unnecessary punctuations and project the code in an indentation-significant way or vice-versa. Your idea to replace all the `'bar' + foo`s with ``bar{foo}``s would also be possible.
It's easy to imagine much more advanced use-cases. A sufficiently advanced editor could detect calls to FRP libraries, and project the data flow as a visual graph (picture all the `flatMaps()` and `scanLatest()s` as nodes on that graph). Or, given access to compile-time type info (via a typescript-style language-server), it could overlay the type of a value with the missing fields being shown as slots to be filled.
I can imagine such an editor to mostly "obsolete" the idea of a single syntax for each language in the first place. Like the language but not the syntax? Roll your own syntax! Just configure your own editor plugins. No one would have to know. No one would have to agree with your "taste." Not even your git repo [0]. (See /r/nosyntax/ for more ideas)
A projectional editor can also be implemented in the runtime, ala Smalltalk. In that case, the language itself is designed from the bottom up to accommodate such DX and opens many more possibilities.
A Clojure Conj talk called "... forgotten Lisp UX" explores the history of this idea in the context of lisp [1]. The author is also on Patreon doing exciting things in this field (https://www.patreon.com/shaunlebron).
---
[0] the editor may store some metadata next to the code that'd be committed to the repo, but the code itself would still be saved in the original syntax. [1] Inspiring a future Clojure editor with forgotten Lisp UX - Shaun Lebron https://www.youtube.com/watch?v=K0Tsa3smr1w
Thanks for such an insightful and educational comment, AriaMinaei! Really interesting stuff.
I have long wanted this for symbol names. When I'm in the zone, I want to write/edit very short names for all kinds of symbolic names. But I want this to be a view, and the underlying code to remain verbose names for later reading. I once set out to create a VSCode plugin for this, only to discover it was not possible to automate the Symbol Rename feature. You can do it with regex find/replace, but it would be much stronger if you could use the compiler to do it.
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).
> The exciting possibility isn't switching Python/Lisp/Java syntax
Also, parsing and generating N languages is a really, really hard problem.
> So what I really want is an editor that takes verbose languages and collapses common idioms into concise syntax.
IDEA does this. Among other things, it hides lots of boilerplate in Java anonymous inner classes.
Also, parsing and generating N languages is a really, really hard problem.
> So what I really want is an editor that takes verbose languages and collapses common idioms into concise syntax.
IDEA does this. Among other things, it hides lots of boilerplate in Java anonymous inner classes.
> Also, parsing and generating N languages is a really, really hard problem.
Really, it is not a hard problem with the right tools. Haskell, for example, is extremely good at parsing and generating (maybe that's the only thing that is is #1 in, but it is miles beyond any other language I have used...). An example of this is pandoc https://pandoc.org/
Really, it is not a hard problem with the right tools. Haskell, for example, is extremely good at parsing and generating (maybe that's the only thing that is is #1 in, but it is miles beyond any other language I have used...). An example of this is pandoc https://pandoc.org/
Haskell has ways of expressing that sort of logic well, but you still need to write, maintain, and test all of the code that abstracts all the languages. There will be a lot of demand for optimizations, customization points, support for importing third party packages, and so on. There's a huge gap between proof of concept and fully mature product in this space. You're basically talking about modelling all the compilers and interpreters with one product.
You'd only need one interpreter. The only thing you're switching out is the lexer/parser.
Yep, just like C# and VB.net. Basically no code duplication between the two.
There are libs out there that do automated refactors as such:
https://github.com/jonase/kibit
https://github.com/jonase/kibit
That sounds like something you could do with Lisp-style macros.
I can't tell what this is just by looking at the home page. After taking a tour and wading my way through all the frustrating "next" buttons I still have no idea what advantages this environment might offer me. As someone else mentioned the site was extremely slow. Feels like it's overly bloated. I'm out before I even tried it.
I've now gone back and tried the sandbox and I couldn't code like this. As such, I'm still left wondering what is the use case for this?
I've now gone back and tried the sandbox and I couldn't code like this. As such, I'm still left wondering what is the use case for this?
>I can't tell what this is just by looking at the home page.
And when I tried the 'Python-inspired' tour, it just waits (presumably it's overloaded just now) and breaks my back button.
Thumbs up for the tour. I was able to navigate it on my 4.7" phone with Firefox.
I basically lost interest into the language when I run into the most verbose type declaration I ever saw, isomorf.number.Number (I couldn't copy it on the phone). There must be a better way to do it.
But the idea is cool even if maybe not very new. I've seen different languages compiled or interpreted into the same pcode, bytecode, etc. Maybe the translation here is deterministic.
I basically lost interest into the language when I run into the most verbose type declaration I ever saw, isomorf.number.Number (I couldn't copy it on the phone). There must be a better way to do it.
But the idea is cool even if maybe not very new. I've seen different languages compiled or interpreted into the same pcode, bytecode, etc. Maybe the translation here is deterministic.
I found the tour infuriating. I really do not have the desire to click 100 next buttons when 70% of them are obvious. I exited before I finished the tour.
Thanks for the feedback. We will definitely have a way to hide those verbose namespaces.
It would be really great if there are some real-world examples. Like, how would look code with side effects (i.e. network read/write)? Can I use Actor Model with Isofmorph and how? Is there any interoperability with existing frameworks?
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!
Is there some text to read explaining what this is? Assuming that the visitor to the site prefers “hands on” learning is tantamount to assuming they have the intellect of a toddler in my book.
There are more thorough descriptions on our blog if that is a preferred medium: https://blog.isomorf.io/
Those look great, thanks. Somehow I didn't recognize the "blog" link on the home page as being what I should click on to get a written docs/whitepaper style description.
Reminds me of this great Gary Bernhardt talk https://www.destroyallsoftware.com/talks/a-whole-new-world
This almost certainly won't catch on because inertia is very hard to overcome, but how amazing would it be to have computers do more of the heavy lifting for us?
(this is guided by my reaction to the product, where I saw the following:
* Syntax is a detail, you choose one you like without altering the semantics! It's a view layer.
* Static types (present in many other languages, less of a gamechanger)
* Analysis of dependencies of and users of code at-a-glance.
* in-IDE integration with social element of it
These were what struck me as the most novel bits, but I might have missed others)
This almost certainly won't catch on because inertia is very hard to overcome, but how amazing would it be to have computers do more of the heavy lifting for us?
(this is guided by my reaction to the product, where I saw the following:
* Syntax is a detail, you choose one you like without altering the semantics! It's a view layer.
* Static types (present in many other languages, less of a gamechanger)
* Analysis of dependencies of and users of code at-a-glance.
* in-IDE integration with social element of it
These were what struck me as the most novel bits, but I might have missed others)
I have 60 seconds. I couldn't figure out what this was, so it's forgotten.
A few screenshots on the home page that gives an abstract idea would solve this.
EDIT: Found this by reading the comments. https://blog.isomorf.io/what-is-isomorƒ-bdc50ce597ee In another 60 seconds I've learned that it's a way to program in a syntax-agnostic way with your mouse. I don't like using my mouse because of wrist fatigue, so I guess I wouldn't be interested.
A few screenshots on the home page that gives an abstract idea would solve this.
EDIT: Found this by reading the comments. https://blog.isomorf.io/what-is-isomorƒ-bdc50ce597ee In another 60 seconds I've learned that it's a way to program in a syntax-agnostic way with your mouse. I don't like using my mouse because of wrist fatigue, so I guess I wouldn't be interested.
> In another 60 seconds I've learned that it's a way to program in a syntax-agnostic way with your mouse.
Oh wow I got like 5 minutes into the tour and didn't realize that until I read your comment. I gave up because it felt like I was just looking at an HTML IDE with some verbose Java. If the novel part of the product isn't showcased in the first few minutes of the tour you're going to lose a lot of interest.
Oh wow I got like 5 minutes into the tour and didn't realize that until I read your comment. I gave up because it felt like I was just looking at an HTML IDE with some verbose Java. If the novel part of the product isn't showcased in the first few minutes of the tour you're going to lose a lot of interest.
I couldn't get it to do anything with the mouse. As far as I could tell, it uses key presses outside of text input widgets to do anything useful. My Firefox is set up to search as I type, so key presses outside of text input widgets aren't visible to the application.
Oh well. Structural editors didn't catch on in the 1980s, I'm not holding my breath for the 2010s. But we'll see; some things do change. Also, it might really be useful for beginners or people who write programs without considering themselves programmers.
Oh well. Structural editors didn't catch on in the 1980s, I'm not holding my breath for the 2010s. But we'll see; some things do change. Also, it might really be useful for beginners or people who write programs without considering themselves programmers.
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...
While I agree with you on most things and I understand I'm not adding much to the overall discussion I kinda feel like saying:
>I don't like using my mouse because of wrist fatigue, so I guess I wouldn't be interested.
Is like saying:
>Having to do activities that involve lightly throwing baseballs hurts my arm so I'm going to stick with lightly throwing tennis balls.
>I don't like using my mouse because of wrist fatigue, so I guess I wouldn't be interested.
Is like saying:
>Having to do activities that involve lightly throwing baseballs hurts my arm so I'm going to stick with lightly throwing tennis balls.
Nifty. Some thoughts...
General UX: "What will/did this button-with-no-tooltip do?" was a theme for me.
Tour UX: I felt trapped in chains of modal windows.
Perhaps add "clicking outside modal windows bails out of chain"; and in Overview, "clicking on numbered topic jumps to that step". These are perhaps low hanging fruit for restoring some user control of navigation?
I wonder if "tours" is the right objective. Perhaps topical examples? Eg https://threejs.org/examples/ ? However... many use youtube videos to learn code far more than I would, so perhaps I'm just not the target audience for a video-like tour. Perhaps a label change to set expectations "Take a video-like tour"? But I expect to be able to jump around in videos. Screencast the tours for youtube?
Language: I wish the type system was richer. I'd happily accept "projections have structured comments describing unrepresentable semantics" for that. If I could express the type "thing with a partial order < and a +", then I'd have looked to sign up, intending to upload a bunch of algorithm code.
Functions are nice, but to win big, we need a better type system than is currently available. ADT's don't scale. Witness haskell's half-decade of heroic effort... just to insert Applicative. Anyone wants to make something like this with a type system that's a pushout lattice of theories, I am your slave. Figuratively.
Randomness: Projective editing might help with the Unicode!/Ascii! Agda/Idris rift, but the semantics would be a challenge, and the market small. Though its maybe a good population to attract if the type system were more of a focus. Fortress-style "projected to look like math" might appeal to Julia-is-the-new-FORTRAN folks? Using kate.com-style emacs/vi/etc plugins with a "sidebar" website window for value-add, might separate out the "switch to us as your editor" aspect from the "here's analysis and ecosystem" aspect.
XR changes the UX constraint space for this kind of thing. Perhaps startlingly soon and rapidly. So something to keep an eye on. The bite-sized functions, sidebar analysis, refactoring, fine-grain ecosystem, and type directed development and search, seem good matches for an XR UI.
General UX: "What will/did this button-with-no-tooltip do?" was a theme for me.
Tour UX: I felt trapped in chains of modal windows.
Perhaps add "clicking outside modal windows bails out of chain"; and in Overview, "clicking on numbered topic jumps to that step". These are perhaps low hanging fruit for restoring some user control of navigation?
I wonder if "tours" is the right objective. Perhaps topical examples? Eg https://threejs.org/examples/ ? However... many use youtube videos to learn code far more than I would, so perhaps I'm just not the target audience for a video-like tour. Perhaps a label change to set expectations "Take a video-like tour"? But I expect to be able to jump around in videos. Screencast the tours for youtube?
Language: I wish the type system was richer. I'd happily accept "projections have structured comments describing unrepresentable semantics" for that. If I could express the type "thing with a partial order < and a +", then I'd have looked to sign up, intending to upload a bunch of algorithm code.
Functions are nice, but to win big, we need a better type system than is currently available. ADT's don't scale. Witness haskell's half-decade of heroic effort... just to insert Applicative. Anyone wants to make something like this with a type system that's a pushout lattice of theories, I am your slave. Figuratively.
Randomness: Projective editing might help with the Unicode!/Ascii! Agda/Idris rift, but the semantics would be a challenge, and the market small. Though its maybe a good population to attract if the type system were more of a focus. Fortress-style "projected to look like math" might appeal to Julia-is-the-new-FORTRAN folks? Using kate.com-style emacs/vi/etc plugins with a "sidebar" website window for value-add, might separate out the "switch to us as your editor" aspect from the "here's analysis and ecosystem" aspect.
XR changes the UX constraint space for this kind of thing. Perhaps startlingly soon and rapidly. So something to keep an eye on. The bite-sized functions, sidebar analysis, refactoring, fine-grain ecosystem, and type directed development and search, seem good matches for an XR UI.
> ADT's don't scale. Witness haskell's half-decade of heroic effort... just to insert Applicative
Huh? Firstly that has nothing to do with ADTs. Applicative's a type class. Secondly it didn't take effort it just took an agreement to do it and enough warning and checks that everyone had done the minimal rewrites required. If anything taking five years was a sign that it wasn't desperately important, just housekeeping.
Huh? Firstly that has nothing to do with ADTs. Applicative's a type class. Secondly it didn't take effort it just took an agreement to do it and enough warning and checks that everyone had done the minimal rewrites required. If anything taking five years was a sign that it wasn't desperately important, just housekeeping.
Easy? Minimal? Ok, yes, compared to... something. C++ standards committee. But consider mathematics. You hand someone an algorithm, valid exactly on some theory/algebra/structure, with its types/equality, operators, and laws. And that's it - that's everything. It doesn't matter what they're named, or in what order they were gathered, or where that structure happens to appear in the lattice of some prelude or another. There's no context, no cruft. If you want a language with the expressive power of mathematics, it needs to support the expressive power of mathematics.
> it didn't take effort [...] housekeeping
This description is not consistent with my limited observation of discussions among some involved.
> it didn't take effort [...] housekeeping
This description is not consistent with my limited observation of discussions among some involved.
> You hand someone an algorithm, valid exactly on some theory/algebra/structure, with its types/equality, operators, and laws. And that's it - that's everything. It doesn't matter what they're named, or in what order they were gathered, or where that structure happens to appear in the lattice of some prelude or another
This is also the case for algorithms in Haskell when the Applicative Monad Proposal was enacted. All existing implementations stayed unchanged. The benefit of the AMP was that some implementations could drop an Applicative constraint if they wanted.
> > it didn't take effort [...] housekeeping > > This description is not consistent with my limited observation of discussions among some involved.
Then I suggest you ask for further clarification. There was a lot of discussion and debate to make sure we got a smooth transition. Basically no one opposed the proposal. The changes to code were absolutely minimal.
This is also the case for algorithms in Haskell when the Applicative Monad Proposal was enacted. All existing implementations stayed unchanged. The benefit of the AMP was that some implementations could drop an Applicative constraint if they wanted.
> > it didn't take effort [...] housekeeping > > This description is not consistent with my limited observation of discussions among some involved.
Then I suggest you ask for further clarification. There was a lot of discussion and debate to make sure we got a smooth transition. Basically no one opposed the proposal. The changes to code were absolutely minimal.
How do you see real applications being managed in this system? The tour doesn't touch on this. The included examples are quite abstract, perhaps even too much as they don't really engage me -- I can't imagine caring about how many times a "length" function is used globally. If anything, that example gave me an uncomfortable vibe of the Node.js "left-pad" drama... Sharing code in ridiculously small units just doesn't solve any productivity problems I've experienced.
The stuff about abstract types and function shapes is certainly intellectually interesting, but I'd encourage you think in terms of larger assemblies of code. (Maybe you already are -- I do understand that this is an early demo and you want to get the core right.)