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

Ask HN: More “experimental” UIs for editing/writing code?

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 137 posts

Re: Ask HN: More “experimental” UIs for editing/writing code?

#81

Post by mkl »

pasc1878 wrote: post #75
sitkack wrote: post #68

Earlier quoted context omitted.

The original refactoring browser/editor was https://en.wikipedia.org/wiki/VisualAge it was later Open Sourced as Eclipse but it predates it by over a decade.

I don't think Eclipse is Open Source Visual Age for Java. Both came from IBM but... When the IBM rep cam to our company explaining the change he explained what changed and 3 of the points were why I used VAJ and Eclipse did not have them (at the time 10 years later it nearly had them). VAJ worked with an included JRE that allowed you to edit code as it ran. VAJ included a GUI builder VAJ was organised around code str…

From that Wikipedia link:

> VisualAge for Java is based on an extended Smalltalk virtual machine which executes both Smalltalk and Java byte codes. Java natives were actually implemented in Smalltalk.[6]

> VisualAge Micro Edition, which supports development of embedded Java applications and cross system development, is a reimplementation of the IDE in Java. This version of VisualAge morphed into the Eclipse Framework.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#82

Post by lelanthran »

bartimus wrote: post #27

I one time did a project entirely in notepad. Not notepad++. But the standard notepad that comes with Windows. It was a time when I got tired of frameworks and IDE's that come and go and try to offer things more conveniently. Again having to learn about some new kid on the block. Having to depend on 3rd parties. I wanted everything to be vanilla. What's interesting is how this forces you to think carefully about stru…

> I'm now using VS Code. I hate how the file explorer jumps around when closing a tab (because it tries to select whatever other tab becomes visible). VS Code also doesn't allow me to easily open my files in multiple windows. Meanwhile we have browsers that allow us to freely open windows or tabs.

I use VSCode with the Vim plugin (it's not perfect: browsing undo/redo tree can lose changes, opening new tabs with `tabe` doesn't work correctly, etc), but on a widescreen monitor, I use `:vsplit` and `:split` often, and this allows me to view the code in 4 to 6 different files, aiwth all of them on the same screen at once.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#83

Post by unsafecast »

TazeTSchnitzel wrote: post #66
marttt wrote: post #60

Not exactly "experimental", considering the Unix heritage, but -- line editors. "I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing." -- Ken Thompson, on the superiority of ed to visual editors. Summarized by Peter Salus in A Quarter Century of UNIX (Addison-Wesley, 1994). Definitely a blast from the past, but I do think line editors may…

Home computers (and, later, certain environments for DOS) used to have you enter programs line by line in this fashion: 10 PRINT "HELLO, WORLD" 20 GOTO 10 You would add or edit a line by using appropriate numbering: 15 PRINT "HELLO EDIT" And you could get the full program with: LIST Does this count as line editing?

I think you'd call that line... appending? Definitely not line editing though.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#84

Post by TuringTest »

nkuttler wrote: post #77
allday wrote: post #73

This thought crosses my mind a lot too. When we're working with code, we're shaping information into structures and patterns. And so our brains are tasked with translating those structures and patterns into text, making sure that text is written exactly right, and reconciling the difference in the observed output of structures and patterns with the text we've written. What if we could stay at that higher level of abs…

> Anything to reduce the friction from thought to working software without having to worry about syntax. The syntax complexity will just be moved into a visual layer, it doesn't disappear. > VR with 3D representations of code as, I dunno, pipes, gears, something like that? Those 3D representations will just generate some code again, adding another layer of complexity to the debugging process?

> The syntax complexity will just be moved into a visual layer, it doesn't disappear.

You missed the part where our brain is much better prepared to deal with visual complexity than textual. It's like moving the job to a specialized hardware co-processor.

Even if the inherent complexity of the task is the same, the environment would allow to do it way more efficiently. And we could also redesign the languages and IDEs to take advantage and reduce non-inherent complexity as well. See for example the Cursorless demo linked above, where you can target specific bits of code by naming a letter rather than navigating to them with arrow keys or the mouse.

https://m.youtube.com/watch?v=5mAzHGM2M0k

Re: Ask HN: More “experimental” UIs for editing/writing code?

#85

Post by austinjp »

fragmede wrote: post #32

