4 ms·

You were probably downvoted too because you keep assuming other people talking about structural editing have never used IDEs for Java, php, C++, C#, etc. Nothi

You were probably downvoted too because you keep assuming other people talking about structural editing have never used IDEs for Java, php, C++, C#, etc. Nothing is blowing my mind, structural editing is different from what you're talking about, and enables different benefits and also downsides then those. I think the wikipedia article I linked does a good job at explaining the distinction: > editors in some integrated development environments parse the source code and generate a parse tree, allowing the same analysis as by a structure editor, but the actual editing of the source code is generally done as raw text.

dmitriid 9y ago
> You were probably downvoted too because you keep assuming other people talking about structural editing have never used IDEs coming from a person who also wrote this: > You were downvoted because what you said shows that you do not understand what paredit is. > I'd recommend you read ... to better grasp the concept. So, people keep assuming that I for some reason have never tried paredit (or written anything in Lisp). So why don't I give you a taste of your medicine. I suggest that you go and read some documentation on the IDEs I mentioned and try and use them to better grasp the concept. Paredit is a very dumb tool that only works because Lisp's syntax is regular. There's nothing semantic or structural about the ability to move some words in or out of parentheses or to close matching brackets. Other languages might not have the same wondrous ability simply because their syntax is more complex. Their tools though clearly allow much better actual structural editing and actual semantic reasoning about code.
- didibus 9y ago
  > So, people keep assuming that I for some reason have never tried paredit (or written anything in Lisp) If you have, its surprising that you believe IntelliJ's PHP editor to be a full structural editor then. > Paredit is a very dumb tool that only works because Lisp's syntax is regular. There's nothing semantic or structural about the ability to move some words in or out of parentheses or to close matching brackets. Yes, it is a very dumb tool, but because Lisp's syntax is so simple, it makes implementing a structural editor for it trivial like that. So in return its a benefit. That's why a lot of simple regular syntax languages like XML often have structural editors for them too, because of how easy it is to make one. > Other languages might not have the same wondrous ability simply because their syntax is more complex. Their tools though clearly allow much better actual structural editing and actual semantic reasoning about code. I'm not saying that certain IDEs for certain languages don't offer great features which allow edits to be made in ways that are semantically aware and maintain syntactically valid structure. I'm saying that those languages don't offer full on structural editors of their code. So when writing and editing the code, you do so as text, without taking structure into account. Yes, your syntax errors will be highlighted, yes you can perform certain structural refactorings, but the editor is textual and not structural. If you have experienced both, it should be pretty obvious that they feel and are very different. I don't claim one to be better then the other, I think both are great, but it also depends on the language. If Java had a structural editor it might be more annoying then it'd be helpful. For Lisps it is amazingly useful, more so then what IntelliJ does for PHP. With Lisps, I'd rather have paredit then a background AST which allows me refactorings, auto-complete and error highlighting. But off course, those are fortunately not mutually exclusive and I have those also.
  - dmitriid 9y ago
    > If you have, its surprising that you believe IntelliJ's PHP editor to be a full structural editor then. Because, unlike paredit, it actually knows about the structure of my code. > That's why a lot of simple regular syntax languages like XML often have structural editors for them too, because of how easy it is to make one. Yeah. It's not "structural". It's just parens-matching and a few very basic actions like "surround with parenthesis". Lispers praise it like a gift from god only because there are no proper tools. > So when writing and editing the code, you do so as text, without taking structure into account. I see this bullshit repeated again and again. All paredit does is: select this word, select this thing in matching parentheses, move them around. Somehow this makes it a magical structural editor unlike the "just text" of other editors. Once again: no programmer in the world thinks or works with code in terms of words and paragraphs. The only thing paredit does is select words between matching symbols. It doesn't make it more structural or semantic than editing PHP in IDEA. It's just a somewhat convenient way of editing text with regular grammar.
    - didibus 9y ago
      > Because, unlike paredit, it actually knows about the structure of my code. I feel like you mean semantics here maybe. Anyways, knowing about the structure of code does not make an editor structural. It has to provide editing mechanism that are based around the structure. Its hard for me to explain, but basically it would be something like if you wouldn't be allowed to type code out of a class or function. You'd need to first add a function, which would always insert a fully valid signature with open and closing bracket, name and all, even if placeholders. So snippets sometimes do that, but they really do it as textual convenience, and its not enforced in any way. You would not be allowed to move half of an assignment by itself, you'd need the full assignment, things like that. So that every edit performed would result in valid syntax after they are performed. Valid syntax, not working code, not code that semantically make sense, just the syntax is valid within the syntax rules. Most IDEs do not provide this. What they do is they syntax check your text on every text edit. So as you add or remove characters, they re-run a syntax check, and highlight your mistakes. But your edit commands are addCharacter(), removeCharacter(). Its not addFunction(), switchAssignment(), wrapInConditional(), deleteVariable, etc. Some of those are available as commands on top of the text editor, but the editor is still textual, and you can not fully write and edit code structurally. Again, I'll quote the wikipedia article which makes this pretty clear: """ However, most source code editors are instead text editors with additional features such as syntax highlighting and code folding, rather than structure editors. The editors in some integrated development environments parse the source code and generate a parse tree, allowing the same analysis as by a structure editor, but the actual editing of the source code is generally done as raw text. """ > Yeah. It's not "structural". It's just parens-matching and a few very basic actions like "surround with parenthesis". Lispers praise it like a gift from god only because there are no proper tools. You're just trying to pick a battle here. I'm making no claim in terms of Lisp vs OtherLanguage. Paredit does meet the criterion for being classified as a structural editor for Lisp code. Yes, Lisp syntax makes meeting the criterion really easy, and paredit is not a complicated piece of engineering marvel, but its a complete structural editor for Lisp code none the less. Eclipse with Java does not meet the criterion. IntelliJ PHP editor does not meet the criterion. This does not mean that Lisp is superior to PHP or Java, or even that it has better tooling. It just means they don't have structural editors, and honestly, they probably don't need one. In Lisp, the benefit of a structural editor is mind blowing. That's why Lispers praise it like a gift from god. Without it, I would probably dismiss Lisp's syntax as too painful to work with. Yes, it provides the most powerful meta-programming of all other language, but the small things, like messing up your parenthesis balancing, or having to juggle forms in and out of each other is enough to throw off a lot of developers. So paredit is like a godsend, because it completely alleviates those pain points, and turns them into strengths. In that regard, it is unfair to judge Lisp's syntax before you've mastered and used it with paredit or similar structural editors. > It doesn't make it more structural or semantic than editing PHP in IDEA. It makes paredit a structural editor for Lisp code, whereas IDEA is not a structural editor for PHP code. That doesn't mean Lisp is superior to PHP, it doesn't mean paredit is superior to IDEA. Structural editor is not a vague abstract concept, its a concrete kind of editor, read the Wikipedia page. If you tell me, hey go use IDEA for PHP and it has a structural editor. And I buy a license, I'd be like, what the hell, this is not a structural editor. Its as simple as that. You can't just redefine what a structural editor is or isn't. They've existed for more then 30 years now, there's a common notion of what it is and what to expect. > It's just a somewhat convenient way of editing text with regular grammar. Yes, and that's what a structural editor is. Its when instead of editing text as free form, you edit it with respect to the grammar. I quote the wikipedia page again: """ structured editors allow the viewing and manipulation of the underlying document in a structured manner """ That's all. Having said that, yes, it can be confusing what is the difference between that and having an editor which syntax check as the text is edited. That's why there's a mention of this on the wikipedia page which I have now quoted many times. Now, Eclipse has the UML editor for Java, that is actually a structural editor to some extent, but most Java devs hate it.

