6 ms·

I've given this a lot of thought, because I'm working on a couple of vaguely similar projects. My conclusion so far is that pretty-printing is great, but enfor

by ken 15y ago

I've given this a lot of thought, because I'm working on a couple of vaguely similar projects. My conclusion so far is that pretty-printing is great, but enforcing structural constraints in the editor (beyond perhaps something like ParEdit) tends to cause more trouble than it's worth. Consider the transformations you might do on a piece of source code while you're playing around. A lot of these (for me, anyway) are things which change not just position or name, but the part-of-speech of words, or temporarily make a nonsensical expression. (I do it in my shell a lot, too.) Rigid structure-enforcing editors hinder this. So for Lisp, either you end up with something that's less useful than Emacs, or something that's just a thin display layer on s-exps (which is fine, but not game-changing) and then users have to understand s-exp editing anyway. The fact that the names of special forms, functions, and variables are all symbols in Lisp is not mere coincidence. This highlights one of the big frustrations I have with most programming languages: they optimize for making a section of code look good and concise, but as a programmer I want a language that also optimizes for my changes being concise. For example, C# can look pretty decent in many cases, but changes which are conceptually simple can be huge diffs. Quoting an expression in Lisp is literally one character, but it takes 5 lines to quote a print statement in C# <http://msdn.microsoft.com/en-us/library/y2k85ax6.aspx> http://msdn.microsoft.com/en-us/library/y2k85ax6.aspx>, and anything nontrivial grows painfully fast. This is why it's impossible for me to truly assess something by looking at sample code, or a screenshot -- so don't take this as a criticism of Pretty Lisp! It could be that as we move higher up the abstraction scale this becomes less important. After all, Mel wouldn't be happy at such a high level as "characters". But I think there's something fundamental about the concept of quoting symbols -- 'using something as something else' -- whether those symbols are bits or characters or round-rects. The #' in the screenshot here looks out of place, as if the author didn't know quite what to do with it. I look forward to see what the author can make of this (new ideas and experimentation are great!) but I don't see anything here yet that jumps out at me as revolutionary, or must-have functionality.

