Earlier quoted context omitted.
Text is a raw data structure, it's just not the one that's used behind the scenes: Everything is a datastructure. And actually I do touch the data by manipulating text. >From the sidelines, your approach is "all I have are nails and all I need is the biggest hammer you can get me". From my perspective, my approach is "that development environment sounds really unpleasant, and while I can appreciare the elegance, I'm…
When your editor's cursor hovers over "transistor T1" do you in fact touch the transistor on the board over your desk, the transistor in the schematic diagram, or only the text that happens to be "1T rotsisnart" spelled backwards (with no underlying meaning that is)? Data representation is not the data. It's just this: "re" presenting. And when this representation is disconnected from the source by means of showing o…
>And when this representation is disconnected from the source by means of showing only the raw text and not allowing access to the source you get what you describe as "unpleasant".
First off, pleasantness of an interaction is a matter of personal opinion. If you like DEdit, great: I'm not stopping you. But I don't enjoy DEdit and its like. That's my prerogative.
Secondly, I'm not working "only with raw text." Paredit &co let me manipulate the sexpr data structure more directly (or less directly, depending on how you look at it). Geiser and SLIME let me evaluate and manipulate the code as code. But at the end of the day, I'm also operating on text, so I have all of the textual data tools as well, and because Paredit is actually operating on text, it can be used outside of the context of Lisp: As Perlis said, "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."