8 ms·

The Subtext 10 Programming Language

56 points by akkartik 5y ago

TuringTest 5y ago
CC Non-commercial license, so it's dead on arrival. https://github.com/JonathanMEdwards/subtext10/blob/master/LICENSE.txt https://github.com/JonathanMEdwards/subtext10/blob/master/LI...
- webstrand 5y ago
  That'll only affect copies of the specification. Implementations are subject to their own licensing. I believe the lack of a patents grant clause is the only worrisome thing about CC licenses?
  - TuringTest 5y ago
    Yeah, but what good is a specification of an obscure language that commercial projects won't touch because it's share-alike, and free projects won't touch because it's not-free? It would need to be a success to warrant alternative implementations, and the license is inadequate for a language to get widespread adoption.
specialist 5y ago
What would a data-only spreadsheet serialized to a human readable format look like? What if you add formulas? I have no idea if Subtext 10 has legs. It kinda reminds me of Fran, so that's a good start (direction). All I'm saying is that if I was gonna tackle this problem, I'd start with turning Excel files into into source code.
- sswezey 5y ago
  I've been pondering similar ideas as this for a while. I think you are correct by starting with Excel files. What I've been hammock thinking is a way to bridge the gap between spreadsheets and what we tend to consider code. Why can't we iterate spreadsheets to something that makes it easier to: diff, review, separate logic from data, track in version control, write new functions/macros, re-use, package and distribute. I think as more people will need to use computers more, that everyone will need to have access to some form of programming skills. I think spreadsheets are a successful mechanism for people to rapidly manipulate data, but they deteriorate quickly with complexity. A tool that doesn't throw out the baby with the bathwater could help people ramp up to programming much easier. If you teach someone to write a function that operates on a medium they already know like a spreadsheet, it is a lot less intimidating than writing a .py file, and downloading python and learning what compile is.
  - TuringTest 5y ago
    There's a lot of thinking around those lines, specially since the work of Bret Victor on data-rich programmable environments. Spreadsheet-like IDEs are the most logical direction to meet that vision, specially when you want to attract non-programmers; figuring out the language syntax and the runtime execution model are the hardest parts of learning to program, and spreadsheets minimize both. I put my bet on code notebooks, of the functional reactive variety. They have the same interaction model of the spreadsheet, intermixing data and code in the same environment, and they allow you to grow a program iteratively with cells acting as reusable objects - a simpler metaphor than OOP, but equally powerful. Data scientists are already making good use of them, and it's easy to think that these notebooks will be getting more and more of the debugging and DevOps functions of traditional IDEs.
jonathanedwards 5y ago
Please take this as Computer Science Fiction
- eternalban 5y ago
  constructive feedback, Jonathan: Things like // passing values through check x do { check >? 0 check even?() + 1 } appear to be in conflict with stated goal of "It is an interactive medium for data processing by people who don’t want to learn how to program. For example, scientists who want to process data without becoming “data scientists”. Or people who want to build simple custom apps without learning to program." [This fighting text with text is indeed a CSFi soap opera :)]
  - skybrian 5y ago
    It says at the beginning that the actual UI wouldn’t be text based. Though, it seems like that leaves an open question of how to represent this?
  - jonathanedwards 5y ago
    Thanks yeah it's got a long way to go.
