Live data from Hacker News

Programmer Tooling Beyond Plain Text

joelburget.com

61–70 of 75 posts

Re: Programmer Tooling Beyond Plain Text

#61
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…

>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.

And yet, it's this "nearly" that creates all the huge C buffer overflow and memory corruption bugs...

Re: Programmer Tooling Beyond Plain Text

#62

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...

> To the Paredit user who just clicked the comments link followed by Ctrl+F paredit: what do you think of it?

How the hell did you see me doing that? :O. I searched for it after reading top-level thread since a lot of comments are basically describing Paredit.

I'm using Paredit to write Lisp and I really miss this style in other languages. It takes some time to get used to - I finally grokked it after spending ~1 hour (two pomodoros) on structuring and restructuring a block of Lisp code. But after that hour of practice, writing code feels much different.

Lisp code is an explicit tree structure, and what Paredit does is enforce that structure. It lets you move things up and down the tree, or left and right at the same level, automatically maintaining the structure (keeping your parens balanced). It properly handles cutting and pasting parts of a tree. After you internalize those features, you really start to think of code in terms of trees instead of text representation.

Re: Programmer Tooling Beyond Plain Text

#65
post #34

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…

Using vim with the sideways (https://github.com/AndrewRadev/sideways.vim) plugin and the following mappings in .vimrc:

    nnoremap  h :SidewaysLeft
    nnoremap  l :SidewaysRight
I pressed two keys, job done: ,l

Re: Programmer Tooling Beyond Plain Text

#66
post #34

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…

Double click, type "20", double click, type "15", double click, type "10", double click, type "35".

(All without typing the actual quotemarks.)

If I had realised earlier that it's (x,y) to (y,x), I could've done it without the keyboard at all.

Re: Programmer Tooling Beyond Plain Text

#67
post #60

Earlier quoted context omitted.

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…

I don't disagree with you, but: > non-lame programmers How many programmers are out there that are "lame"? Honestly, I still to this day work with code written by developers with years of experience who still get syntax wrong. Often I forget that most skills follow a bell-curve, and most developers are not one-with-their-machine-and-language -- hell, even I'm probably not, although some days I might feel like it. I t…

I don't agree with the premise that structural editing is for developers that are (necessarily) subpar to begin with (see my other comment).

Re: Programmer Tooling Beyond Plain Text

#68
post #61

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…

> 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. And yet, it's this "nearly" that creates all the huge C buffer overflow and memory corruption bugs...

That sounds like a language problem, not an editor problem.

Re: Programmer Tooling Beyond Plain Text

#69
post #34

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…

Nice example, but...I work with graphics code a lot (I'm a game developer), as well as in tons of other domains. That operation wouldn't be worth the mental storage (and certainly not a key!) to memorize. I can't think of the last time I would have needed it. Maybe when getting a pair of function parameters in the wrong order?

The example you gave wouldn't ever be a program I'd write. Magic numbers? Hard-coded rendering? Rendering something that can't be edited by an artist? All bad. I understand that it's just an example, but can you come up with one that would be valid in production code?

I know you were looking for a simple example, but in addition to the comments others have made about syntax not being a big deal for an experienced developer, this looks like a helper operation for developers who are doing it wrong to begin with.

Aside from that, years of user-experience research shows that modal editors are worse than the alternative (if you can hit one key, that means you can't type text in that mode; sorry vim-lovers, but it's true).

Yes I tried your experiment, and I could get it down to 7 keystrokes in my editor. I type quickly, so that's a couple of seconds at most; less than a second if I'm in the zone. With how rarely I do that operation, I'd not bother trying to optimize it more (another comment mentioned premature optimization).

But if I did need to do it a lot, creating a new macro that did the right thing wouldn't be hard; in a couple minutes I could bind a simple version of the command to a key permanently. Also, if I were modifying many similar lines to change them, I have options: Refactoring tools (if we're talking a function signature change), simple keyboard macros, or smart multi-file search-and-replace regular expression conversions.

And all of this in a "text" editor with a low barrier to entry (unlike vim OR emacs) -- though one that understands some structure at least.

Re: Programmer Tooling Beyond Plain Text

#70
post #61

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…

> 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. And yet, it's this "nearly" that creates all the huge C buffer overflow and memory corruption bugs...

Are you suggesting that syntax errors create memory corruption?
Post reply on HN