If you haven't used Colab/Juypter Notebooks yet, I highly recommend you try it. It's a "notebook" style interface used a lot in data science, and it allows you to run "cells" in arbitrary order if needed. Stylized comments are well supported. The other interesting interface I've come across is https://gibber.cc/ and https://glicol.org/ which are both music coding environments though they have slightly different UI so…

The algorave and live music coding scenes are fun to watch, and no doubt their editors are innovative in ways I'm not aware of. Might investigate.

As for REPL-driven development, I agree. A smoother way of moving from REPL to editor would be great. I use ptpython and Emacs in terminals. I could probably get ptpython running in an Emacs buffer, never tried that approach. Ptpython's history makes copy-and-paste into Emacs fine, but it's all a bit clunky. Variables, imports, etc all need to be fiddled with. (Separate gripe: ptpython needs restarting if changes are applied to an imported file.)

Re: Ask HN: More “experimental” UIs for editing/writing code?

#86

Post by gbrown_ »

I came across tylr the other week which looks very interesting. Probably easiest to watch this video[1] first then play with the demo and read the paper [2][3].

[1] https://www.youtube.com/watch?v=00riOfMuaNY

[2] https://tylr.fun/

[3] https://tylr.fun/essay

Re: Ask HN: More “experimental” UIs for editing/writing code?

#87

Post by capableweb »

austinjp wrote: post #85
fragmede wrote: post #32

If you haven't used Colab/Juypter Notebooks yet, I highly recommend you try it. It's a "notebook" style interface used a lot in data science, and it allows you to run "cells" in arbitrary order if needed. Stylized comments are well supported. The other interesting interface I've come across is https://gibber.cc/ and https://glicol.org/ which are both music coding environments though they have slightly different UI so…

The algorave and live music coding scenes are fun to watch, and no doubt their editors are innovative in ways I'm not aware of. Might investigate. As for REPL-driven development, I agree. A smoother way of moving from REPL to editor would be great. I use ptpython and Emacs in terminals. I could probably get ptpython running in an Emacs buffer, never tried that approach. Ptpython's history makes copy-and-paste into Em…

Most lisps that leverage repl-driven development also have repl integration in the editor itself. So for example, I write my Clojure code with vim as normal, and when I want to run a snippet of code, I highlight what I want to run and execute that snippet in the editor, that communicates with the running repl instance and displays the result in my editor. This way, when I'm done, I simple save the file that has all the code i've evaluated in it already.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#88

Post by bitwize »

unsafecast wrote: post #83
TazeTSchnitzel wrote: post #66

Earlier quoted context omitted.

Home computers (and, later, certain environments for DOS) used to have you enter programs line by line in this fashion: 10 PRINT "HELLO, WORLD" 20 GOTO 10 You would add or edit a line by using appropriate numbering: 15 PRINT "HELLO EDIT" And you could get the full program with: LIST Does this count as line editing?

I think you'd call that line... appending? Definitely not line editing though.

There were line editing features in micro BASICs though. Some early versions of Microsoft BASIC let you say EDIT 10 and be taken into an edit mode, where vaguely vi-like, but more perhaps TECO-like, keyboard commands let you change the line by inserting, deleting, swapping, etc. characters.

The Commodore BASICs let you just cursor up to the line on the screen and change it, and when you hit enter the interpreter just read the screen at that line and accepted it as the new line. There were smarts in there to detect wrapped lines and accept the whole thing. Despite being more primitive it was a huge UI win, so GW-BASIC adopted this approach as well.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#90

Post by unsafecast »

kragen wrote: post #43
PainfullyNormal wrote: post #10

Have you heard of dion? https://media.handmade-seattle.com/dion-systems/ It's still in the category of "inserting text with the keyboard", but the underlying representation of the "program" isn't raw text. The text is just a user interface for a more complicated representation.

https://github.com/dion-systems/metadesk seems to be the repo for their prototype. It seems like it's vaguely similar to SGML but with small but significant differences: instead of blah blah you say a: "blah blah", the node labels can be user data instead of just structure, attribute values are full subtrees instead of just strings, and attributes syntactically precede the node, so you say @foo(bar) baz instead of .

That's not Dion. It's a plain text language for DSLs.

This is Dion: https://dion.systems/gallery.html

(Those are videos)

Post reply on HN