11 ms·

Yeah that didn't happen. I stopped this work before I got to reimplementing the UI. I worked out some problems I've been obsessing about forever, but the result

Yeah that didn't happen. I stopped this work before I got to reimplementing the UI. I worked out some problems I've been obsessing about forever, but the result is just too complex and alien. Back to the drawing board. Thanks for your encouragement all these years.

kragen 5y ago
Any significant improvement will necessarily be a significant change and therefore alien. Computers were alien, and the culture projected all its fears onto them: rightists churned out endless movies about slave revolts with computers and robots in the role of slaves, while leftists tried to bomb and burn down computer centers as oppressive instruments of the System. FORTRAN and COBOL were alien to experienced programmers, who seriously doubted how optimal the output assembly would be. VisiCalc was alien to Fortran programmers. You're still pushing back against the remnants of that rejection today. MacOS in 01984 was alien to those of us who'd grown up writing BASIC. It provoked hostility, too! Pascal was alien to me because it didn't have line numbers. Online chatting was alien. We called ourselves "geeks". I still have anti-JS JS from 02000 on http://canonical.org/~kragen/hotlist.html http://canonical.org/~kragen/hotlist.html because JS was alien and I hated it. When we pioneered AJAX and Comet later that year at KnowNow (one of three independent inventions), it was alien, and in fact it took four years before Gmail took AJAX mainstream; Comet took even longer. So don't worry about being alien. You're shooting for a revolutionary change, not an incremental improvement. Revolutionary changes are difficult under the best of circumstances, but they are impossible to achieve without being alien. Your weirdness budget isn't unlimited but it's necessarily larger than for an incremental change. I know it would be a headache to achieve it, but it would be pretty useful to have an open-source runnable version of any of the older Subtext prototypes.
- jonathanedwards 5y ago
  Well said. You know, sometime soon I need to make a stand. My gut check was that this wasn't the hill I'm willing to die on.
  - TuringTest 5y ago
    I didn't know of the existence of Subtext, and I've felt impressed by the core set of ideas behind it (even if at first I was underwhelmed when first looked at how it was licensed, sorry about that). I've seen recently many other converging to the same region of the design space, but your approach hits all the relevant points on what I would expect on a system for a next-generation style of computing. I have some ideas on my own on building a new style of computing environment that doesn't feel alien, and I've arrived to a lot of the same conclusions that you describe in the "Notable features" section. My approach is to focus the environment in content-editing first (i.e. making it feel like a "structured content editor" more than a IDE), and representing code primarily with a metaphor of content transformation over collections (think Google's OpenRefine or MS Power BI), rather than as processes running on an application. I have a core idea at the base of the structure for this system, which is to reify function applications as a named object in the environment, much like your idea of treating function results as collections of values accessible as raw data. This reified object, which I call a wit for memorability, acts very much like items in your Subtext, except that: * Each wit has a unique identifier (a 'label') which can be used to annotate data directly through direct manipulation, like giving a name to a cell in a spreadsheet. The user can build collections by applying the same tag to all the values in the collection, manually or supported by a PbE process. The wit represents the data structure containing all those values; but at the same time it may represent the process used to generate them. * There is no distinction among scalars and collections. I think this is the most unique feature of my system; you may apply a function to a wit (identified by its label), and it gets lazily applied to all its values, thus creating a new collection of transformed values. This is similar to named ranges in a spreadsheet, but it doesn't depend on a positional grid. And single values are treated the same as collections, so there's no need for loop constructs; the user can simply build templates with wits as variables, which then get applied to all their possible values in their input domain. (Microsoft has a similar feature with their research on FlashFill, which was posted here a few days ago[1]). * Wits may be used as identifiers of attributes, to extract content from records. That content may be previously stored values or computed on the fly from their formula and current inputs (just like in your "Subtext is both a PL and a DB" line). I.e. wits can represent relations among entities, not just code applied over data. This blurs the metaphors of function application and data structure, which I believe is a good thing for easy-to-use computational environments. * Since code is seen as data collections, you can build repeatable behaviors by changing the input on a sequence of transformations. For example, recorded recent user actions are not seen as a sequence of code steps, but a sequence of intermediate processed states of the transformed collection (with each step being itself represented by a wit, and thus accessible as data). I think you have a similar idea with your "functions seen as expanding to traces", but I envision using the intermediate steps as possible inputs to new functions (facilitating creation of pipes and recursion by demonstration). I've felt my ideas validated when seeing that you've created a system which has evolved to a very similar design space; your Feedback mechanism is a neat solution to the representation of interaction and user updates, for which I didn't have a concrete solution (other than the abstract idea of representing all state as updates on functional-reactive streams). Unfortunately my design process involves primarily paper prototypes and lots of concept notes; and also I don't get paid for it, so there's very little in a shareable form. Do you have a public discussion forum where these ideas can be discussed in the open? It would be good to share my detailed concepts and see how they apply to concrete use cases that you may have in mind for building your system. [1] https://news.ycombinator.com/item?id=28548165 https://news.ycombinator.com/item?id=28548165 "Story of the Flash Fill Feature in Excel"

