Adventures in Dataflow
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 287 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/56898 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
GradientAreaAntimatterAdventure gameComputer programmingDataflowComputer programVideo gameMusical ensembleHypothesisGastropod shellPower (physics)Cartesian coordinate systemInterface (computing)Scripting languageWordNeuroinformatikSemantics (computer science)Virtual machineFreewareTheory of relativityDivisorSoftware maintenanceData managementDialectSoftwareMultiplication signProgrammer (hardware)Point (geometry)Context awarenessDefault (computer science)Commodore VIC-20Field (computer science)QuicksortMoore's lawComputational scienceFocus (optics)SmartphoneNumberTheoryArrow of timePresentation of a groupRight angleType theoryComputer-assisted translationBoss CorporationComputerProjective planeComputer scienceData storage deviceDiagramMeeting/Interview
03:47
Functional programmingComputerComputer scienceLatent heatComputer programmingNeuroinformatikConnected spaceFunctional (mathematics)Cartesian coordinate systemSeries (mathematics)outputNumberGraph (mathematics)Integrated development environmentDataflowDeclarative programmingTask (computing)Virtual machineProgrammer (hardware)First-order logicSingle-precision floating-point formatMathematicsImperative programmingObservational studyTerm (mathematics)TouchscreenMeeting/Interview
05:38
SpreadsheetConceptual graphDataflowProgramming languageInterface (computing)Well-formed formulaGraph (mathematics)Computer programmingCellular automatonIntegrated development environmentEntire functionPhysical systemGrass (card game)Computer programVisualization (computer graphics)Computer scienceGraphische ProgrammierungDigital photography
06:32
DataflowPhysical systemProgramming paradigmNeuroinformatikAxiom of choiceComputer scienceProgrammer (hardware)Computer programmingUniform resource locatorArithmetic meanMeeting/Interview
07:03
Individuelle DatenverarbeitungArchitectureType theoryComputer programSystem programmingMacro (computer science)Time domainGame theoryGastropod shellScripting languageMultiplicationGraphics softwareSpreadsheetVideoconferencingCore dumpCoprocessorHausdorff dimensionAsynchronous Transfer ModeTypprüfungInformationDataflowVisual systemTable (information)IterationData Encryption StandardSeries (mathematics)Observational studyIntegrated development environmentComputer programmingMultiplication signType theoryTask (computing)Core dumpProcess (computing)Programmer (hardware)Functional (mathematics)Programming languageScripting languageCartesian coordinate systemArithmetic meanComputer programDomain nameMorley's categoricity theoremProjective plane2 (number)QuicksortResultantCalculusFocus (optics)High-level programming languageObject (grammar)Software developerState of matterWritingSelf-organizationMusical ensembleDimensional analysisAxiom of choiceInterface (computing)CASE <Informatik>Level (video gaming)Expert systemMeeting/Interview
09:26
Pure Data <Programmiersprache>Time domainAsynchronous Transfer ModeData modelData typeoutputDataflowLevel (video gaming)Pairwise comparisonTable (information)Imperative programmingIterationAxiom of choiceCASE <Informatik>PrototypeSeries (mathematics)Fluid staticsComputer configurationProgramming languageCartesian coordinate systemGraph (mathematics)DataflowIterationObservational studyPattern languageFunctional (mathematics)Dimensional analysisInternet forumOrder (biology)Semantics (computer science)Grass (card game)Meeting/Interview
10:08
Programming languageGastropod shellSemantics (computer science)User interfaceForm (programming)Cartesian coordinate systemProgramming paradigmEmulatorRadical (chemistry)Programmer (hardware)Interface (computing)DataflowTouchscreenComputer programmingDefault (computer science)MassComputer programMeeting/Interview
11:13
AverageInterrupt <Informatik>Structural loadLimit (category theory)Electronic mailing listProcess (computing)FrustrationNetwork topologyProgramming paradigmQuicksortRadical (chemistry)Semiconductor memoryDampingRepresentation (politics)Interface (computing)Core dumpDataflowOrbitIntegrated development environmentUsabilitySeries (mathematics)
11:47
GEDCOMProgrammer (hardware)SpreadsheetComputer-assisted translationPhysical systemIntegrated development environmentVideo cardDataflowAsynchronous Transfer ModeEquals signKeyboard shortcutFunctional (mathematics)Representation (politics)PrototypeImplementationElectronic visual displayCartesian coordinate systemDemo (music)Radical (chemistry)Computer filePlug-in (computing)AdditionInterface (computing)Gastropod shellArithmetic meanCountingLimit (category theory)Type theoryLine (geometry)Mobile appDifferent (Kate Ryan album)Projective planeGreatest elementGame theoryCore dumpCellular automatonMultiplicationModule (mathematics)INTEGRALPower (physics)Ocean currentUniform resource locatorEndliche ModelltheorieUser interfaceBlogPressureComputer programmingMoment (mathematics)Programming languagePRINCE2MereologyComputer animation
14:43
GEDCOMType theoryPerformance appraisalTouchscreenGastropod shelloutputLine (geometry)Cellular automatonWordCountingBitRule of inferenceIntegrated development environmentRepetitionIndependence (probability theory)Interactive televisionModule (mathematics)Game controllerDirectory serviceDemo (music)Limit (category theory)Computer animation
15:22
Integrated development environmentLimit (category theory)BitDirectory serviceGastropod shellSuite (music)Physical systemComputer programmingComputer-assisted translationDataflowMechanism designBuildingResultantMedical imagingComputer animation
15:57
ResultantMedical imagingSinc functionProper mapCellular automatonWordElectronic visual displayParameter (computer programming)Computer fileGastropod shellBitSpreadsheetCartesian coordinate systemAsynchronous Transfer ModeNumberIntegrated development environmentTelecommunicationWell-formed formulaPropagatorComputer architectureProgramming languageLine (geometry)Direction (geometry)Wave packetDataflowDemo (music)IdentifiabilityComputer animation
17:46
Data managementProcess (computing)Plug-in (computing)Order (biology)Object (grammar)Computer programmingDemo (music)Integrated development environmentParity (mathematics)Interface (computing)Direction (geometry)Projective planeExtension (kinesiology)SpreadsheetRadical (chemistry)Endliche ModelltheorieVisualization (computer graphics)WritingScripting languageSurfaceWaveLie groupLine (geometry)Level (video gaming)PrototypeRight angleError message1 (number)QuicksortPressureSystem callArithmetic meanRow (database)Cellular automatonMultiplication signArmAsynchronous Transfer ModeFigurate numberTrailComputer programContent (media)Numbering schemeObservational studyComputer fileModule (mathematics)WordHypothesisDataflowPhysical systemChannel capacityText editorMeeting/InterviewComputer animation
23:31
DataflowPower (physics)Limit (category theory)QuicksortLine (geometry)Integrated development environmentCartesian coordinate systemMultiplication signGastropod shellMobile appMultimediaCellular automatonAsynchronous Transfer ModeNumberSummierbarkeitTouchscreenVideo gameComputer programmingProgramming languageSoftware developerPrototypeLevel (video gaming)ProgrammschleifeRight angleWindowSpreadsheetGraph (mathematics)Point (geometry)Gateway (telecommunications)Interface (computing)Interpreter (computing)FreewareNumbering schemePlug-in (computing)Computer programSoftwareConnectivity (graph theory)Branch (computer science)Text editorScripting languageVisualization (computer graphics)Local ringRaw image formatCrash (computing)ResultantWide area networkMaxima and minimaWordUniform resource locatorMeeting/Interview
28:55
Structural equation modelingMeeting/InterviewComputer animation
Transcript: English(auto-generated)
00:06
Hi, my name is Hisham, and this talk is called Adventures in Dataflow. We're going to be talking about dataflow programming in the context of end-user programming. That is, programming done by people who we don't normally consider to be programmers, but who are programmers nonetheless, as we will see.
00:23
So let me start by quickly introducing myself. I'm a free software developer, I have been for a long time. I have created several projects, so depending on the community you may know me for different things. I've been very active for many years in the Lua community, and I'm the creator and maintainer of luarocks, the Lua package manager.
00:41
I have also created Teal, which is a statically typed dialect of Lua. But many of you also know me as the creator of HTOP, and yes, people have asked me many times, yes, the H in HTOP stands for Hisham. Well, and since not everything in life is about coding, well, here are my cats, Ada and Pascal. Yes, programming references again.
01:01
And this is the music that I made, if you're interested in indie rock, please check it out. But for the topic of this presentation, I think what's most relevant to mention is that I have a PhD in Computer Science from Pukuriu, and the topic of the thesis is data flow semantics for end-user programmable applications. The thesis itself deals with the theory, but the question that I'm most interested in practice is,
01:24
how can we democratize computing? I understand that this is a very open-ended question, so I want to narrow down the focus here and specify that I'm not talking about access, about access to actual computing devices, because this has been spreading, we all know smartphones are computers and all that,
01:41
but really talk about the power, about what can we do with those things, about being active producers versus being passive consumers. So to bring the point across, again, it's not a question of access, but a question of power. And when we talk about our relationship with computing, those of us who are of a certain age, we do remember that users used to have that power of being active producers rather than passive consumers.
02:04
So this is one of the things that fuels that deep nostalgia for the 8-bit era of computers like the Apple II, Commodore 64, BBC Micro and all of that, because that entailed a sense of ownership and power towards the machine that users have since lost.
02:20
And most importantly, this has produced a divide between end-users and programmers. And it's very unfortunate because we as programmers still have that ownership and power, right? We feel that we own the machine, especially in free software, and we also feel that if we need to change something, we can. And if we want to automate something, we can do a quick shell script and all of that, right?
02:41
And so it's a very different relationship that we have towards our machines. And even if we look at our relatives and people close to us and people who use computers merely and use their phones, and they have a completely different relationship with their machines. So we mostly took away that power from users as we made interfaces simpler
03:00
and as we as an industry locked down things and all of that. But the key word here is mostly. We haven't removed all the power from users because if you look closely, you will realize that end-user programming is a reality. There is a number of programs in which users actually have computational power at their disposal. And they can actually do things that were not originally planned by the application.
03:25
And they have the feeling that they can come up with something new as they use the application. And this is seen in all sorts of fields. Not only with more obvious things like engineering, but also in the arts and music and all of that. If you look closely, there are many examples of applications that are themselves programmable
03:43
and their users are really programming even if they don't realize it. But that is not the default. That's not the way that using computing devices is understood nowadays. Unlike in the 8-bit era in which you would turn on a computer and the first thing you would see would be basic and users would be simply driven towards it. I've seen that change happen
04:01
and I've seen people who were able to actually do simple programming tasks in an 8-bit computer as the years went by and they became passive users of modern machines. They simply lost that ability. And now they have a very different relationship with their computing devices. So how can we bring that back in a way that makes sense to computing nowadays?
04:22
Well, in my PhD studies, I have looked for success stories. I searched around for programmable environments that users love. That when I talk to their users, I would see that they would essentially live inside those applications. In the same way that, for example, Emacs users essentially live inside their applications. So we've seen a number of examples of programs like that
04:42
and we've seen the screenshots and here are some of their names. But the question is, if you look under the hood, what do they have in common? They are all based on Dataflow. So what is Dataflow? It's essentially programming via a graph of data dependencies. In computer science terms, that's essentially understanding a program as a series of functional applications and the specification of a program as the connections between those functions, their inputs and outputs.
05:04
So you might look at that and say, well, that's functional programming. And well, essentially that is. Well, but don't get too excited yet because when we're talking about end-user programming, one important distinction is that we usually normally don't talk about higher-order functions, which is the staple of functional programming.
05:20
So that's essentially first-order functional programming. So to get around that whole discussion, let's just call it declarative programming, okay? What's most important here is to make that distinction between declarative programming, which is something that users really pick up very intuitively, and imperative programming, which actually takes some teaching. One thing that's important to point out is that Dataflow is really about the conceptual graph
05:43
and not specifically that you have to have a visual language. For example, the spreadsheet cells that you see here correspond to the Dataflow graph that you see below. And as you can see, even the textual language of spreadsheet formulas expands to a Dataflow graph. And this example also helps to dispel some myths about end-user programming.
06:01
For example, that Dataflow environments are always visual programming, they're not. Some of them are, for example, nodes in Blender, but a spreadsheet is also a Dataflow graph. And another myth is that users are afraid of text interfaces and essentially the language of Excel and other spreadsheets, it's entirely textual and it has over 500 million users worldwide.
06:22
So you could say that Excel is the most used programming language in the world by far. And it's pretty wild to think that actually the programming language with the most users is a declarative one. So how and why do these Dataflow systems work? This is a two-sided question and the answers are related. If we look at it from the side of the how, how do these Dataflow systems work?
06:42
We really talk about, as computer scientists, as programmers, we really want to understand what's going on under the hood, what's the computer science around them. And if we look at why do these Dataflow systems work, what I mean is, why do they end up working well for users? Why is this the programming model of choice of successful end-user programmable applications?
07:03
As I set out to do my research to try to answer those questions, I came across this book by Bonnie Nardi called A Small Matter of Programming, which was published in the 90s, in which she did a series of user studies to try to understand end-user programming and how did people relate to programmable environments. The results were very interesting.
07:20
She identified three types of people who end up being related to the task of programming. The first type would be the end-users. In an end-user programmable environment, they will program, but they will be mostly in focus at the task at hand. They just want to get the job done. For example, if they're a geologist or a musician, they really care about the geology or the music, not about the program.
07:42
The program is really a means to an end. That doesn't mean that they are not advanced users. They're really experts in their fields. It just means that they don't really care about the program. They don't really want to spend the time thinking about programming. They want to spend time thinking about their domain, about the project that they have at hand.
08:00
I speculate that this is also why those end-user programming environments don't really have higher-order functions. It's not as much that the users cannot handle them. It's really that they want to be focused on the objects of their domain, not only the programs themselves. So they don't really want to write functions that deal with other functions. They want to specify behaviors related to objects of their domain of expertise.
08:21
The second type would be some sort of enthusiasts, people who end up enjoying programming itself, but they come from the background of the task at hand. Those would be the geologists and accountants or musicians or whatever who would end up taking some joy from the actual programming side of the thing and they would naturally dive deeper into the programming aspect of things.
08:42
They will take advantage of more advanced functionality that the programmable environment offers, such as scripting. And finally, it will have professional programmers. Those will typically be the core application developers. Amazingly, as I started to research end-user programmable applications, I started to notice that all of them shared that three-layer design that matched those three personas.
09:02
You will essentially have a very high-level language for end-user programmers, a scripting layer in the middle, and then a core application that's developed by the professional programmers. In my research, I employed a classification of dataful language that can be applied towards those end-user programmable applications so we can compare those languages that are described by their interfaces.
09:22
And I also extended it with a few more categorizations of my own. And then I performed a series of case studies comparing all those applications across those various dimensions. It was remarkable how many of those choices were consistent across those successful applications. And the other options for design choices that were used, for example,
09:40
in academic prototypes and things like that really did not catch on. So clearly, there are some patterns that are more conducive to successful dataflow design for end-user applications. As examples of common designs, well, all of them offer some kind of iteration. All of them use unidirectional dataflow. None of them have higher-order functions.
10:00
And almost all of them use a static graph for dataflow. And all of them have a scripting layer. And amusingly enough, all of the languages are imperative. So once we understand how the semantics of a dataflow language that's powering an end-user programmable application should behave, and I'm not going to get into the details of that semantics here. It's all in my thesis if you're curious.
10:21
We can start asking ourselves a question. What would it look like? What would it feel like to have a default user interface that would be based on those principles so that we could have a dataflow paradigm underlying the applications and we could combine them and have data flowing around and come up with creative things? So I would really like to see the answer to that question.
10:41
But before trying to solve any kind of problem of finding the solution for programming for the masses, I realized that actually I would like to see that solved for myself. I realized that even us, even we programmers, we need something better than what we currently use as interface for our programs. Yes, we do have shells that have pipes which are the most basic form of dataflow.
11:02
But essentially, we're still on clunky tools. We're held back by legacy. So really, is a screen full of terminal emulators emulating devices from decades ago really the best that we can do nowadays? I've always been the kind of person who gets annoyed by this sort of arbitrary limitations. And even like 15 years or so ago when I started HTOP,
11:21
that was out of my frustration with TOP, in which back in the day it did not allow you to scroll through the list of processes, did not give you a visual representation of your memory or anything like that. So HTOP was back then the best that I could do and even that was limited by the paradigm of the terminal trying to draw trees of processes with ASCII art and whatnot.
11:41
So I told myself, well, what do I have to lose? Let's try to rethink the interface from scratch. And that's when I came up with Userland. So Userland is an integrated dataflow environment which is inspired by the common core of dataflow apps. You can think of it as a shell for multiple types of applications. Each application is essentially implemented as a plugin towards the main app
12:00
and everything should integrate seamlessly. The current status of the project is that I have a prototype written in Lua that uses the Love2D graphics engine which is actually a game engine, but worked really well for showcasing the ideas behind the interface. I'm currently writing the core application in C using STL for graphics and of course the idea is to eventually add a scripting layer
12:21
and add support for plugins and additional applications written on top that can be written in any language. So, let me show you a demo I prepared a while ago using the prototype. I think it's a good representation of the ideas put in practice. Userland is a programmable end-user environment based on dataflow. At first glance it works just like
12:41
the quintessential end-user dataflow application, a spreadsheet. In fact, cells, formulas, references work just like one would expect. A difference from a typical spreadsheet though is that cells are created on demand. But otherwise their behavior is pretty normal. But Userland is not a spreadsheet,
13:01
or at least not just a spreadsheet. The spreadsheet functionality was loaded as a module and in fact was activated when we first entered a cell with an equal sign. We can switch out of the spreadsheet mode by pressing a key combination and then enter a different mode, shell. The shell mode implements an actual Unix shell.
13:21
The current implementation forks commands off to bash so you have the full power of bash scripting available. However, just because we are using a Unix shell it doesn't mean we have to be constrained by the limitations of a Unix terminal. As we see here, launching a long-lived command does not prevent us from continuing to interact with the system.
13:42
We can move up, edit and relaunch commands while other cells are still running. The user can choose between adding more commands at the bottom like a regular terminal would do or just replace a command with something else. Notice how this implementation of cat displays the file with syntax highlighting.
14:01
This is because this is not the system's cat but rather a module implemented in Userland. The idea is to gradually extend the capabilities of the shell with functionality that can make use of the enhanced environment. As we can see, running internal commands implemented via scripting
14:21
is indistinguishable from running external commands from the system. Here we replaced cat with tac which is a binary from the system that prints a file backwards. Let's switch back to cat now and let's try something different. Let's build a pipeline. We'll pipe together cat, tac and wc, the count lines
14:43
and voila! Each bit of the pipeline is now its own cell. It can be manipulated independently and it can also be edited and triggered independently. So let's modify the wc invocation and change it from counting lines to counting characters.
15:01
Execution and evaluation are triggered according to dataflow rules. Let's edit the command in the middle of the pipeline changing it from tac to grep. Grep filtered the input looking for occurrences of the word type and the count of characters was also updated. We can freely mix interaction styles. Here I move to a cell with the mouse
15:20
and then I press Ctrl-L to clear the screen in typical shell fashion. For the next bit of the demo, let's switch to the home directory. And as I'm sure it would be expected from a shell environment that frees itself from the limitations of character graphics Userland does support graphics. Here we are seeing the show command which was implemented as a built-in in Userland's shell module.
15:42
The built-in was implemented in such a way as to integrate with the dataflow mechanics of the system. Let's build a pipeline that begins with our built-in cat. Which feeds data into the external program convert from the ImageMagick suite and then finally goes into our built-in show. Here's the result of our pipeline.
16:00
Our show command at the end displays the converted image. The cell in the middle running convert has fed the proper data into show but since Userland doesn't know anything about convert it just showed the data as text. We can use the built-in keyword quiet to get rid of that. Just like we did with our text pipeline we can play with the arguments and see instant results.
16:25
For the last bit of the demo let's integrate all that we have seen so far. By pressing a key I can reset any cell and switch it back to spreadsheet mode. So let's create a couple of cells and then add a formula. Just like the dataflow relationships in spreadsheet cells
16:42
are declared via their textual language the same thing is possible in shell cells as well. Here we're going to use a spreadsheet cell identifier adjusted to the shell syntax of course to control the argument for this shell invocation. Userland has a single unified dataflow engine so the spreadsheet cells and the shell cells
17:01
can integrate seamlessly. The architecture is extensible so that new modes can also be created. To wrap up the demo let's switch back to shell mode and demonstrate the communication in the opposite direction. So let's begin by displaying a text file and then extending that into a pipeline
17:23
that counts the number of lines. That conveniently produces a numeric value which we can then use in our spreadsheet formula which will then propagate to the pipeline above. And that is all for today's demo. This is Userland, an integrated dataflow environment that allows different applications to be constructed
17:41
and that will hopefully allow users to combine them in creative ways. Well, I hope you enjoy that and thank you for watching. If everything is going well with the conference streaming I should be available now live for the Q&A session. See you there!
18:45
Okay, so there's one here saying like I was just about to ask if you could use spreadsheet cells in other modes and yep, yes, this is possible. One thing I have done in the extension of the prototype was adding a third mode already, that's synthesizer.
19:03
So that was a fun thing too, so you can do calculations and feed them into changing the waves and playing with all of that. The main idea is that really you should be able for any additional mode that you add I'm calling them plugins right now because I've asked non-professional programmers
19:23
what kind of terminology they would more naturally understand. I basically asked if people like how do you understand the word plugin and they basically describe what a plugin is and then I figure out, okay, non-programmers know what plugins are and I was originally calling them modules and module was completely like programmer speak to them
19:43
with no meaning, so I'm calling them plugins from now on. So the idea is that when you add a new plugin you can get data in and out of from any plugin to any other plugin. Let's see here, let's see something else.
20:01
Okay, a question. As someone who's a long-time user of Macs, PD, and TD the biggest issue is that you end up writing as much C as you do PD. In some way they become interface layers over C and the SDK is almost quite convoluted unlike scheme FFIs which are usually very easy. In fact, once you use those environments professionally you start extending their capacities in C in order to interface with objects written in C.
20:21
Do you plan to address this extensibility in a thorough manner and how would you go about making this process seamless if so? Yeah, so that was one of the findings of the thesis is that a successful environment like that and I make this distinction of successful environments because in the academia there were studies
20:41
of visual environments and data flow environments and many of them used very different designs but when I looked at the ones that were industrially successful or successful as you see like Blender, Labviolex, all those kinds of things they tended to have very similar designs
21:01
and I figured that if all of those successful ones have similar designs well they must be doing something right. So one thing is that to address the question like the most successful ones they generally like they always have a middle layer which is a scripting layer which is like an easy to learn programming environment
21:22
for like more heavy duty in programming than the one that you get in like with the basic interface but not as heavy as like going all the way down to C and those kind of things that require toolchains and all of that. So I think the answer to that question is that having a middle layer with scripting
21:43
is just as important as having an upper layer with data flow based and user programming. So and let's see another question like when will the rewrite be available? I'm thinking about getting future parity
22:02
with the demo first. So and so this is something that I have in mind. This is my goal. Yeah hopefully sometime this year. Another question do you think Jupyter could be used as an end user programming system or does that require too much knowledge?
22:22
That's an interesting one because Jupyter is essentially a data flow environment if you look at the cells like that but then like the contents of every cell is generally always scripting. So yes of sorts if you think of Jupyter as another way
22:40
of looking at a spreadsheet but generally the kind of knowledge that it requires like you almost always already have to know the scripting level right to get the most out of it. But yes I think something like yeah so I think definitely something like Jupyter is in the right direction.
23:02
Okay so Christine says obviously this approach is general but what kinds of projects would you like to see these ideas apply to most directly? So that's why I started with the shell plugin. So at first I would like to apply to my own use
23:21
so the kinds of things like I the kinds of things that I would like to use it myself would be like as a replacement to my terminals as a replacement to my text editor those kinds of things and as a placement to a file manager. So generally like managing your local offline environment and so that's my very selfish like initial goal
23:41
but I could see something like creative programming those sorts of things that you would do with processing and like more multimedia stuff I could see that integrating more easily as well and even like creating visualizations to the other possible plugins and those kinds of like fun stuff.
24:01
So I would probably start from this avenue and then branch out into other kinds of end user applications. So is userland a standalone app or something that runs in the CLI? Well right now the prototype is a love2d Lua program
24:20
and the in the rewrite is a C program with in SDL so yeah so it's a program that you launch and then like you can like go full screen or you can run it from a window. How do you deal with circular dependencies? Yeah in the dataflow graph it's interesting
24:41
in the prototype it crashes and in the rewrite it actually feeds back and loops nicely so right now if you do a circular for example a circular sum in a spreadsheet cells it keeps like increasing so if you do like a1 like 1 and then 2
25:04
and then you change 1 to like a2 plus 1 and a1 plus 1 you see the numbers increasing so it's like a live environment in that sense. Another one, another comment here now that I think about it Emacs isn't a dataflow environment but it does tend to be a gateway into end user programming despite this.
25:22
Would you agree? And if so why do you think that might be? Yeah I think Emacs is definitely a gateway from like a text editor into the scripting layer very similar to what I mentioned like in a comment above that when Christine mentioned that Blender tends to be a gateway towards scripting.
25:41
Generally I would think that well we all know that like Emacs users tend to be Linux users, Unix users, Free Software users like many of them are already programmers so yeah maybe those are programmers who are not used to idea of programming like to end user programming and programming their own applications
26:02
so but I don't usually see like lots of people like from other walks of life like using Emacs casually and then getting into programming through that but you will see like you know artists using pure data and then learning programming or Blender through that right so
26:23
so yes I would agree that Emacs is a gateway towards end user scripting but probably not as much end user programming at that highest level so yeah another comment here
26:42
Max and pure data used similarly to the way Max users use Emacs yes that's very much the point and I've talked to users of all of these other applications and indeed like if you if you look at the way like a power user of Excel uses Excel yeah they really stretch the limits of what's possible in there
27:02
so yeah it's very similar the way they live inside the app and the way they love the app and the way they use it for like things that wasn't originally designed and things like that it's very impressive so another question said so the plugin could be understood as an interpreter component for the data you would like to use is that right
27:21
yes that's right and one thing I would really right now you can kind of sort of do it with the shell mode since you can basically run call-in interpreting in a shell plugin but yes I would like to see plugins that directly implement like directly plug-in interpreters for scripting languages
27:41
so that you know you could have like a snippet of Python or a snippet of Scheme or whatever your favorite language in there and have data flow in and out and you can like connect it via the interface seamlessly another one as the developer of practice live certain bias not having the scripting layer how much do you think API's can get around those layers
28:03
well in my experience looking like studying those successful apps they tend to all have scripting layers and one thing I've noticed is that having the scripting layer makes you avoid the temptation of making your highest level end user
28:20
language too complicated because then you can just you know draw a line in the sand and say okay if you want something more complicated than this then we can move that to the scripting layer so that you can keep the end user level you know welcoming to newcomers and things like that
28:41
it does not require lots of specific programming knowledge because like if you look at it data flow I guess we're running on time so yeah we can continue