hathawsh 5y ago
I once built a complex spreadsheet for my colleagues. When I had to leave, what I built for them was almost instantly useless because there was too much they needed to understand. That got me thinking about the gulf between spreadsheets and programming languages. There are important differences: - Spreadsheets don't separate code from data, which is an important aspect of programming. Blending the two is a nice shortcut for spreadsheets, but it ruins maintainability. - Naming is important for programming, but spreadsheets encourage users to not bother with names and fall back to cell coordinates like "A10" instead. It's a great shortcut, but again, it ruins maintainability. - Spreadsheet formulas operate on scalar values, while programming languages operate on nested data structures. Data structures are a key to managing complexity, yet the spreadsheet paradigm has only a very limited view of them. If users are ever going to be able to use a spreadsheet-like interface for serious programming, most of those issues will need to be addressed in a way that doesn't hurt usability. That's a tall order! Users already struggle with function calls in formulas. At some point it's smarter for users to just pay a programmer to figure out how to build it.
- stormbrew 5y ago
  > the gulf between spreadsheets and programming languages There is no gulf. Spreadsheets just are programming languages. You've certainly identified problems or at least quirks of spreadsheets as a 'language', but I think people do a huge disservice to their own ability to understand programming as a field when they try to carve out exclusions for languages and environments on the basis of who uses them. Lots of things no one would ever argue aren't a programming language have all these flaws and more. When people make a big ass complicated spreadsheet, they are programming. They are doing so whether they're a seasoned professional or an accountant or a lawyer or a homemaker.
  - TuringTest 5y ago
    Of course people who use spreadsheets are programming; they're building data structures (with columns as object fields), generating values from formulas, and debugging the program's execution when editing cells. What develops typically don't get is that the paradigm of the programming language and environment matters a lot, triple so for people without formal training in coding. Most people who can code with a spreadsheet would be totally unable to create a very simple shell script, because the paradigm of imperative, syntax-led classic programming languages require building a mental model of a whole Turing machine in your head, which requires years of training. That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. The functional-reactive paradigm (and spreadsheets in particular) avoid that need, because they're highly composable so you can truly think of each part of the program in isolation, something which side-effects and program flow in imperative programs won't allow.
kragen 5y ago
I've found Jonathan's research in Subtext inspirational for a long time, though only through watching videos and reading papers. It's too bad it's not under a free license, but hopefully people can get it to run well enough to get some experience with the interaction model he's refined through all these iterations.
- jonathanedwards 5y ago
  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.
timroediger 5y ago
As someone who has been working in this area for a while, for a programing language to be embraced by non-programmers it has to not look like a programing language. That is, no matter how streamlined an simple it feels to us programmers, when you stand two meters back from the screen if it looks like c++ then it won't have any significant uptake. I scroll through the subtext page and just see code samples that look pretty much like any other language, and that's what the non-programmer target audience will notice.
- jonathanedwards 5y ago
  Strong agree. The syntax in this work was meant to be mostly hidden from the end user. I've found that syntax is still really useful for language design and implementation. I stopped before building the graphical programming environment on top.
  - timroediger 5y ago
    Designing a productive graphical programming environment is very challenging. I think it is probably at least as difficult as designing the underlying language mechanics. I'd love to see any experiments you might be able to share.
smaddox 5y ago
> Will Subtext be open source? > I hope not. Open source works best for software used by other programmers, because that is how the contributors get their cred. But the economics of startups conflict with the goal of liberating software development. Perhaps a hybrid form like a Public Benefit Corp or a Coop offers a workable middle way. ... Huh? The question is about open source. The answer seems to be about startups. Was this an editing mixup?
- vanderZwan 5y ago
  You don't see how the economics of startups interact with the open source ecosystem and how someone's view of that interaction might affect their choice to not make something open source?
  - smaddox 5y ago
    I can certainly see how they might be related, but the answer doesn't clarify how---rather it seems completely disconnected in the first and second halves, which is why I'm wondering if it's just an editing error.
    - jonathanedwards 5y ago
      Just poor writing. I've talked more about this on my blog. Open source usually only works for tools for hackers. I want to reach the rest of humanity.
mikewarot 5y ago
I'm intrigued, but need to read through this a few times to get everything. One thing I don't understand is the dismissal of operator precedence for infix operators. It seems to me that creates an unnecessary impedance mismatch for getting formulae entered into the computer. Thanks for sharing.
- mikewarot 5y ago
  Having read some more, and watched the 2018 video, I now understand that ditching operator precedence was a necessary sacrifice to make your interactive environment something that could be implemented in a reasonable timeframe.
- jonathanedwards 5y ago
  Yeah, I've gotten a lot of pushback on that. One approach I've seen is to reject expressions that would violate standard precedence, and require extra parentheses.
- mikewarot 5y ago
  like lisp and forth, the moving of things to/from variables is removed from primacy, to good effect. being able to use a result without having to name it is a quite powerful tool. As with spreadsheets, the absolute or relative location can fill in as a address. Perhaps there should be some relative addressing for code, as you hinted ^ with spaces around it is the previous result.
wibblewobble123 5y ago
To some degree it overlaps with Inflex https://twitter.com/inflexhq https://twitter.com/inflexhq But the inspirations differ https://inflex.io/blog/bibliography https://inflex.io/blog/bibliography
DemocracyFTW 5y ago
> Subtext is both a PL and a DB to me this is really the desirable core idea

