Engelbart's Violin (2012) | Hacker News Reader

Engelbart's Violin (2012)

loper-os.org

87 pointspmoriarty27 comments

"To my knowledge, no child grows up “playing doctor” and still believes as a teenager (or even as a college student) that an actual medical practice resembles that activity. Likewise, no one has a fully functional toy legal system to play with as a child, and as a result goes into law. On the other hand, “adult” programming, seen from afar, is enough like child-programming to set the computer-enthusiast child up for just this kind of exceptionally cruel bait-and-switch."

No, but they do see things like "House MD", "ER","The practice" etc... , which resembles the actual medical or legal profession as much as movie "hacking" resembles computer programming.

Besides, I've never known a child to actually see "adult" programming - unless one of your parents is working from home, most "adult" programming happens in a corporate setting. In the same way I've never known a child to see "adult" psychology, or other professions which are practiced in closed environments.

"Virtually every profession has a concept of professional equipment"

True, but so do programmers. The idea that professional equipment has to be hardware (or for that matter a keyboard) is rather false.

Professional writers use the same hardware as amateur writers - pen, paper, computer . But they might have better word processing software.

And I'm not sure about others, but the hardware I use for programming is much different then what an amateur computer user might have- a lot more memory (to run those IDEs, databases, memory cache etc...) , two or more screens , and software that are unlikely to be used by non professionals (Jetbrains IDE, Beyond compare, virtual machines) etc..

Also - there are keyboards designed for faster typing, from my experience they just not very useful (programming rarely requires fast typing in my experience, better googling would be a thousand times more useful).

At my workplace, we have both professional and amateur programmers. I admittedly fall into the latter category. And we use different tools. The pro's have C# and Source Safe. I have Python and git. They produce and maintain a zillion-line-of-code software product. I do R&D, testing, algorithm development, etc.

The demarcation is useful. I can try things quickly. But turning my spaghetti code into their good code is a point where all of my conceptual errors and missed corner cases can be wrung out, and they know how to maintain stuff for 10 years without going batty.

As other have mentioned, his focus on input devices is a misguided. If I lost a month of programming work, and only had a copy on paper, I would in most cases be able to type it in less than a day. My limitation is in logical reasoning, not in typing.

This is actually quite similar for music. A musician can't perform 40 hours a week, the process of playing is only a small part of being a musician. Unlike programmers, musicians typically only get paid for the time time they are performing, while programmers get paid for the time spent at work. This means that programmers really have a much better deal than musicians in general.

The advantage for musicians is that they also get recognition as individuals for their work, while the employers take most of that for programmers. That said, musicians can do the same deal if they choose to work as studio musicians or member of a symphonic orchestra or similar. Then they lose autonomy, but get more predictable pay.

> My limitation is in logical reasoning, not in typing.

I thought the same thing until I learned Vim.

If it were just typing, that'd be different. But editing is the real point. Being able to make changes almost as fast as I think them up has revolutionized my ability to get work done. It's not just that it speeds me up, it keeps me in flow, so I just get it done instead of getting bored and frustrated.

I know vim, but I don't think that change much. In fact, if I lost a month of work and did not have any printouts or even notes, I would in most cases be able to redo it in 2-3 days, and unlikely no more than a week. The reason is that I remember most of the decisions I made along the way, and don't have to spend time on making the right decisions about the code and architecture, since they were already made, and I would spend less time reading documentation and looking up how the problem can be solved in general.

What I describe is at least true when you solve relatively complex problems, and is a relative experienced programmer that take most high level decisions about the code yourself. If you have a very junior position, where most decisions are made for you by others, and you work in programming languages and framework that require a lot of boilerplate, then what I said will be less true. Then using the right editor may matter at least a bit. Even in that case I doubt it is a major factor.

On the other hand, using the right programming languages, libraries and tools may boost you productivity quite a lot, and have much larger impact than typing speed or input method.

Well I'm pretty experienced, nobody else is making decisions for me, and at least sometimes I do fairly complex stuff, but it still helps me a lot. I spend that time thinking, and then I can get it done without getting bored by the tedium and switching away to surf reddit. Or I think as I type and make wholesale changes as I go, because why not, it's easy. YMMV.

Ah, that's an interesting point. The definition of "professional" is debated, even among musicians, but the view that I adhere to is that "professional" describes the studio musician or symphony player. That may be self serving, as I fall into that category as a so called "side man." I get a call, show up, play, go home, seldom with the same band twice in a row. My name is seldom on the program. If the bandleader introduces me, it's to create a social atmosphere with the audience, not because anybody actually cares.

