Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmer Tooling Beyond Plain Text

joelburget.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: Programmer Tooling Beyond Plain Text

#31

Post by jameshart »

The very first programming text editing interface I ever used was the ZX Spectrum's BASIC editor. The Spectrum had a peculiar modal entry system, where entering any keyword was always a single keypress. The keyboard had all the BASIC keywords written on and around the keys (see http://en.wikipedia.org/wiki/ZX_Spectrum#/media/File:ZXSpect...).

As you typed a BASIC command, the cursor would switch between being a flashing 'K' (keyword entry mode: the next key you press will enter the white keyword on that key), or in expression entry mode, a flashing 'L' (lowercase letter entry) or 'C' (capital letter entry). Other keywords were accessible using the 'Symbol Shift' key (to enter the symbols or function names in red on the key caps), or by pressing symbol shift and shift you could put it into 'Extended' mode and enter the red or green keywords above or below the keys.

The upshot of this was that Spectrum BASIC never had to lex code outside of basic expression parsing - and the only ASCII lexing it had to handle was expressions containing literals and variable names. Any keyword token was stored just as a single character token in memory - the program was stored tokenized and ready to be interpreted. It was fundamentally impossible to type certain classes of syntax error.

I remember being kind of surprised when I came across the BBC Micro and C64 where you had to type BASIC keywords out in full. It felt crazy - how could the computer handle you mistyping 'prnit'? How come the computer let you type lines of BASIC in that were wrong?

I still think there's something slightly broken about the fact that text editors let you type syntactically invalid code.

Re: Programmer Tooling Beyond Plain Text

#32

Post by mkramlich »

BoppreH wrote: post #10

I've been working on a Structured Code Editor for a couple of years: https://i.imgur.com/wvcduDk.png (in the picture above "string" is selected, and "find" is slightly highlighted because its on the same level. this helps visualize the tree and plan your movements) It actually started as my final project during undergrad. Here's my 78-page thesis on it (unfortunately Portuguese, but has English pictures): https://pro…

I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros right, on 1st attempt, becomes nearly effortless, once in that frame of mind.

It's the think-design-code-test loop that is the biggest driver on my time/energy/brain cost. Not syntax conformance. Conformance becomes like a musician having played a certain instrument for enough years, you acquire muscle/eye memory for what note requires what finger/body/mouth positions/behaviors, nearly a one-to-one map, autonomous.

Do agree that anything that enforces syntax correctness, upfront, is helpful for newbies, especially "forever newbie" use cases, the non-expert users.

Re: Programmer Tooling Beyond Plain Text

#33

Post by atrus »

fizixer wrote: post #30

In some sense pointing out 'text'ness of the text tools is the wrong thing to do (e.g., 'text' is something that contrasts with 'binary'). All of Excel, LabView, Scratch etc (as jamii pointed out in the other comment, as examples of structured editors), could have text file formats behind the scenes which could still be diffed, grepped etc. (unless the author made the distinction between text and ASCII/Unicode). I th…

Macromedia Dreamweaver had a nice split pane option where you could view both the html and rendered page at the same time. You could edit either side at will, and they both would stay in sync. Some things were much easier just dragging and dropping them into place, whereas other items it was easier tweaking text to get it to look right.

Re: Programmer Tooling Beyond Plain Text

#34

Post by BoppreH »

mkramlich wrote: post #32
BoppreH wrote: post #10

I've been working on a Structured Code Editor for a couple of years: https://i.imgur.com/wvcduDk.png (in the picture above "string" is selected, and "find" is slightly highlighted because its on the same level. this helps visualize the tree and plan your movements) It actually started as my final project during undergrad. Here's my 78-page thesis on it (unfortunately Portuguese, but has English pictures): https://pro…

I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros…

Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch.

  lineTo((10, 35), (20, 15))
         ^
  lineTo((20, 15), (10, 35))
Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the keyboard. Three or four seconds, and to me feels like using a blunt knife.

