4 ms·

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.

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/ 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.

tome 9y ago
> 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.
- mncharity 9y ago
  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.
  - tome 9y ago
    > 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.

tome 9y ago

> 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.

mncharity 9y ago
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.
- tome 9y ago
  > 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.