Programmer Tooling Beyond Plain Text • Hacker News Board

Re: Programmer Tooling Beyond Plain Text

#51

Post by unhammer » Wed, May 06, 2015, 7:45 AM UTC

WalterGR wrote: post #35

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

Paredit is one of the reasons I find writing emacs-lisp really enjoyable, it made me dislike Python's lack of braces since I could no longer fly through my code as fast :-)

Note: there is now https://github.com/Fuco1/smartparens which might supersede paredit, supporting all kinds of languages; I haven't given it a good try yet though.

Re: Programmer Tooling Beyond Plain Text

#52

Post by davidshepherd7 » Wed, May 06, 2015, 7:45 AM UTC

Related: there are a few emacs plugins that can do structural editing for lisps.

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

https://github.com/Fuco1/smartparens

https://github.com/abo-abo/lispy

Re: Programmer Tooling Beyond Plain Text

#53

Post by lloeki » Wed, May 06, 2015, 8:15 AM UTC

unhammer wrote: post #48

BoppreH wrote: post #34

Earlier quoted context omitted.

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…

Isn't d% a more likely vim command? Although, you'd think vim would have a general "transpose text object" operator. If it were bound to some ŧ, then you could just do %ŧ% (here emulating Emacs' C-M-f C-M-t)

Short of having a transpose verb, here is what I cape up with (using the arg text objext):

    dia      # 1. delete argument under caret
    df       # 2. delete separator (comma and space)
    %        # 3. move after argument (i.e to end of tuple)
    p        # 4. paste separator
    "2p      # 5. paste argument

I'm not doing this out of the desire of golfing but to analyse and point out that what vim lacks in this specific case is how to semantically do step 3 (ga/gA ?) and possibly step 2 (because what if there's no space? a "separator", like "surround", might be useful), upon which one could easily and semantically build a "ŧa" (transpose argument) sequence (which could also become ŧ2a, ŧ3a to swap with the second or third next argument, and capitalize the a to swap with the previous).

That said vim is still "only" a text editor, but it goes a long way at being a general purpose one with semantic operations.

Re: Programmer Tooling Beyond Plain Text

#54

Post by escap » Wed, May 06, 2015, 8:37 AM UTC

skywhopper wrote: post #6

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

You might be interested in reading about Frontier, Dave Winer's outline/tree-oriented scripting language/object database/web server from the 90s: http://davewiner.userland.com/historyOfFrontier More context: http://scripting.com/davenet/ A lot of the infrastructure of the current web sprung out of Dave Winer's experiments with Frontier. From RSS/OPML/podcasts to weblogs to RPC-over-HTTP, Dave and his employees at Use…

no, Aaron did not work at UserLand. Aaron was involved in the RSS world though.

Frontier is open source, http://frontierkernel.org/ and these day, Dave Winer is rewriting a similar system with node, cf https://github.com/scripting?tab=repositories

Re: Programmer Tooling Beyond Plain Text

#55

Post by antod » Wed, May 06, 2015, 8:59 AM UTC

jameshart wrote: post #31

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 flas…

That brings back memories. Despite the horrible squishy keys that made text entry painful, the keyword entry was pretty efficient once you got used to it.

It wasn't quite my first coding experience though - I had tinkered on a TRS80, so I didn't quite have that same feeling of shock when moving on to something else.

Re: Programmer Tooling Beyond Plain Text

#56

Post by Dewie3 » Wed, May 06, 2015, 9:14 AM UTC

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…

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

I don't want structural editing because I can't remember the syntax of a language. I want it because I want to edit the code more efficiently. I don't know if I'll really be more efficient, but that's nonetheless what I want.

People who use more plain editors like Gedit or Notepad++ might scoff at Emacs or Vim users. But if they think that power editor users use them is because they can't write or navigate text, they're really missing the point. The point is to navigate and edit text more efficiently.

Re: Programmer Tooling Beyond Plain Text

#57

Post by WalterGR » Wed, May 06, 2015, 9:19 AM UTC

sunnyps wrote: post #43

WalterGR wrote: post #22

With previously working code above and below, I start to declare foo. In the process I introduced unmatched ‘{’; '('; and '"', and am referencing the not yet (fully) declared foo. This is routine editing, but it causes huge problems to tools like * typechecking * go to source * code folding * autocomplete * etc Visual Studio and C# aren't without problems, but they are without this problem. This works fine.[1] I'd be…

It's not a solved problem if your project is gigantic or if you're doing cross-platform development and don't want to or can't use the build system of the IDE or if it's C++. To me solving the problem has a higher bar - you should be able to open a large project for the first time and have usable intelligent editor support within a second. I'm even okay with the results of autocomplete being incorrect (to a degree) i…

    It's not a solved problem if your project is gigantic
    or if you're doing cross-platform development and don't
    want to or can't use the build system of the IDE or if
    it's C++.

I can't comment on whether the problem is solved for C++ because I haven't done C++ development in several years. But, for the other potential roadblocks you listed: no, they're all solved.

    To me solving the problem has a higher bar - you should
    be able to open a large project for the first time and
    have usable intelligent editor support within a second.

Well, therein lies the rub. With the "intelligence on a novel project within one second" requirement, if it hasn't already been solved then you will never find it to be.

Many people are fine with a tool that has a large(r) start-up cost if saves them time (and/or headache) during run-time. Also, I don't think - though I can't prove - that it's common for people to open and close large projects in IDEs often enough that start-up time is a primary concern.

Combine that with increased tool feature count and project complexity as time goes on, as well as limited resources for tool development, plus the current start-up times being Good Enough, and the result is a problem that won't get solved.

    [IDEs] require you to use their build system...

I'm not sure what you mean. In my experience, you can use IDEs as glorified text editors - and build from the command line or some other external build tool.

Re: Programmer Tooling Beyond Plain Text

#58

Post by chipsy » Wed, May 06, 2015, 9:53 AM UTC

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…

Something I notice about the UI you use is that it tries very hard to emphasize the structured-ness of the underlying engine. Perhaps the middle ground goes back towards Emacs(or rather, a new iteration of the Emacs concept) - plain old text editing is the default, but the underlying editing engine is always working in structured form.

Ultimately, I have to concur with the people calling out the lack of need; if my sustained average is 80 lines of code per day, I'm not being bottlenecked by my type time, but I am bottlenecked by typing errors that cascade to runtime. I would welcome seeing more modes that simplify specific, necessary-but-error-prone tasks like copy-paste-modify.

Re: Programmer Tooling Beyond Plain Text

#59

Post by collyw » Wed, May 06, 2015, 10:51 AM UTC

Its probably because I have spent way more time in front of an IDE than in (advanced) maths classes that I find the code example vastly more readable. I had no idea what the Integral symbol on the left meant, while the function name makes it obvious. Likewise the parenthesis make it easy for me to understand what gets parsed first.

Re: Programmer Tooling Beyond Plain Text

#60

Post by girvo » Wed, May 06, 2015, 12:10 PM UTC

mkramlich wrote: post #36

BoppreH wrote: post #34

Earlier quoted context omitted.

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…

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 think having a system that removes that barrier would allow that vast sea of average programmers to move closer to that sublime moment where your thoughts are transcribed in code, perfectly, in one go.