I have used Scheme and Racket a fair amount and know bits of Common Lisp.
What I don’t understand is what I stated and what I quoted.
Without seeing it demonstrated, I just don’t understand the quoted claims. When I’ve done Scheme and Racket, I never really needed to be copying and moving ASTs (i.e., parenthetic groups) all over the place. Maybe that’s just me and my style, for better or worse.
Re:Running Lisp in Production (2020)
by reikonomusha on Wednesday February 02, 2022 @01:59AM
(#30174630)
I think "structural editing" is a better way to talk about it. You manipulate code as units of S-expressions. You don't type parentheses so much as you create and modify (trees of) S-expressions. So things like unbalanced parentheses or improperly indented forms are not possible since there's no way to create them in the first place.
In a somewhat vague sense, the "units of editing" are not characters.
There are some videos on YouTube demonstrating ParEdit and SLIME.
That’s fine, but I don’t see where one gets "light years ahead of any programming IDE out there" from that.
I like Lisps/Schemes as much as the next person, but other languages don’t have parentheses to deal with, so by that same token, you’re getting that for free, such as an ML like F#.
Re:Running Lisp in Production (2020)
by mrcode007 on Wednesday February 02, 2022 @12:54PM
(#30181207)
There isn’t a single language IDE that I know of outside of Lisp that allows you to hoist a sub block of a loop (a sub tree in the AST) and remove the parent of that code and paste the hoisted expression while simultaneously removing the loop construction with a single key. Please show me an IDE like that and I will buy it immediately. Paredit is not about parenthesis editing and matching despite its name.
Okay, but my original question remains.
Re:Running Lisp in Production (2020)
by medo-bear on Thursday February 03, 2022 @11:26PM
(#30202868)
with lisp structural edditing you are editing blocks of code, as opposed to characters. in fact it is the use of s-expressions that makes this possible. here is a simple example. immagine you have a list, two elements just outside it, and your cursor is just after the second element:
Python: [x,y,z] 1,2
Lisp: '(x y z) 1 2
Python: [x,y,z,1,2]
Lisp: '(x y z 1 2)
By day 7 you should have a feel for what people mean when they say you are directly editing the AST.
Basically: there is the same amount of friction to moving constructs around at a high level as there is at a low level, and this is due to Lisp’s uniform syntax, and paredit leverages this a lot.
Contrast this to a language like Java, where the friction between modifying a single expression and modifying class-level interactions are totally different, syntactically. Now you find yourself leaning on highly specific IDE-level support or Lombok for things like setting up Builders for every POJO, to get around these constraints.
From a Lisper’s perspective, these syntactic constraints are unnecessary, and should at most require a library that you can trivially port to any editor. Which is exactly what paredit achieves.