Hacker News Reader

Comment by ageofwant | Hacker News Reader

I have this notion that in time, as people's general comfort level interacting with computers and advanced computing platforms like Python become rote. That computer interfaces will be more REPL like, and less application, or GUI like. That the principle of general computing will be applicable at interaction level, not application level, if you will.

Future users may consider today's restrictive GUI interfaces as quaint anachronism of the stupid ages.

View on HN

I strongly disagree with this prediction. That may be true for some lines of work where people have a strong technical background and uses a specific set of applications all the time (such as scientific computing). In all other cases, gui will always win because:

- Non technical people lack the capacity to formalize their goal - many document creators want wysiwyg applications - programming languages are powerful but hard to "discover". People don't want to read the docs for something they will use once in a while

'Future people' will all be 'technically strong' by today's standards at least. They will expect their tools to be powerful and have a whole childhood to familiarize and internalise concepts and paradigms. Pointy clicky is not going to cut it, not for anything worth doing. Of course there will be toys, of which I enjoy many, I'm not talking about those.

The only intuitive interface is the nipple, everything else is learned. It also seems you got stuck on the notion that 'programming languages' are hard. That does not need to be the case, not for native talkers. And REPL and 'wysiwyg' are certainly not mutually exclusive things, http://nbviewer.jupyter.org/url/jakevdp.github.com/downloads... that seems pretty what you see is what you get to me.

I wonder where you get that prediction from. We've came from windows GUIs over single apps on mobile phones to "just tell the machine what you want". The development goes further away from consoles and "typing" of any kind.

Consumers want GUIs. Show and don't tell is the way it goes.

I believe that in order to grow strong enough programming skills, one has to have strong enough analytical skills. Those can also be learned but are much more of a personality trait.

As for notebook being wysiwyg, I also disagree. That would be like having a markup editor with a rendering window. Document creator like the "painting/sculptor" metaphor, where they interact directly with their creation. Want to modify a part of a document? click on it.

I think there's a happy middle ground between extensibility/flexibility and simplicity. You can use a GUI for simpler stuff while still allowing code for the complex stuff.

In moviepy's case I wouldn't use python to do describe simple video transformations as shown above, I'd use YAML. Unlike python, it's something that you can build by hand, can easily get a GUI or script to output and if you put it in version control you'll get readable diffs.

At the same time if you made every "video project" include the source media, the YAML file describing transformations used to build the output and by default include a stub 'plugin' python file, you could reduce the friction between people with coding skills seeing the need for an ad hoc custom transformation and creating it.

While I never used it, it sounds like HyperCard actually did achieve both goals: Ease of use for non-technical users, and wysiwyg GUI design + use.

We used to have pretty small, simple languages in the past that were very effective in driving a simple text-based or stock-UI-component interface. These simple languages aren't difficult for people to be introduced to, preferably by accessible examples & demonstrations, and do just enough to be practical for common uses.

It's a nice thought but we aren't heading in that direction. The young are almost exclusively brought up on swipe interfaces. The future is likely to be a dystopia of idiot proof GUIs or even worse voice control.

True, but those interfaces are built by adults still stuck in the old paradigm. Kids have astonishing familiarity with tables and phones. The notion that interfaces need to be dumbed down because users are 'stupid' might be true today, but that won't be the case for those raised with smartphones.

2007 was 11 years ago, in 10 years those iPhone reared people will enter the workplace. They will have instincts you and I do not. I suspect it will push general computing interface design to the 'power user' side.

A lot has been written on the “digital native” (people growing up with technology being good with technology). I encourage you to look it up.

As computer savvy people, I think we imagine how much better we could have been with more opportunity. It seems like the prevailing opinion is that the digital native is a myth and that just having technology doesn’t make the next generations experts in it.

Kids have strong familiarity with swipe UIs and iPhone games. This won't make them switch to programming-based UIs any more than growing up with a TV turned one into an electrician. In fact, the opposite is likely to be true - the more "magical" and abstracted away the UI is from the underlying technology - the less likely it is that its users will develop any intuitive understanding of what lies beneath.

We were going that route, and then I'd say Windows' and Mac's market acceptance proved otherwise.