ken 15y ago
I guess that sounds like kind of a downer (even though I said I liked experimentation and didn't want to make it sound like criticism of this particular implementation). I think there are definitely paths forward here, and my hunch (which you shouldn't listen to, because I don't know anything) is that the most promising one would be some combination of some/all of: - Not use Common Lisp as a base. Lisp is great, but reader macros and visualizations are a really tough combination. - Come up with a good visualization for quoting. If your fundamental units of computation are "symbol/word" and "box" (a neat concept to build a language around), then incorporate quoting into those things somehow. I don't have a good answer for you here, but I think this is the key to unlocking the whole thing. - Integrate with other tools (or upgrade them to this visual symbol/box world) that make good use of text today, like version control, sed/grep, or editor extensions (as in Emacs). If there was a programming environment that offered the same level of flexibility and power that I have today, but which was visual (and beautiful), I could see that being a very compelling upgrade. I'm fascinated by visual languages, and I find it unfortunate that they all seem to acquire visuals by sacrificing power.
timmy-turner 15y ago
> Consider the transformations you might do on a piece of source code while you're playing around. A lot of these (for me, anyway) are things which change not just position or name, but the part-of-speech of words, or temporarily make a nonsensical expression. (I do it in my shell a lot, too.) Rigid structure-enforcing editors hinder this. I hope that this can be mitigated by using an incremental parser (pretty easy to write for a lisp), which gracefully switches to a plaintext representation if the underlying code cannot be parsed anymore. The advantages of an editor which understands the code (both, syntax and simple semantics) you are writing or reading are just too promising.
- doty 15y ago
  I worked on a language once (now dead) which even had a syntactically valid form for parse errors, which allowed a structured editor to record a valid AST at all times. The "parse error" expression just raised a "parse error" exception at runtime, so you could even execute ill-formed expressions. It turns out to be fantastically empowering.
  - spitfire 15y ago
    Which language?
    - doty 15y ago
      http://en.wikipedia.org/wiki/M_(programming_language) http://en.wikipedia.org/wiki/M_(programming_language)
spitfire 15y ago
You're absolutely correct. Right now we focus on moving text around. Where the magic will come in, as these sorts of things progress is developing interactions to move the ideas around. Moving further up the power curve is always a good thing. My comment was based on the concept and my interpretation of those concepts in the future. Not necessarily on the reality right now.
- jerf 15y ago
  We've done a lot of moving up the curve. Generally, when you move up the curve, there's a way to serialize it as text. Then, you might as well actually do so, and use all the advantages of a textual representation to use the abstraction. Compare a concise Haskell specification of something with the C equivalent. The problem with people who seek to replace our glorified text editors that we use for source code editing is not that they don't understand the disadvantages of the format... it is that they don't understand the advantages. Consequently, proposals for replacement tend to throw away huge swathes of functionality without realizing it, then start from a functionality deficit nearly impossible to recover from. It's actually hard to beat text. There's a reason we're communicating in text right now, and it isn't a lack of creativity or lack of attempts at other solutions to the problem or any of the other memes trotted out every time this topic comes up.
  - idlephilosopher 15y ago
    What would you list as the advantages of text-based editing that replacements miss?
  - Detrus 15y ago
    I think it is a lack of creativity. Also a lack of serious attempts and minimal refinement in successful attempts like labview. Take the simple case of naming. In plain text, the name of a function is its unique ID, more or less. Some language cultures love long descriptive names like BattleResourceMediator.getMediatorInstance(). Well such names can be broken up into tags. [Battle Resource] [Mediator].[get][Mediator][Instance]. Then when you don't need to know it's a mediator instance you'll see [Battle Resource].[get]. If you need to see what's a mediator and what's a factory, turn on some deeper editing mode and swim in verbose boilerplate. You're not going far from text, just augmenting it with simple ideas we use in bookmarking. You can go further, add tags to sections of code to rate and label it as readable, hand optimized, quick & dirty, reviewed, etc. Simply a better UI for documentation, so in a zoomed out view of a project you can see at a glance how much is hand optimized. Also watch this video https://vimeo.com/36579366 https://vimeo.com/36579366 and notice the sorting code walkthrough. A simple case of refinement where you put output side by side next to the code and format it properly. We'll need a lot more refinements like this, which means more attempts, more creativity.

by ken 15y ago

ken 15y ago

I guess that sounds like kind of a downer (even though I said I liked experimentation and didn't want to make it sound like criticism of this particular implementation). I think there are definitely paths forward here, and my hunch (which you shouldn't listen to, because I don't know anything) is that the most promising one would be some combination of some/all of: - Not use Common Lisp as a base. Lisp is great, but reader macros and visualizations are a really tough combination. - Come up with a good visualization for quoting. If your fundamental units of computation are "symbol/word" and "box" (a neat concept to build a language around), then incorporate quoting into those things somehow. I don't have a good answer for you here, but I think this is the key to unlocking the whole thing. - Integrate with other tools (or upgrade them to this visual symbol/box world) that make good use of text today, like version control, sed/grep, or editor extensions (as in Emacs). If there was a programming environment that offered the same level of flexibility and power that I have today, but which was visual (and beautiful), I could see that being a very compelling upgrade. I'm fascinated by visual languages, and I find it unfortunate that they all seem to acquire visuals by sacrificing power.

timmy-turner 15y ago

> Consider the transformations you might do on a piece of source code while you're playing around. A lot of these (for me, anyway) are things which change not just position or name, but the part-of-speech of words, or temporarily make a nonsensical expression. (I do it in my shell a lot, too.) Rigid structure-enforcing editors hinder this. I hope that this can be mitigated by using an incremental parser (pretty easy to write for a lisp), which gracefully switches to a plaintext representation if the underlying code cannot be parsed anymore. The advantages of an editor which understands the code (both, syntax and simple semantics) you are writing or reading are just too promising.

doty 15y ago
I worked on a language once (now dead) which even had a syntactically valid form for parse errors, which allowed a structured editor to record a valid AST at all times. The "parse error" expression just raised a "parse error" exception at runtime, so you could even execute ill-formed expressions. It turns out to be fantastically empowering.
- spitfire 15y ago
  Which language?
  - doty 15y ago
    http://en.wikipedia.org/wiki/M_(programming_language) http://en.wikipedia.org/wiki/M_(programming_language)

spitfire 15y ago

You're absolutely correct. Right now we focus on moving text around. Where the magic will come in, as these sorts of things progress is developing interactions to move the ideas around. Moving further up the power curve is always a good thing. My comment was based on the concept and my interpretation of those concepts in the future. Not necessarily on the reality right now.

jerf 15y ago
We've done a lot of moving up the curve. Generally, when you move up the curve, there's a way to serialize it as text. Then, you might as well actually do so, and use all the advantages of a textual representation to use the abstraction. Compare a concise Haskell specification of something with the C equivalent. The problem with people who seek to replace our glorified text editors that we use for source code editing is not that they don't understand the disadvantages of the format... it is that they don't understand the advantages. Consequently, proposals for replacement tend to throw away huge swathes of functionality without realizing it, then start from a functionality deficit nearly impossible to recover from. It's actually hard to beat text. There's a reason we're communicating in text right now, and it isn't a lack of creativity or lack of attempts at other solutions to the problem or any of the other memes trotted out every time this topic comes up.
- idlephilosopher 15y ago
  What would you list as the advantages of text-based editing that replacements miss?
- Detrus 15y ago
  I think it is a lack of creativity. Also a lack of serious attempts and minimal refinement in successful attempts like labview. Take the simple case of naming. In plain text, the name of a function is its unique ID, more or less. Some language cultures love long descriptive names like BattleResourceMediator.getMediatorInstance(). Well such names can be broken up into tags. [Battle Resource] [Mediator].[get][Mediator][Instance]. Then when you don't need to know it's a mediator instance you'll see [Battle Resource].[get]. If you need to see what's a mediator and what's a factory, turn on some deeper editing mode and swim in verbose boilerplate. You're not going far from text, just augmenting it with simple ideas we use in bookmarking. You can go further, add tags to sections of code to rate and label it as readable, hand optimized, quick & dirty, reviewed, etc. Simply a better UI for documentation, so in a zoomed out view of a project you can see at a glance how much is hand optimized. Also watch this video https://vimeo.com/36579366 https://vimeo.com/36579366 and notice the sorting code walkthrough. A simple case of refinement where you put output side by side next to the code and format it properly. We'll need a lot more refinements like this, which means more attempts, more creativity.