[HN Gopher] The Subtext 10 Programming Language
___________________________________________________________________
The Subtext 10 Programming Language
Author : akkartik
Score : 46 points
Date : 2021-09-27 07:30 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| timroediger wrote:
| 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.
| specialist wrote:
| 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 wrote:
| 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 wrote:
| 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.
| hathawsh wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| stormbrew wrote:
| > That's the gulf the GP was referring to; not from which
| people happen to use them, but from how they think about
| coding.
|
| I'm calling out an implicit bias that always comes up in
| discussions like these and I see lurking behind this
| sentiment, because these two things are inextricably
| related, not an accidental correlation.
|
| They think better in this paradigm _because_ its a better
| suited paradigm to their actual work, and it fits better
| with things they understand already because of their
| experiences and knowledge.
|
| When we prioritize the "thought patterns" of professional
| programmers we forget this, and then we lament the lack of
| understanding for our field from people outside of it. Our
| solutions, when we look at it this way (with a stark divide
| between "programmers" and "non-programmers"), end up
| demanding that they come to our understanding instead of us
| to theirs. And that's basically always doomed to fail.
|
| This is important.
| TuringTest wrote:
| You identified the essential qualities of spreadsheets, which
| many programmers fail to realize how important these are; these
| qualities are what make spreadsheets so useful to non-
| programmers. A successful development tool for non-coders
| should retain these, and explore alternative ways to add all
| the benefits of IDEs without the burden of classic programming
| languages.
|
| - Spreadsheets don't separate code from data, and that's the
| single most important reason why they're easy to use and allow
| non-developers to build automations. They work like an always-
| on debugger, so normal users can work like a programmer works
| when exploring and/or fixing a program's behaviour. Practically
| no other coding tool for non-developers allow this.
|
| - Naming is important for code reuse, not necessarily for one-
| shot functions; positional reasoning can work equally well
| there. Spreadsheets do allow naming cells and accessing them by
| name when needed; but the option not to, which classic PLs
| don't allow, lowers the entry barrier. Programmers could also
| name all their parameters 'a', 'b', 'c'; that they learn to use
| better names is a matter of discipline, not a limitation of the
| tool.
|
| - Scalar vs ranges: this one is actually the most limiting part
| of spreadsheets. They are great for tabular data structures
| (doh!), but nested structures are tricky. There are research
| projects to improve this (Microsoft hosts a lot of them on this
| line, specially around ML and Programming By Example), but in
| the end you need to overcome the paradigm and apply
| spreadsheet-like programming concepts to tools allowing
| hierarchical, nested structures. That lies the future of
| computation for the masses.
| kragen wrote:
| - You can have an always-on debugger while still factoring
| common code out of varying data. Subtext does this.
|
| - You can give things names after you create them instead of
| before, and it's not clear that argument names are
| necessarily either necessary or sufficient for code reuse.
| Subtext makes it easy to change argument names whenever you
| want.
|
| - It's reasonable to describe Subtext as a programming-by-
| example environment, and it does support nesting--in fact,
| it's rather pervasively nested. An alternative approach is to
| solve your problems without hierarchical, nested structures.
| SQL and co-dfns are two interesting directions there. I wrote
| an overview of this kind of thing five years ago:
| http://canonical.org/~kragen/memory-models/
| jonathanedwards wrote:
| Please take this as Computer Science Fiction
| eternalban wrote:
| 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 wrote:
| 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?
| TuringTest wrote:
| CC Non-commercial license, so it's dead on arrival.
|
| https://github.com/JonathanMEdwards/subtext10/blob/master/LI...
| webstrand wrote:
| 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 wrote:
| 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.
| kragen wrote:
| 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.
___________________________________________________________________
(page generated 2021-09-27 23:01 UTC)