I think the argument might there for interfaces to scale more fluidly from GUI to text (e.g. every GUI command is text mapped and shows you). But the on ramp to text is too difficult for new users...

Many professional tools have a strong GUI/Engine separation, AutoCAD famously used Lisp, and one could see and modify commands that were being dumped into the application REPL in real time.

Many applications on the Amiga had an ARexx Port that allowed scripts to drive all the same actions as the user.

http://docs.autodesk.com/ACDMAC/2013/ENU/PDFs/acdmac_2013_au...

http://www.pjhutchison.org/tutorial/arexx.html

Good point, but I tend to believe that no one kind of user interface can ever be complete, so the best kinds of programs will support multiple interfaces that can be used with people with varying levels of skills and familiarity, to accomplish the program's tasks. Point and click GUIs will always have their place for those who have very little or no familiarity with software concepts.

Nonsense. Point and click is useful for anyone who uses a tool infrequently and wants to make progress without resorting to a manual. Honestly the average app is not so complex its fundamentals cannot be represented as point-and-click. Its partly ego that keeps people on command lines. As expressed in that comment, which has a vibe of chest-beating.

If a task seems straightforward I will likely apply my past experiences with any similar task, and skip any provided manual until I become unsure or hit an obstacle. This is how normal people approach computing devices.

This is more or less the ongoing wider state of 3D software. There’s a pile of exceptions to every rule around each corner. If anything, coding has become less important as better software design evolves.

I highly doubt this would be the case. Well designed GUI's makes learning software significantly easier than without GUIs.

Just imagine going to a chemical plant that makes fertilizer. Now imagine you have an operator that stares at 5 or 6 screens showing each IO process for making said paper. From the drying process, to the chemical rxns, heat, temp, water, pressure ,etc. Its a complex system to understand, and GUI's make it easier to break down.

Take away the GUI and throw in all python REPL and CLI. Things will go to shit so fast. Plants will shut down. Operators will need to be retrained and paid more to understand the inner workings of what the GUI was doing.

Thats not to say that CLI and REPL are necessarily worst than their GUI counterpart. A good example where CLI and REPL are significantlly better than its GUI counterpart outside of programming would be AutoCAD (AutoDesk). Any competent architect uses a list of well known shortcut hotkey commands, through its CLI. Such as "M" for move an object, "O" for offseting a line. It takes way longer to use a GUI to do this.

Arguably, some common GUI interfaces for programming like GIT makes it much easier to do things, like branch off, rebase, merge, and pull. I personally prefer Atom's built in GUI, or even a possible stand-alone, as I simply cannot remember every GIT command when I need too. Just the most common ones.

Lastly, windows/mac VS Linux. Its thanks to the GUI-based systems in windows/mac that make it much more popular and appealing to programmers and nonprogrammers a like, for focusing on things that actually matter (Business functions, persona life, etc).

We may be trading todays restrictive GUI's for badly documented application API's...

Actually thinking about fairly advanced non developer applications. Mapping/GIS work is a lot like what you describe. GUI tooling with tool boxes of little functions that you can chain together to get the desired outcome.

Though its incredibly complex when you get the advanced use cases, it becomes not dissimilar to regular software development.

How much video/audio editing have you done?

I think about this from time to time, it's sort of the difference between using the computer and using an application.

The main issue with this is discoverability.

How would anyone know what commands are supported?

I don't agree with 'ageofwant’s prediction (though I really wish that I could), but command discovery is a solved problem:

Pharo Smalltalk has a nifty feature whereby you can find methods by example[1].

E.g. typing

    'hello, world', 'HELLO, WORLD'

in the finder returns the method `asUppercase` on the String class.

In a statically-typed language, you can just search by function signature (e.g. Clip -> RotatedClip (an effect) or Clip -> Time -> Clip * Clip (a cut)).

[1] https://www.youtube.com/watch?v=HOuZyOKa91o&app=desktop&t=30...

Python tab completion does wonders. I know when I was messing around with blender it worked really well when I didn't want to read the code (or figure out what was missing from the API for patches).

Not too sure the "artist types" will ever get very comfortable with the command line but they can usually describe what they need well enough for a techie to code up what they need given a good enough API.

Reply on news.ycombinator.com