And yet you are just moving one element down a list. You do it all day with parameters in a function, statements in a block, items in a literal list. Which is why it has a dedicated command in my editor: "Move down" (https://i.imgur.com/wvcduDk.png). It's a single key. Works in all cases mentioned, for all supported formats.

I'm not saying a structured editor is for people who forget semicolons. It's for people who have to work with semicolons.

Re: Programmer Tooling Beyond Plain Text

#35

Post by WalterGR »

melloclello wrote: post #2

I've long felt that a proper structured editor would work somewhat like a tree editor[1]. Code is trees, right? [1] https://pcmonk.wordpress.com/2014/04/01/why-dont-we-have-a-g... If you had a really good, intuitive tree editor, I would imagine it would be easily adaptable to all kinds of interfaces and scenarios. Mobile, web, VR...

    If you had a really good, intuitive tree editor
People who write Lisp in Emacs seem to swear by Paredit.[1]

I've not used it so I can't respond to either "really good" or "intuitive", but let's see if this works: To the Paredit user who just clicked the comments link followed by Ctrl+F paredit: what do you think of it?

[1] http://danmidwood.com/content/2014/11/21/animated-paredit.ht...

Re: Programmer Tooling Beyond Plain Text

#36

Post by mkramlich »

BoppreH wrote: post #34
mkramlich wrote: post #32

Earlier quoted context omitted.

I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros…

Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the ke…

again... I hear you. been there, done that, have the T-shirt, over 35 years of coding in multiple domains, including GUIs, graphics, games, code-driven visual layouts, etc.

and I'm saying with a low-overhead deterministic-optimized editor like vim, and the right person at the keyboard, this can be done very quickly and accurately. and again, to continue your example, the hard part is not getting the syntax correct it's ensuring the resulting visual image -- your example suggests a vectory visual artifact ala OpenGL or SVG, etc. -- has the right shape and position. Syntax is something my brain/eye system just tells me, instantly, RIGHT or WRONG. our brains are great at this.

I'm not saying you're wrong. I'm saying for non-newb, non-lame programmers it's a use case that optimizes for a cost that's one of the smallest costs imposed on the programmer. not unlike "premature optimization".

I'm not saying syntax-enforcing keystrokes are a bad thing. I do think there are benefits to having a set of syntax-generic consistent keystrokes, like vim, across all the various syntaxes one has to deal with, day in and day out. If the only thing I ever had to edit was C files or JSON, that's it, nothing else, then yes having a C or JSON-semantic keystroke-restricted inescapable mode (with prompts, wizards, etc.) would be a help. (Which arguably is how all the big fat modern IDEs have evolved towards anyway.) But I'm very aware of the phenomenon where one can gain in the small but lose in the large. Local maxima, etc.

Also benefits to having screen match print, etc. Being grep-friendly, diff-friendly, textual VCS-optimized friendly, etc.

Local maxima. The sneakiest wrongs are right in the small.

Re: Programmer Tooling Beyond Plain Text

#37

Post by rwallace »

This article makes exactly the same mistake that pretty much everyone else suggesting programmer tooling beyond plain text has made: assuming it has to be either or, that if we want more sophisticated tools that use a more complex representation, we have to give up text.

The suggestion is a nonstarter. Network effects alone would prevent the world making such a move, and it's a good thing, because the loss wouldn't be just a particular existing tool, it would be the entire universe of tools that work with text, that the world has spent decades developing, most of which any individual has never even heard of, let alone thought about how to replace.

It's also completely unnecessary. If you want a tool that lets you view and edit your code in a fancy table format, you can write one. All it needs to do is parse the existing source code into whatever internal format it wants and write it out again afterwards. Yes I know the author criticizes parsers, but really, writing reliable parsers has been done often enough to make it clear that it's a solvable problem. And would it not be better to have some of what you're looking for in an actual tool than all of it in an imaginary one?

Re: Programmer Tooling Beyond Plain Text

#38

Post by pcmonk »

melloclello wrote: post #2

I've long felt that a proper structured editor would work somewhat like a tree editor[1]. Code is trees, right? [1] https://pcmonk.wordpress.com/2014/04/01/why-dont-we-have-a-g... If you had a really good, intuitive tree editor, I would imagine it would be easily adaptable to all kinds of interfaces and scenarios. Mobile, web, VR...

I've personally been pulled into another project, but I do think there's plenty of unexplored space in the structured code editor arena. Paredit is good, but I'd like to see a more visual way of dealing with the structure.

The challenge is, of course, that a general-purpose tree editor is not likely to be efficient for editing code. You have to resist the urge to over-generalize. A good structured code editor isn't likely to be useful for anything besides coding.

Re: Programmer Tooling Beyond Plain Text

#39

Post by mkramlich »

BoppreH wrote: post #34
mkramlich wrote: post #32

Earlier quoted context omitted.

I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros…

Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the ke…

I do think the "killer app" use case for the modalities you're talking about are data entry kinds of use cases. Where a non-expert user, perhaps one who has to deal with a variety of formats, very randomly, is required to type things in that strictly confirm to a perfectly-defined syntax. And he/she has a gigantic amount of data to enter manually, by hand, in a short time. Higher throughput is better, but also highest correctness is the other dimension. Tiny percentage time overhead spent on thinking, design, test. Mostly on data entry by hand. Then yes your approach starts to yield disproportionately higher benefits.

Arguably one reason why XML/XSD/XSL took off. It was not just yet-another-structured-text-format like CSV and JSON. It also had an "official" way to express and constrain an application data format, and generic query and mapping languages. Great for low brain, high volume, high repetition use cases. However... programming itself is high brain, lower volume, low repetition.

Re: Programmer Tooling Beyond Plain Text

#40

Post by gumby »

BoppreH wrote: post #34
mkramlich wrote: post #32

Earlier quoted context omitted.

I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros…

Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the ke…

That's a lovely example. I was going to post that I don't like structure editors, but your example is two keystrokes in Emacs: c-m-F and c-m-T -- which I now (after 35+ years) realize is a structure editor.

(one of the first things I worked on when I started at PARC was adapting an Emacs clone since I didn't like the Interlisp structure editor. Little did I know!).

Post reply on HN