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

11–20 of 75 posts

Re: Programmer Tooling Beyond Plain Text

#11

Post by makmanalp »

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…

Very neat!

I think the issue with high learning curve tools is not that the learning curve is high, it's that the benefit seems (rightly) dubious at the beginning.

You can find videos of people whizzing along with emacs or vim, and it's not difficult to see the productivity gain. So it'd be cool if you had a video of what it looks like to program with this thing.

Re: Programmer Tooling Beyond Plain Text

#12

Post by BoppreH »

makmanalp wrote: post #11
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…

Very neat! I think the issue with high learning curve tools is not that the learning curve is high, it's that the benefit seems (rightly) dubious at the beginning. You can find videos of people whizzing along with emacs or vim, and it's not difficult to see the productivity gain. So it'd be cool if you had a video of what it looks like to program with this thing.

Thank you, and you're absolutely correct. I think a side-by-side video comparison would work even better, because it's not immediately clear how much time is spent moving commas around, playing with whitespace or hunting parenthesis.

That said, I'm not trying to convert people just yet. It still needs polishing and support for a few more languages (right now it only does Lua, Python and basic Lisp, which is not very exciting).

Re: Programmer Tooling Beyond Plain Text

#13

Post by wyc »

The notation section reminded me of what good tools APL/J/K/Q were for dealing with matrices:

http://jsoftware.com/help/dictionary/vocabul.htm

Instead of Mat.Inverse(), there's an operator that actually means "take the inverse of this matrix". Likewise, the power operator in J, if given infinity as the exponent, will apply a function to a value until the fixed-point is reached. Haskell's infix operators also steer towards this direction of expressiveness.

It's pretty liberating to be able to use programming symbols to represent computations in the same way the integral symbol represents integration. However, the barrier to literacy is inevitably raised.

Re: Programmer Tooling Beyond Plain Text

#14

Post by ploxiln »

jamii wrote: post #8
ori_b wrote: post #5

I've been hearing this sort of thing for years (decades?), but I have yet to see someone put a toolchain together that works well using these concepts. It would be interesting to see someone try it instead of just talking about how it would be a good thing.

Excel, Access, Labview, Scratch. Pretty much anything that doesn't require years of training as a programmer uses a mixture of structured editing and small chunks of raw text. If you look at it by sheer number of users, structured tools are winning and have been for a long time.

Except for programmers. And when people try to do what we do, but in Excel, it's bad. Or if they try to do it in Labview, it's also bad. (I've personally seen both.)

These tools can't do, structurally, what git (or even cvs) does with plain text, or what vim or emacs (or even notepad!) do with plain text.

Re: Programmer Tooling Beyond Plain Text

#15

Post by anigbrowl »

coliveira wrote: post #7

colorForth adds at least the color dimension to a programming language. Words have different meaning depending on the color used. This reduces the amount of punctuation and the need for "reserved" words as we see in traditional languages.

Sounds awful. What about people who are color-blind? How are you going to read it out to yellow-somoene across the purple-room?

Re: Programmer Tooling Beyond Plain Text

#16

Post by jamii »

ploxiln wrote: post #14
jamii wrote: post #8

Earlier quoted context omitted.

Excel, Access, Labview, Scratch. Pretty much anything that doesn't require years of training as a programmer uses a mixture of structured editing and small chunks of raw text. If you look at it by sheer number of users, structured tools are winning and have been for a long time.

Except for programmers. And when people try to do what we do, but in Excel, it's bad. Or if they try to do it in Labview, it's also bad. (I've personally seen both.) These tools can't do, structurally, what git (or even cvs) does with plain text, or what vim or emacs (or even notepad!) do with plain text.

When people try to do what we do, but in python/emacs/git, it's bad. It's not like if you banned excel the same people would suddenly produce a beautifully factored python program. They just wouldn't have anything at all.

Right now we have structured tools with easy learning curves but low ceilings, and raw text tools with high ceilings but with a learning curve like being punched in the face with a brick wall. There is definitely room to explore in between the two.

Re: Programmer Tooling Beyond Plain Text

#17

Post by smarks159 »

The most complete example of a structured editing system I know off is Doug Engelbart's NLS system from the mother of all demos (from 1968!) [0]. In the system text, drawings and code are all structured hyperdocument data. It is quite different from most software we use today. As seen from the demo, structured editing works well not just on code but on also on text.

I have been experimenting with implementing some of these ideas in the browser[1]. I primarily use the system to take text notes with and write down my ideas. You can't program in it yet, but part of the program is driven by datastructures that are created, edited and manipulated in the system itself. Instead of looking and manipulating the raw data, however, you can render the data to look like a pseudo dsl.

[0] https://www.youtube.com/watch?v=yJDv-zdhzMY

[1] https://github.com/smarks159/hyperdocument-system-wiki

Re: Programmer Tooling Beyond Plain Text

#18

Post by michaelmrose »

jamii wrote: post #8
ori_b wrote: post #5

I've been hearing this sort of thing for years (decades?), but I have yet to see someone put a toolchain together that works well using these concepts. It would be interesting to see someone try it instead of just talking about how it would be a good thing.

Excel, Access, Labview, Scratch. Pretty much anything that doesn't require years of training as a programmer uses a mixture of structured editing and small chunks of raw text. If you look at it by sheer number of users, structured tools are winning and have been for a long time.

Come back when you can write excel as an excel macro. The argument that spreadsheets are easy for non programmers to use is not an argument for replacing programmers current tools with structured tools. Nor an argument against.

Re: Programmer Tooling Beyond Plain Text

#19

Post by jamii »

michaelmrose wrote: post #18
jamii wrote: post #8

Earlier quoted context omitted.

Excel, Access, Labview, Scratch. Pretty much anything that doesn't require years of training as a programmer uses a mixture of structured editing and small chunks of raw text. If you look at it by sheer number of users, structured tools are winning and have been for a long time.

Come back when you can write excel as an excel macro. The argument that spreadsheets are easy for non programmers to use is not an argument for replacing programmers current tools with structured tools. Nor an argument against.

Come back when you can write a database in sql, or a browser in html. Hell, try writing a browser in javascript.

How much of what the average programmer does looks like implementing a programming language and how much is just throwing some UI over a CRUD database? Why insist that a tool is only worthwhile if it can do both? There is plenty of room for tools that just solve the kinds of problems that most people have and do it without requiring years of training.

The vast majority of knowledge workers still rely on tools like Excel and Labview even when they are grossly unsuited for the task at hand, because the alternatives we offer require far too much training.

No-one is going to take your emacs away, we're just trying to figure out what the other 99% of the population is going to use.

Re: Programmer Tooling Beyond Plain Text

#20

Post by RootDynasty »

BoppreH wrote: post #12
makmanalp wrote: post #11

Earlier quoted context omitted.

Very neat! I think the issue with high learning curve tools is not that the learning curve is high, it's that the benefit seems (rightly) dubious at the beginning. You can find videos of people whizzing along with emacs or vim, and it's not difficult to see the productivity gain. So it'd be cool if you had a video of what it looks like to program with this thing.

Thank you, and you're absolutely correct. I think a side-by-side video comparison would work even better, because it's not immediately clear how much time is spent moving commas around, playing with whitespace or hunting parenthesis. That said, I'm not trying to convert people just yet. It still needs polishing and support for a few more languages (right now it only does Lua, Python and basic Lisp, which is not very…

Is your editor open source? It looks really interesting.
Post reply on HN