56 points by akkartik 5y ago

CC Non-commercial license, so it's dead on arrival. https://github.com/JonathanMEdwards/subtext10/blob/master/LICENSE.txt https://github.com/JonathanMEdwards/subtext10/blob/master/LI...

webstrand 5y ago
That'll only affect copies of the specification. Implementations are subject to their own licensing. I believe the lack of a patents grant clause is the only worrisome thing about CC licenses?
- TuringTest 5y ago
  Yeah, but what good is a specification of an obscure language that commercial projects won't touch because it's share-alike, and free projects won't touch because it's not-free? It would need to be a success to warrant alternative implementations, and the license is inadequate for a language to get widespread adoption.

specialist 5y ago

What would a data-only spreadsheet serialized to a human readable format look like? What if you add formulas? I have no idea if Subtext 10 has legs. It kinda reminds me of Fran, so that's a good start (direction). All I'm saying is that if I was gonna tackle this problem, I'd start with turning Excel files into into source code.

sswezey 5y ago
I've been pondering similar ideas as this for a while. I think you are correct by starting with Excel files. What I've been hammock thinking is a way to bridge the gap between spreadsheets and what we tend to consider code. Why can't we iterate spreadsheets to something that makes it easier to: diff, review, separate logic from data, track in version control, write new functions/macros, re-use, package and distribute. I think as more people will need to use computers more, that everyone will need to have access to some form of programming skills. I think spreadsheets are a successful mechanism for people to rapidly manipulate data, but they deteriorate quickly with complexity. A tool that doesn't throw out the baby with the bathwater could help people ramp up to programming much easier. If you teach someone to write a function that operates on a medium they already know like a spreadsheet, it is a lot less intimidating than writing a .py file, and downloading python and learning what compile is.
- TuringTest 5y ago
  There's a lot of thinking around those lines, specially since the work of Bret Victor on data-rich programmable environments. Spreadsheet-like IDEs are the most logical direction to meet that vision, specially when you want to attract non-programmers; figuring out the language syntax and the runtime execution model are the hardest parts of learning to program, and spreadsheets minimize both. I put my bet on code notebooks, of the functional reactive variety. They have the same interaction model of the spreadsheet, intermixing data and code in the same environment, and they allow you to grow a program iteratively with cells acting as reusable objects - a simpler metaphor than OOP, but equally powerful. Data scientists are already making good use of them, and it's easy to think that these notebooks will be getting more and more of the debugging and DevOps functions of traditional IDEs.

jonathanedwards 5y ago

Please take this as Computer Science Fiction

eternalban 5y ago
constructive feedback, Jonathan: Things like // passing values through check x do { check >? 0 check even?() + 1 } appear to be in conflict with stated goal of "It is an interactive medium for data processing by people who don’t want to learn how to program. For example, scientists who want to process data without becoming “data scientists”. Or people who want to build simple custom apps without learning to program." [This fighting text with text is indeed a CSFi soap opera :)]
- skybrian 5y ago
  It says at the beginning that the actual UI wouldn’t be text based. Though, it seems like that leaves an open question of how to represent this?
- jonathanedwards 5y ago
  Thanks yeah it's got a long way to go.

hathawsh 5y ago

I once built a complex spreadsheet for my colleagues. When I had to leave, what I built for them was almost instantly useless because there was too much they needed to understand. That got me thinking about the gulf between spreadsheets and programming languages. There are important differences: - Spreadsheets don't separate code from data, which is an important aspect of programming. Blending the two is a nice shortcut for spreadsheets, but it ruins maintainability. - Naming is important for programming, but spreadsheets encourage users to not bother with names and fall back to cell coordinates like "A10" instead. It's a great shortcut, but again, it ruins maintainability. - Spreadsheet formulas operate on scalar values, while programming languages operate on nested data structures. Data structures are a key to managing complexity, yet the spreadsheet paradigm has only a very limited view of them. If users are ever going to be able to use a spreadsheet-like interface for serious programming, most of those issues will need to be addressed in a way that doesn't hurt usability. That's a tall order! Users already struggle with function calls in formulas. At some point it's smarter for users to just pay a programmer to figure out how to build it.