dmitriid 9y ago

> You were probably downvoted too because you keep assuming other people talking about structural editing have never used IDEs coming from a person who also wrote this: > You were downvoted because what you said shows that you do not understand what paredit is. > I'd recommend you read ... to better grasp the concept. So, people keep assuming that I for some reason have never tried paredit (or written anything in Lisp). So why don't I give you a taste of your medicine. I suggest that you go and read some documentation on the IDEs I mentioned and try and use them to better grasp the concept. Paredit is a very dumb tool that only works because Lisp's syntax is regular. There's nothing semantic or structural about the ability to move some words in or out of parentheses or to close matching brackets. Other languages might not have the same wondrous ability simply because their syntax is more complex. Their tools though clearly allow much better actual structural editing and actual semantic reasoning about code.

didibus 9y ago
> So, people keep assuming that I for some reason have never tried paredit (or written anything in Lisp) If you have, its surprising that you believe IntelliJ's PHP editor to be a full structural editor then. > Paredit is a very dumb tool that only works because Lisp's syntax is regular. There's nothing semantic or structural about the ability to move some words in or out of parentheses or to close matching brackets. Yes, it is a very dumb tool, but because Lisp's syntax is so simple, it makes implementing a structural editor for it trivial like that. So in return its a benefit. That's why a lot of simple regular syntax languages like XML often have structural editors for them too, because of how easy it is to make one. > Other languages might not have the same wondrous ability simply because their syntax is more complex. Their tools though clearly allow much better actual structural editing and actual semantic reasoning about code. I'm not saying that certain IDEs for certain languages don't offer great features which allow edits to be made in ways that are semantically aware and maintain syntactically valid structure. I'm saying that those languages don't offer full on structural editors of their code. So when writing and editing the code, you do so as text, without taking structure into account. Yes, your syntax errors will be highlighted, yes you can perform certain structural refactorings, but the editor is textual and not structural. If you have experienced both, it should be pretty obvious that they feel and are very different. I don't claim one to be better then the other, I think both are great, but it also depends on the language. If Java had a structural editor it might be more annoying then it'd be helpful. For Lisps it is amazingly useful, more so then what IntelliJ does for PHP. With Lisps, I'd rather have paredit then a background AST which allows me refactorings, auto-complete and error highlighting. But off course, those are fortunately not mutually exclusive and I have those also.
- dmitriid 9y ago
  > If you have, its surprising that you believe IntelliJ's PHP editor to be a full structural editor then. Because, unlike paredit, it actually knows about the structure of my code. > That's why a lot of simple regular syntax languages like XML often have structural editors for them too, because of how easy it is to make one. Yeah. It's not "structural". It's just parens-matching and a few very basic actions like "surround with parenthesis". Lispers praise it like a gift from god only because there are no proper tools. > So when writing and editing the code, you do so as text, without taking structure into account. I see this bullshit repeated again and again. All paredit does is: select this word, select this thing in matching parentheses, move them around. Somehow this makes it a magical structural editor unlike the "just text" of other editors. Once again: no programmer in the world thinks or works with code in terms of words and paragraphs. The only thing paredit does is select words between matching symbols. It doesn't make it more structural or semantic than editing PHP in IDEA. It's just a somewhat convenient way of editing text with regular grammar.
  - didibus 9y ago
    > Because, unlike paredit, it actually knows about the structure of my code. I feel like you mean semantics here maybe. Anyways, knowing about the structure of code does not make an editor structural. It has to provide editing mechanism that are based around the structure. Its hard for me to explain, but basically it would be something like if you wouldn't be allowed to type code out of a class or function. You'd need to first add a function, which would always insert a fully valid signature with open and closing bracket, name and all, even if placeholders. So snippets sometimes do that, but they really do it as textual convenience, and its not enforced in any way. You would not be allowed to move half of an assignment by itself, you'd need the full assignment, things like that. So that every edit performed would result in valid syntax after they are performed. Valid syntax, not working code, not code that semantically make sense, just the syntax is valid within the syntax rules. Most IDEs do not provide this. What they do is they syntax check your text on every text edit. So as you add or remove characters, they re-run a syntax check, and highlight your mistakes. But your edit commands are addCharacter(), removeCharacter(). Its not addFunction(), switchAssignment(), wrapInConditional(), deleteVariable, etc. Some of those are available as commands on top of the text editor, but the editor is still textual, and you can not fully write and edit code structurally. Again, I'll quote the wikipedia article which makes this pretty clear: """ However, most source code editors are instead text editors with additional features such as syntax highlighting and code folding, rather than structure editors. The editors in some integrated development environments parse the source code and generate a parse tree, allowing the same analysis as by a structure editor, but the actual editing of the source code is generally done as raw text. """ > Yeah. It's not "structural". It's just parens-matching and a few very basic actions like "surround with parenthesis". Lispers praise it like a gift from god only because there are no proper tools. You're just trying to pick a battle here. I'm making no claim in terms of Lisp vs OtherLanguage. Paredit does meet the criterion for being classified as a structural editor for Lisp code. Yes, Lisp syntax makes meeting the criterion really easy, and paredit is not a complicated piece of engineering marvel, but its a complete structural editor for Lisp code none the less. Eclipse with Java does not meet the criterion. IntelliJ PHP editor does not meet the criterion. This does not mean that Lisp is superior to PHP or Java, or even that it has better tooling. It just means they don't have structural editors, and honestly, they probably don't need one. In Lisp, the benefit of a structural editor is mind blowing. That's why Lispers praise it like a gift from god. Without it, I would probably dismiss Lisp's syntax as too painful to work with. Yes, it provides the most powerful meta-programming of all other language, but the small things, like messing up your parenthesis balancing, or having to juggle forms in and out of each other is enough to throw off a lot of developers. So paredit is like a godsend, because it completely alleviates those pain points, and turns them into strengths. In that regard, it is unfair to judge Lisp's syntax before you've mastered and used it with paredit or similar structural editors. > It doesn't make it more structural or semantic than editing PHP in IDEA. It makes paredit a structural editor for Lisp code, whereas IDEA is not a structural editor for PHP code. That doesn't mean Lisp is superior to PHP, it doesn't mean paredit is superior to IDEA. Structural editor is not a vague abstract concept, its a concrete kind of editor, read the Wikipedia page. If you tell me, hey go use IDEA for PHP and it has a structural editor. And I buy a license, I'd be like, what the hell, this is not a structural editor. Its as simple as that. You can't just redefine what a structural editor is or isn't. They've existed for more then 30 years now, there's a common notion of what it is and what to expect. > It's just a somewhat convenient way of editing text with regular grammar. Yes, and that's what a structural editor is. Its when instead of editing text as free form, you edit it with respect to the grammar. I quote the wikipedia page again: """ structured editors allow the viewing and manipulation of the underlying document in a structured manner """ That's all. Having said that, yes, it can be confusing what is the difference between that and having an editor which syntax check as the text is edited. That's why there's a mention of this on the wikipedia page which I have now quoted many times. Now, Eclipse has the UML editor for Java, that is actually a structural editor to some extent, but most Java devs hate it.