My doctor and plumber are professionals. They receive no recognition, and I don't even remember their names.

If a musician wants name recognition, then they would call themselves an "artist" and put up with all of the risks involved.

"Artist" and "professional" involve different skills too. For me to do "side man" work requires fairly extensive classical training and skills such as sight-reading, even though I play jazz. Many "artists" never develop those skills.

Perhaps the route for those who want to be "artists" in programming is academia or as a technical founder of a startup.

Author of the linked article speaking.

Possibly I should have emphasized the specific claim that junky input devices (e.g. QWERTY keyboard) are merely one symptom of the deprofessionalization of computer programming - rather than the 'alpha and omega' of it.

And, in this case, not only of computer programming. The fact that millions of people who make their living entering natural language text do so with the abominable limb destroyer known as QWERTY is an atrocity. Quite like the case of the radium watch dials and the labourers who went to an early grave making them. Or those who worked in the match factories, before them.

I just read through what you had to say about the death of HyperCard.

Why do you think Python etc. do not fill the hole HyperCard has left? Is it because of their ever-so-slight price of admission (which tends to push non-professional users away, as compared to the comfortable familiarity of a GUI)?

Which Python? Ver. 2 or 3? On what machine? With what graphical libraries? How much study would be involved in knowing all (and yes, it matters) of the Python+libs+os aggregate?

And does anyone alive know the above aggregate the way a kid can know Hypercard?

The 'master of all you survey' feeling of a kid on a raw Commodore-64 (or, to a lesser extent, Hypercard) - matters. If you've never experienced it, you are a blind man.

Asking the question re: Python suggests precisely this kind of blindness.

I confess that I do not know how to explain sight to a blind man. Perhaps someone else here is up to the task.

> "Professional equipment [...] sturdier, more solid, more rewarding of dedicated training, more difficult to obtain, than equipment intended for amateurs"

That is how I see Linux/Unix, and its tools - vim/emacs, the shell, etc. It doesn't have to be hardware, after all.

The OA sees professionals using amateur tools. I've always drawn some comfort from the idea that some young person somewhere not rich can get an old box and download an OS and the same toolchain that people use to build stuff they see.

Hardware can be differentiated: HP Z series work station half a dozen large monitors and a mechanical switch keyboard will feel much nicer than a frankenbox from the local supermarket. I take the OAs point that it is still basically a 'glass teletype'.

Yeah, my setup as a developer is a laptop with quad Core i7 CPU, 32G of RAM, 250G SSD and 1TB HDD, plus two 24" monitors.

That is a piece of professional equipment for a developer, and it cost about 4 times what a decent general purpose laptop does. But I could develop on any old box, and I like that.

I like the idea. But...

Is faster typing really the solution to the problem of wanting to professionalize computer programming? And is that even a problem?

I play the double bass. The problem that faster "entry" solves for musical instruments is wanting to express complex ideas in real time.

Exactly. Upgrading the keyboard in this case is more like improving your composing sheet or getting a better pen for composing -- not the limiting factor at all.

I guess the real 'instrument upgrade' analogy in this case would be upgrading the human mind, or perhaps a well tuned programming language.

Typing has never been the road block.

It's the inability to blend typing with other kinds of media I generate - easy references to diagrams, notes, reference papers, etc - that is my limiting factor, that is stopping my work for moving closer to my ideal of what a professional solution in software should look like.

I want some web-esque way to blend the several kinds of artifacts I make as a programmer in an easy to generate manner from a system that understands I'll be generating all these kinds of things, and that they're all fundamentally different expressions of the same idea.

That way I can blend drawing and doodling doing what they're they're good at with text entry with what it's good at, and create the deeper and more meaningful references that underscore the idea (or composition of ideas) I'm attempting, and not have several stand-alone pieces that don't express their relationships and interdependencies correctly.