kragen 5y ago

Any significant improvement will necessarily be a significant change and therefore alien. Computers were alien, and the culture projected all its fears onto them: rightists churned out endless movies about slave revolts with computers and robots in the role of slaves, while leftists tried to bomb and burn down computer centers as oppressive instruments of the System. FORTRAN and COBOL were alien to experienced programmers, who seriously doubted how optimal the output assembly would be. VisiCalc was alien to Fortran programmers. You're still pushing back against the remnants of that rejection today. MacOS in 01984 was alien to those of us who'd grown up writing BASIC. It provoked hostility, too! Pascal was alien to me because it didn't have line numbers. Online chatting was alien. We called ourselves "geeks". I still have anti-JS JS from 02000 on http://canonical.org/~kragen/hotlist.html http://canonical.org/~kragen/hotlist.html because JS was alien and I hated it. When we pioneered AJAX and Comet later that year at KnowNow (one of three independent inventions), it was alien, and in fact it took four years before Gmail took AJAX mainstream; Comet took even longer. So don't worry about being alien. You're shooting for a revolutionary change, not an incremental improvement. Revolutionary changes are difficult under the best of circumstances, but they are impossible to achieve without being alien. Your weirdness budget isn't unlimited but it's necessarily larger than for an incremental change. I know it would be a headache to achieve it, but it would be pretty useful to have an open-source runnable version of any of the older Subtext prototypes.

jonathanedwards 5y ago
Well said. You know, sometime soon I need to make a stand. My gut check was that this wasn't the hill I'm willing to die on.
- TuringTest 5y ago
  I didn't know of the existence of Subtext, and I've felt impressed by the core set of ideas behind it (even if at first I was underwhelmed when first looked at how it was licensed, sorry about that). I've seen recently many other converging to the same region of the design space, but your approach hits all the relevant points on what I would expect on a system for a next-generation style of computing. I have some ideas on my own on building a new style of computing environment that doesn't feel alien, and I've arrived to a lot of the same conclusions that you describe in the "Notable features" section. My approach is to focus the environment in content-editing first (i.e. making it feel like a "structured content editor" more than a IDE), and representing code primarily with a metaphor of content transformation over collections (think Google's OpenRefine or MS Power BI), rather than as processes running on an application. I have a core idea at the base of the structure for this system, which is to reify function applications as a named object in the environment, much like your idea of treating function results as collections of values accessible as raw data. This reified object, which I call a wit for memorability, acts very much like items in your Subtext, except that: * Each wit has a unique identifier (a 'label') which can be used to annotate data directly through direct manipulation, like giving a name to a cell in a spreadsheet. The user can build collections by applying the same tag to all the values in the collection, manually or supported by a PbE process. The wit represents the data structure containing all those values; but at the same time it may represent the process used to generate them. * There is no distinction among scalars and collections. I think this is the most unique feature of my system; you may apply a function to a wit (identified by its label), and it gets lazily applied to all its values, thus creating a new collection of transformed values. This is similar to named ranges in a spreadsheet, but it doesn't depend on a positional grid. And single values are treated the same as collections, so there's no need for loop constructs; the user can simply build templates with wits as variables, which then get applied to all their possible values in their input domain. (Microsoft has a similar feature with their research on FlashFill, which was posted here a few days ago[1]). * Wits may be used as identifiers of attributes, to extract content from records. That content may be previously stored values or computed on the fly from their formula and current inputs (just like in your "Subtext is both a PL and a DB" line). I.e. wits can represent relations among entities, not just code applied over data. This blurs the metaphors of function application and data structure, which I believe is a good thing for easy-to-use computational environments. * Since code is seen as data collections, you can build repeatable behaviors by changing the input on a sequence of transformations. For example, recorded recent user actions are not seen as a sequence of code steps, but a sequence of intermediate processed states of the transformed collection (with each step being itself represented by a wit, and thus accessible as data). I think you have a similar idea with your "functions seen as expanding to traces", but I envision using the intermediate steps as possible inputs to new functions (facilitating creation of pipes and recursion by demonstration). I've felt my ideas validated when seeing that you've created a system which has evolved to a very similar design space; your Feedback mechanism is a neat solution to the representation of interaction and user updates, for which I didn't have a concrete solution (other than the abstract idea of representing all state as updates on functional-reactive streams). Unfortunately my design process involves primarily paper prototypes and lots of concept notes; and also I don't get paid for it, so there's very little in a shareable form. Do you have a public discussion forum where these ideas can be discussed in the open? It would be good to share my detailed concepts and see how they apply to concrete use cases that you may have in mind for building your system. [1] https://news.ycombinator.com/item?id=28548165 https://news.ycombinator.com/item?id=28548165 "Story of the Flash Fill Feature in Excel"