Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi Steve, excellent feedback as always :) On Wed, May 27, 2015 at 4:41 PM, Steve Litt wrote: > On Wed, 27 May 2015 14:27:17 -0400 > Jude Nelson wrote: > > > > I've been thinking about the general form of this problem (and a > > general solution) for months, and I think I'm almost ready to provide > > a formal design document. > > > > [The Problem] > > Many programs couple the business logic to the presentation logic. > > The code that drives the UI is too intermingled with the code that > > provides the application's core functionality to use them separately, > > or develop on them independently. > > Hi Jude, > > Be careful what you wish for. MVC was created to solve this problem, > and it looks to me like, in the hands of most developers, like MVC > makes an unfathomable Easter Egg Hunt where a reasonably simple > algorithm can't go six lines without the need to go look something up > somewhere else. And yet, in the hands of most practitioners, my > observation is they *still* manage to intersperse program logic, data > and UI. > > Separation is good, but not all ideas for separation are good. > Yeah, MVC can get out of hand if used improperly. However, that's can be because sometimes MVC isn't the right factoring in the first place, but (for Web applications in particular) a lot of development frameworks force developers to try to shoehorn their applications into it nevertheless. I should point out, I don't see shui as an MVC-like framework. I see shui as way to compose unrelated individual programs that each implement a single UI element to create complex graphical applications, in the same spirit as using the shell to compose unrelated individual programs that each implement a data stream filter to create a pipeline that accomplishes a complex data transformation. I'd use the shell with zenity to accomplish what I'm proposing with shui, except that I additionally want to expose the structure of the UI as a first-class aspect of the application as well. This is because I want to let the user arrange the UI elements of an application however they see fit without having to touch any code (i.e. they can create and preserve whatever workflow they want irrespective of the developer's intentions), and I want the user to be free to borrow UI elements from one application and put them in others (i.e. we can never lose features; only disable them). > > [clip] > > > [Motivation] > > I was watching my SO create a (long) Powerpoint presentation the > > other day, and she wanted to add a "fade in" animation to each bullet > > point on each slide. Powerpoint (and every office suite I'm familiar > > with) makes you do this by hand, bullet-point by bullet-point, with a > > mouse. The UNIX hacker in me saw this, and wondered why it's not > > possible to simply open a shell and run something like "for > > ppt_bullet in $(ppt-ls "bullets"); do ppt-animate "fade-in" > > "$ppt_bullet"; done". This would have saved an hour of tedious, > > repetitive effort. > > > > The reason this isn't possible is because Powerpoint (and every other > > office suite) does not offer a command-oriented UI. What could > > Powerpoint have done? One option is to add a program-specific > > command-language (like how vim and emacs do). However, I don't think > > this the answer either, for two reasons: > > (1) The UI (the command-language in this case) is still tightly > > coupled to the program, and has rules and semantics that are only > > applicable to the program. > > I think #1 above is a *good* thing. There's a reason it's called a > *domain* specific language. It's the functions of this program's > "business logic", and nothing more. > > Yes, domain-specific languages have their place. However, all Turing-complete languages are equivalently powerful. So, there had better be a compelling reason to spend time designing a domain-specific language that you then expect users to go learn just to use your program properly, as opposed to embedding support for a more general language that the user already knows (or can easily learn through 3rd party resources) and shipping a library for that language that exposes your domain-specific functionality. It's a bit of digression, but the point I'm arguing is that unless the programming paradigm itself is so specific to your problem domain that you need a whole new programming language to describe its system of logical axioms (this is rarely the case), I think developers and users are better off with the latter option since it doesn't re-invent the wheel and doesn't waste the user's time. For example, I'd do my best to design shui so that it only ever needs to communicate with the subprocesses it runs via environment variables, exit codes, signals, and pipes, thereby giving users a wide selection of languages for programming applications. > > > (2) Without careful design, the user can't bring to bear existing > > knowledge or existing tools to address problems. This is a general > >
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi Hendrik, On Wed, May 27, 2015 at 12:35 PM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 02:27:17PM -0400, Jude Nelson wrote: > > Hi Hendrik, > > > ... (much snipped) (I'm sorry, I hadn't meant to take you away from > vdev for the amount of time it took to write this lengthy and > interesting reply) > > > > > An interesting consequence of structuring applications this way is that > you > > can trivially solve both network transparency and application > distribution: > > simply put the application on an NFS mount (or some network filesystem), > > and run the interpreter on the local client. The application stores > > runtime state as files within its directory hierarchy, so they get > > automatically written to the NFS server. Users could run remote > > applications locally simply by mounting the remote volume and running the > > interpreter on them in-place. > > > > > I was considering building such an interpreter as well as and a suite of > > applications for Devuan at some point, after finishing vdev. I was > > thinking of calling it "shui"--both from the concept of "feng shui" (the > > idea of harmonizing everyone with their environment), as well as serving > as > > an acronym for "SHell-oriented User Interface". > > Sounds interesting. But for applications like ordinary text editing, > it might become a little slow if you end up running a shell script > with every character typed. The idea did seem to work somewhat for > the ancient mail handler MH (if I recall correctly). > > But as for the file system ... I wonder if the completely virtual file > system in something like Inferno could help things along -- put more > of the primitive operations into the file itself. Or have I > misunderstood Inferno? > > Of course, taking this to its logical conclusion would move the > file system rather seriously in the direction of a typed persistent > objects system, with methods and so forth. A very different beast > from what we're used to. > These are excellent points. I should clarify, shui itself would be designed as an aggregate of programmable widgets. Each one would know how to render itself, and how to interpret a particular directory and run its scripts. One such widget would be a text area with the capabilities you originally described. The value shui provides is that it would make it very easy for users to swap out parts of the text editor they didn't want, or mix and match components without having to become developers and without having to re-compile the application. I don't think we'd need a typed persistent object system at the end of the day, since unless all application developers agreed to it, there wouldn't be a unified type system in the first place. Flat files of bytes should be just fine for the purpose of developing applications--if the application needs an advanced type system, it can implement it itself. -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
On Wed, 27 May 2015 14:27:17 -0400 Jude Nelson wrote: > I've been thinking about the general form of this problem (and a > general solution) for months, and I think I'm almost ready to provide > a formal design document. > > [The Problem] > Many programs couple the business logic to the presentation logic. > The code that drives the UI is too intermingled with the code that > provides the application's core functionality to use them separately, > or develop on them independently. Hi Jude, Be careful what you wish for. MVC was created to solve this problem, and it looks to me like, in the hands of most developers, like MVC makes an unfathomable Easter Egg Hunt where a reasonably simple algorithm can't go six lines without the need to go look something up somewhere else. And yet, in the hands of most practitioners, my observation is they *still* manage to intersperse program logic, data and UI. Separation is good, but not all ideas for separation are good. [clip] > [Motivation] > I was watching my SO create a (long) Powerpoint presentation the > other day, and she wanted to add a "fade in" animation to each bullet > point on each slide. Powerpoint (and every office suite I'm familiar > with) makes you do this by hand, bullet-point by bullet-point, with a > mouse. The UNIX hacker in me saw this, and wondered why it's not > possible to simply open a shell and run something like "for > ppt_bullet in $(ppt-ls "bullets"); do ppt-animate "fade-in" > "$ppt_bullet"; done". This would have saved an hour of tedious, > repetitive effort. > > The reason this isn't possible is because Powerpoint (and every other > office suite) does not offer a command-oriented UI. What could > Powerpoint have done? One option is to add a program-specific > command-language (like how vim and emacs do). However, I don't think > this the answer either, for two reasons: > (1) The UI (the command-language in this case) is still tightly > coupled to the program, and has rules and semantics that are only > applicable to the program. I think #1 above is a *good* thing. There's a reason it's called a *domain* specific language. It's the functions of this program's "business logic", and nothing more. > (2) Without careful design, the user can't bring to bear existing > knowledge or existing tools to address problems. This is a general > gripe I have against vim and emacs too--if you're going to offer a > Turing-complete command language, why not offer one that is > widely-used already and lets people use external tools? That's just it. I think packaging a Turning-complete language is overkill, much the same as having the init system take charge of login logic. I'm an elder in the Church of the Parsimoneous Scope. I'd prefer to expose every business logic function, such that it's callable from the command prompt and other places. Those functions are the thin interface connecting business logic and appearance. There's nothing Turing complete about them. If you want Turing completedness, that's for the program Years ago GoLUG's Gary Miller told me something I never forgot. When writing a program, he makes his entire user interface as input and output to a socket. That way, on his side of the socket, there's no need for Python-Tk, nor Curses, nor GTk nor tk nor HTML generation nor mod-apache-whatever: None of that complication. Nothing but business logic algorithms and the functions that implement them. Write it in simple, no-dependency C, Python, Perl, Ruby, Lua, whatever. Then Gary publicizes the commands that socket takes, so the other guy can write a program with Curses or Python-Tk or whatever, to present the info to the user, as needed. This presentation program has all the GUI molassas, but no business logic, so it's pretty straightforward. And you have complete separation of business logic from presentation, enforced by a socket. But of course, the thing on the far side of the socket can be more than a UI. It can be a script. It can be a program that turns a config file into a script. It can be a command prompt (using telnet) to tweak. You can accomplish almost anything, except adding a function or changing a function's actions on Gary's side of the program. If you want to do that, do it on Gary's side. > > What I would like the most is if Powerpoint were somehow designed so > that its runtime state was exposed to the system shell, so I could > operate on it directly. Powerpoint wouldn't need to ship with its > own custom language, and I could use whatever tools I wanted. I'm pretty sure Gary's method would do just that. [snip] > [Design Notes] > The idea I I'm working on can be thought of as a re-telling of the > SQUEAK story for the UNIX environment: > * The shell is the binding language between different aspects of the > application, as well as between the application and external tools > (this replaces Smalltalk). > * Persistent state is encoded as files As a djb enthusiast, I'm always happy when state is
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
On Wed, May 27, 2015 at 02:27:17PM -0400, Jude Nelson wrote: > Hi Hendrik, > ... (much snipped) (I'm sorry, I hadn't meant to take you away from vdev for the amount of time it took to write this lengthy and interesting reply) > > An interesting consequence of structuring applications this way is that you > can trivially solve both network transparency and application distribution: > simply put the application on an NFS mount (or some network filesystem), > and run the interpreter on the local client. The application stores > runtime state as files within its directory hierarchy, so they get > automatically written to the NFS server. Users could run remote > applications locally simply by mounting the remote volume and running the > interpreter on them in-place. > > I was considering building such an interpreter as well as and a suite of > applications for Devuan at some point, after finishing vdev. I was > thinking of calling it "shui"--both from the concept of "feng shui" (the > idea of harmonizing everyone with their environment), as well as serving as > an acronym for "SHell-oriented User Interface". Sounds interesting. But for applications like ordinary text editing, it might become a little slow if you end up running a shell script with every character typed. The idea did seem to work somewhat for the ancient mail handler MH (if I recall correctly). But as for the file system ... I wonder if the completely virtual file system in something like Inferno could help things along -- put more of the primitive operations into the file itself. Or have I misunderstood Inferno? Of course, taking this to its logical conclusion would move the file system rather seriously in the direction of a typed persistent objects system, with methods and so forth. A very different beast from what we're used to. -- hendrik > > -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi Hendrik, On Wed, May 27, 2015 at 6:12 AM, Hendrik Boom wrote: > On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote: > > > As a rule of thumb, developers should always use the smallest possible > > amount of dependencies for a project, and clearly separate layers - e.g. > > if a project comes with an engine and a GUI, then the engine should come > > as a command-line tool in its own package with no dependencies on > graphical > > stuff, which would be the role of the GUI package. But I'm a dinosaur AND > > a fan of minimalism, so I don't expect many people to think like me. > > I mean this as a serious question, not as a piece of sarcasm, > though it could easily be misconstrued as such. > > I am testing the limits of the advice to separate interaction from > command line, though. Sometimes limit testing leads to discoveries. > > I'm in the process of writing (yet) a(nother) editor and output formatter, > and on reading this, I started to wonder -- just how could one separate > a command-line version from the UI? I can see that the output > formatter can be so separated (and very usefully), but the actual > editing? > > Brainstorming welcome. > I've been thinking about the general form of this problem (and a general solution) for months, and I think I'm almost ready to provide a formal design document. [The Problem] Many programs couple the business logic to the presentation logic. The code that drives the UI is too intermingled with the code that provides the application's core functionality to use them separately, or develop on them independently. However, we would like to be able to do this in order to allow the user to apply existing tools and skills in one domain without affecting the other domain, and allow developers to innovate in one domain without affecting the other. This should be possible, since rendering a UI is usually (but not always) a separate, orthogonal concern from performing the desired functionality. [Motivation] I was watching my SO create a (long) Powerpoint presentation the other day, and she wanted to add a "fade in" animation to each bullet point on each slide. Powerpoint (and every office suite I'm familiar with) makes you do this by hand, bullet-point by bullet-point, with a mouse. The UNIX hacker in me saw this, and wondered why it's not possible to simply open a shell and run something like "for ppt_bullet in $(ppt-ls "bullets"); do ppt-animate "fade-in" "$ppt_bullet"; done". This would have saved an hour of tedious, repetitive effort. The reason this isn't possible is because Powerpoint (and every other office suite) does not offer a command-oriented UI. What could Powerpoint have done? One option is to add a program-specific command-language (like how vim and emacs do). However, I don't think this the answer either, for two reasons: (1) The UI (the command-language in this case) is still tightly coupled to the program, and has rules and semantics that are only applicable to the program. (2) Without careful design, the user can't bring to bear existing knowledge or existing tools to address problems. This is a general gripe I have against vim and emacs too--if you're going to offer a Turing-complete command language, why not offer one that is widely-used already and lets people use external tools? What I would like the most is if Powerpoint were somehow designed so that its runtime state was exposed to the system shell, so I could operate on it directly. Powerpoint wouldn't need to ship with its own custom language, and I could use whatever tools I wanted. [Related Work] This is something that Smalltalk/SQUEAK got right, as well as SecondLife (but to a lesser extent). In these environments, a UI element is fully scriptable by the user, and can access functionality in other UI elements and store persistent state within them. As a user, I can easily add my own functional overlays on top of the application, as well as my own custom UIs that extend the functionality of the application on-the-fly. If Powerpoint were written as a SQUEAK application, I might have been able to write and attach a button on-the-fly that iterated through each bullet point and added an animation. This is something that RESTful Web services sometimes get right as well. The business logic in a RESTful Web service is meant to be decoupled from the CSS/HTML/Javascript UI, so you should be able to use use any HTTP-speaking client to interact with the business logic on the remote servers. For example, this lets Web front-end developers create mash-ups of multiple services, and it lets devops and back-end developers write scripts with curl to interact with services. The downside is that you're limited by the availability and expressiveness of the RESTful API (which you do not control). Applescript, ActiveScript, and nowadays Powershell try to do something like this, but they fall short architecturally in that they can't access and operate on all of the application's
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi, Hendrik. Your post reminds me of a chapter in "The Art of Unix Programming", by Eric Steven Raymond, which I always recommend. http://catb.org/~esr/writings/taoup/ El 2015-05-27 06:12, Hendrik Boom escribió: ... I am testing the limits of the advice to separate interaction from command line, though. Sometimes limit testing leads to discoveries. ... Brainstorming welcome. -- Saludos cordiales, Ángel Ramírez Isea. Usuario de Devuan y Canaima GNU / Linux # 460737. Coordinador General. Cooperativa Simón Rodríguez para el Conocimiento Libre, RS. www.simonrodriguez.org.ve (261) 524.55.93 -:- (426) 369.57.18 J-40294137-4 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
On Wed, May 27, 2015 at 06:12:15AM -0400, Hendrik Boom wrote: > On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote: > > > As a rule of thumb, developers should always use the smallest possible > > amount of dependencies for a project, and clearly separate layers - e.g. > > if a project comes with an engine and a GUI, then the engine should come > > as a command-line tool in its own package with no dependencies on graphical > > stuff, which would be the role of the GUI package. But I'm a dinosaur AND > > a fan of minimalism, so I don't expect many people to think like me. > > I mean this as a serious question, not as a piece of sarcasm, > though it could easily be misconstrued as such. > > I am testing the limits of the advice to separate interaction from > command line, though. Sometimes limit testing leads to discoveries. > > I'm in the process of writing (yet) a(nother) editor and output formatter, > and on reading this, I started to wonder -- just how could one separate > a command-line version from the UI? I can see that the output > formatter can be so separated (and very usefully), but the actual > editing? It's a matter of building an editor like leafpad, or building a vi or an ed. What are you working on? If you're working on the latter, take vim, neovim and vis as examples: they do a lot more than writing in place, save, colorize and undo. Thus, decoupling the engine from the UI means that you have already on draft what does the editor do and how as for example as a list of commands. Then the UI, as a command line client, probably would behave like a shell script, or like ed or ex; as a full blown editor, no matter if curses or GUI, probably would grab commands (through modes or menus) and input, and synchronizes with the engine (which executes special commands, changes files, write to them, and whatever else). If everything is in the same process, this synchronization is mostly done as code execution; otherwise it's developed in a client-server model: the UI shows to the user her/his edits, while passing messages to the engine, for example sending text or msgpack through a socket read by clients (where the user types) and the editor engine. This aids mostly code reuse, because you could have any kind of GUI and the powerful set of commands you feel comfy about for editing text. -- Teodoro Santoni ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
