We should be indistinguishable from magic by now. This is a (small) step in the right direction.
Can we please live in the future already?
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>, 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.
- 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.
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.
It turns out to be fantastically empowering.
My comment was based on the concept and my interpretation of those concepts in the future. Not necessarily on the reality right now.
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.
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 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.
Agreed. I think this has something to do with the fact that programming is not about the objects on screen themselves, it's about the interaction that occurs between those objects and the mind of the person looking at them. The objects are not real, but mere representations.
Therefore, the interaction I have with a block of code is defined by my experience wrestling with the problem at hand in the language of that block, during which my brain has "mapped" from the text to a sort of abstract visualization of its value (or "serialized", as you put it).
I don't think a tool that makes a "picture-block" for me will ever help. My brain has to do the work of understanding those blocks by compressing each text block into a form (block? graph node? neither?) that I can hold in my head.
Strangely enough, if the above is correct, that means that there is more value in implementing a tool like this (for the implementor) in $LANGUAGE than there is for a potential user. Perhaps this is why programmers keep writing them, and users keep on not using them.
As the user, I need to learn something either way, and learning is usually hard/expensive. Therefore, why learn the (imperfectly-mapped) "picture-block" abstraction at all?
It'd be interesting to see if programmers feel the need to keep using these sorts of tools them once they've written them. My guess is no.
Also, check this out: http://www.foldr.org/~michaelw/emacs/mwe-color-box.el (you can see a screenie in http://www.foldr.org/~michaelw/emacs/color-box.png)
Edit: Now I see that I didn't notice that this situation happens in the "let maxcol 0" line in that image. I need to compare the colors on the line below to make sure I'm mentally parsing that line correctly.
Seriously though, I actually prefer working with text, even here.
Also, I think this could be improved by making "meta" symbols like defun into different shapes rather than just including them as words. So a definition would look like a different box than a normal statement. Probably the same for &optional. Of course, this wouldn't work for user-defined macros or functions, but it would be nice if just for the standard ones.
Sure, there may be some fonts and indentation and colors. (Eclipse and VS use those, too.) But the text is the point.
It's the same with code. Code is a means of expression, best treated as text. Every attempt at turning it into something graphical always reduces the expressiveness.
Then we went to san serifs (like here on HN) and then to monospaced code fonts. It's a long line and a lot of work by designers.
Adding to this medium will also take a lot of work. An essay can be more expressive when various ideas in it are turned into visualizations. Writers of long novels use special writer software to keep track of which characters interact with what others, to create family charts, friend charts, event timelines, etc.
These don't replace text, they augment it. And it would be interesting to have a macro view of the book through such tools for readers someday.
Not every attempt reduced the expressiveness of code. Syntax highlighting is graphical. Labview is graphical. Short compile cycles so the programmer can see what he's doing is graphical. Great demo of that here https://vimeo.com/36579366
Just because this particular attempt at pretty lisp leaves much to be desired doesn't mean we should stop attempting. Simple programmer tasks like naming can be improved if we move away from plain text as the medium, more detail here http://news.ycombinator.com/item?id=3633740 and http://news.ycombinator.com/item?id=3651257
Augmenting the text with graphical representations is a wonderful idea, that IDEs already perform in many ways, with many more yet to be discovered.
However, it's one of the more useful code/program visualizations I've come across.
Licensing isn't an issue - $3K/year+libraries for development. A runtime player for Mathematica costs $300. You just have to pick your projects carefully - No rails todo apps.
One recent project I worked on was auto segmentation and labelling of MRI images. Auto-segmentation was the easy part. Labelling however took several different approaches before I got something that works reliably.
A lot of my other work is much less suited to matlab. Mathematica is certainly much better for multi-domain work, which matlab barely supports.
One aspect that seems to be brought up about MatLab often is the community, it's often claimed, especially in the co punter vision world, that if an algorithm exists, it has an available implementation in MatLab source. Which seems significant.
I'm sure some LISP editors have this too, but in a m-expression language like Mathematica it seems like magic.
Sorry!
Is there a demo available somewhere?
Perhaps it would be better to call it a 'Domain General Language' for everything.