Telling me how to play the violin faster doesn't help me conduct a symphony of ideas, and shows that the people proffering answers don't even understand what my problem actually is. (Hint: I'm rarely the one playing any particular instrument; rather, I'm trying to explain how I'll bring all the instruments to bear together on a single piece.)

I even think that slow input systems have benefits. I remember feeling awkward when using an HP48 (GUI was sluggish compared to other simpler calc) but it was so consistent, you didn't really care about it, you could think in advance, fill the buffer and think while the computer was processing the input. In the end, you'd enjoyed the slowness. It was a non-thing.

Also, back when people had to book computer time 1h per week, they had to think the thing through before asking the compiler to check and run the code. I'm pretty sure they didn't want to waste their time slot on a misplaced comma.

I think that that's not the point here.

The point is that software is often designed towards the average or median home user (i.e., mobile), not designed towards the professional software developer or the professional & expert users. Or, we conflate power with needing to be confusing(git, bash).

Probably the only piece of software I've heavily used that I can comfortably say is designed for professionals is emacs, and it's got well-known issues early on the learning curve. Arguably 30 years of modification in a system designed for modification have moved us to that happy place.

I think software is often designed towards the average or median programmer, not user. Professional software has to be written so one's successors can work with it, so it is typically written with a typical successor (ie. average or median) in mind. If this isn't the case, the typical management (ie. average or median) judge the predecessor to have been incompetent, as no one can understand his work, so it must be junk.

For example, I'd love to be more productive and use a WYSISYM system for my documentation, but the median person in the company that I work for can't get their head past a bog standard word processor, so won't be able to further develop what I write.

Some companies work on a higher plane, but most companies contain median programmers with median management, and need everyone to work at that level.

"most companies contain median programmers with median management"

I refer to that as the law of large numbers for work. Everything regresses to the mean. As someone who strives regularly to push beyond the mean, it's extremely frustrating.

>Is faster typing really the solution to the problem of wanting to professionalize computer programming? And is that even a problem?

Perhaps not for desktop programming. But why am I only allowed to do meaningful work in an upright posture at a desk? One-handed development on a train would be pretty awesome.

I'd like to find a one-handed keyboard that I can use in my pocket, without having to look at it, and which I can use with a relaxed, comfortably closed fist. Pressing the buttons on it should require only the lightest touch.

Unfortunately, I haven't seen anything remotely close to this.

>Is faster typing really the solution to the problem of wanting to professionalize computer programming?

I think both you and the article are making a mistake here. If you listen closely to the 1968 demo and, especially, its 1969 follow-up (available on archive.org) it's clear that Engelbart was not using the chorded keyboard for text input but for command input.

You should think of NLS text editor as a vi without cursor addressing: you would enter the command to execute with the chorded keyboard then select the target character/word/sentence with the mouse cursor.

You can follow the evolution of this idea throughout history. Many of Engelbart's "employees" went to work for Xerox Labs, the Xerox Alto used the keyset to give commands just like Engelbart's NLS.

The keyset was removed from Xerox Star after it proved to hard to learn and replaced with an extra block of keys on the left of the keyboard [2] with the most used commands.

When apple copied from xerox they got rid of this extra block (probably in the name of ease of use) but someone kept the idea alive by inventing the ctrl-zxcv for undo, cut, copy, paste that are conveniently placed all on the left side of the keyboard, so that you can use them while your other hand is on the mouse, like Engelbart always intended.

On this page [1] you can see some of the command given using a combination of the keyset (the chorded keyboard) and the mouse, it is not exhaustive however.

[1] http://chm.cim3.net/cgi-bin/wiki.pl?NlsTechnical/KeysetMap

[2] http://www.digibarn.com/friends/curbow/star/keyboard/keyboar...

Vim even has the verb-noun structure that Engelbart advocated.

A while back I played around with some old Windows 3.0 software based on Engelbart's Augment. The modern tool closest in spirit to it is probably Emacs org-mode with evil-mode.

> Engelbart was not using the chorded keyboard for text input but for command input.

It was designed for both, and certainly Engelbart himself could and did type with it.

Context menus (originally from Smalltalk) are another substitute for the expanded command set of NLS' chording-augmented mouse.

The advantage of having a chord keyboard for typing is that you can avoid the mouse-to-keyboard-to-mouse hand-movements that are so annoying when you can only type with a two-handed keyboard. However a one-handed chord keyboard is even slower than two-handed QWERTY when it comes to typing, all else being equal, and there is obviously the burden of having to learn it. For programmers and many other people, then, a better setup is probably a two-hand keyboard that lets you control a mouse pointer with minimal hand movement: and in fact we now have these, in the form of pointing-stick keyboards and keyboards with a trackpad in relatively easy reach of the user's thumbs http://www.loper-os.org/?p=861&cpage=1#comment-16138 . The mystery is why why people are still selling and buying expensive keyboards without either.

Previous discussion at https://news.ycombinator.com/item?id=4016421

And for who may interested in the idea behind chording keyboard, Bill Buxton wrote an informative chapter in his book http://billbuxton.com/input06.ChordKeyboards.pdf

I actually like this blog. There are some other reasonably sounding posts there: like “Bedrock of Abstraction” (http://www.loper-os.org/?p=55) or “On Formats War” (http://www.loper-os.org/?p=309)

Reply on news.ycombinator.com