stormbrew 5y ago
> the gulf between spreadsheets and programming languages There is no gulf. Spreadsheets just are programming languages. You've certainly identified problems or at least quirks of spreadsheets as a 'language', but I think people do a huge disservice to their own ability to understand programming as a field when they try to carve out exclusions for languages and environments on the basis of who uses them. Lots of things no one would ever argue aren't a programming language have all these flaws and more. When people make a big ass complicated spreadsheet, they are programming. They are doing so whether they're a seasoned professional or an accountant or a lawyer or a homemaker.
- TuringTest 5y ago
  Of course people who use spreadsheets are programming; they're building data structures (with columns as object fields), generating values from formulas, and debugging the program's execution when editing cells. What develops typically don't get is that the paradigm of the programming language and environment matters a lot, triple so for people without formal training in coding. Most people who can code with a spreadsheet would be totally unable to create a very simple shell script, because the paradigm of imperative, syntax-led classic programming languages require building a mental model of a whole Turing machine in your head, which requires years of training. That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. The functional-reactive paradigm (and spreadsheets in particular) avoid that need, because they're highly composable so you can truly think of each part of the program in isolation, something which side-effects and program flow in imperative programs won't allow.

kragen 5y ago

I've found Jonathan's research in Subtext inspirational for a long time, though only through watching videos and reading papers. It's too bad it's not under a free license, but hopefully people can get it to run well enough to get some experience with the interaction model he's refined through all these iterations.

jonathanedwards 5y ago
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.

timroediger 5y ago

As someone who has been working in this area for a while, for a programing language to be embraced by non-programmers it has to not look like a programing language. That is, no matter how streamlined an simple it feels to us programmers, when you stand two meters back from the screen if it looks like c++ then it won't have any significant uptake. I scroll through the subtext page and just see code samples that look pretty much like any other language, and that's what the non-programmer target audience will notice.

jonathanedwards 5y ago
Strong agree. The syntax in this work was meant to be mostly hidden from the end user. I've found that syntax is still really useful for language design and implementation. I stopped before building the graphical programming environment on top.
- timroediger 5y ago
  Designing a productive graphical programming environment is very challenging. I think it is probably at least as difficult as designing the underlying language mechanics. I'd love to see any experiments you might be able to share.

smaddox 5y ago

> Will Subtext be open source? > I hope not. Open source works best for software used by other programmers, because that is how the contributors get their cred. But the economics of startups conflict with the goal of liberating software development. Perhaps a hybrid form like a Public Benefit Corp or a Coop offers a workable middle way. ... Huh? The question is about open source. The answer seems to be about startups. Was this an editing mixup?

vanderZwan 5y ago
You don't see how the economics of startups interact with the open source ecosystem and how someone's view of that interaction might affect their choice to not make something open source?
- smaddox 5y ago
  I can certainly see how they might be related, but the answer doesn't clarify how---rather it seems completely disconnected in the first and second halves, which is why I'm wondering if it's just an editing error.
  - jonathanedwards 5y ago
    Just poor writing. I've talked more about this on my blog. Open source usually only works for tools for hackers. I want to reach the rest of humanity.

mikewarot 5y ago

I'm intrigued, but need to read through this a few times to get everything. One thing I don't understand is the dismissal of operator precedence for infix operators. It seems to me that creates an unnecessary impedance mismatch for getting formulae entered into the computer. Thanks for sharing.

mikewarot 5y ago
Having read some more, and watched the 2018 video, I now understand that ditching operator precedence was a necessary sacrifice to make your interactive environment something that could be implemented in a reasonable timeframe.
jonathanedwards 5y ago
Yeah, I've gotten a lot of pushback on that. One approach I've seen is to reject expressions that would violate standard precedence, and require extra parentheses.
mikewarot 5y ago
like lisp and forth, the moving of things to/from variables is removed from primacy, to good effect. being able to use a result without having to name it is a quite powerful tool. As with spreadsheets, the absolute or relative location can fill in as a address. Perhaps there should be some relative addressing for code, as you hinted ^ with spaces around it is the previous result.

wibblewobble123 5y ago

To some degree it overlaps with Inflex https://twitter.com/inflexhq https://twitter.com/inflexhq But the inspirations differ https://inflex.io/blog/bibliography https://inflex.io/blog/bibliography

DemocracyFTW 5y ago

> Subtext is both a PL and a DB to me this is really the desirable core idea