Parinfer and typing/understanding Lisp

Now this is the kind of thing I love to see: Parinfer [hnn]. It uses indentation to show structure while inferring paren closure to preserve syntactic validity. You can switch back and forth between inferring parens or inferring indentation. It makes sense. This kind of thing is really exciting to see.

Gear Generator

Oh, sweet: a gear generator. Does exactly what it says on the tin.

Eco

Holier Toledo! Eco is a text editor that parses arbitrary languages on the fly and allows you to insert "language boxes" to embed other languages within them. The data structure actually saved is the composite parse tree, not the text, which is mildly alarming given the reliance of the existing programming infrastructure on text source code (although Laurence Tratt, the editor's promulgator, notes that Smalltalk has solved many of these problems).

This is really quite attractive. I can't think of a good reason it couldn't be duplicated in something along the lines of Padre, using Marpa.

JetBrains MPS

Holy Toledo - this is amazing! It's an editor/DSL integrated environment that allows you to compose your own DSLs into code in the editor, then autogenerate the output language when needed - through multiple levels of abstraction if necessary. Just watching the demo screencasts is making me smarter.

Anyway, this is kind of what I want to do, except, like the emperor in Amadeus, I find there are "too many notes". I need more simplicity. Maybe. Although damn. It sure is pretty. There's one embedded decision table - right in the C code - that gets translated into a C-like language with a "gswitch" statement and then further into straight C. That is tasty.

Flood

Flood seems to be primarily an editor for solid shapes to be made using 3D fabrication - but to get there, it implements a visual programming language that also embeds JavaScript.

Which is so incredibly cool.

Code Browser

A folding code editor. I think I'm going to evaluate it.

StackEdit

Here's a complete markup editor for formatting posts for StackOverflow and other markup-based stuff. It's bewilderingly good.

Conception IDE

Conception is a general IDE for assembling snippets and macros into code (that's probably an inadequate description). It looks pretty slick.

Data table editor for jQuery

And another nice drop-in component: a data table viewer/editor built on jQuery.

Outline editor Concord

Oh, this is nice - a drop-in outline editor component in open-source JavaScript.

Programming by voice

This is more manipulation of emacs by voice, but still: here. Writing Python by voice with emacs...

Simple online editor

Nice.  Integrates with Bootstrap.

Tern

Tern is to be a JavaScript analysis engine for embedding into editors.  The author made his Kickstarter goal, so the code will be open (still not sure what I think of this trend).

I'm ambivalent about Tern per se, but I really like the general idea of parsing editors; it's halfway to a semantic editor.

Authorea

Authorea is a scientific publication-specific editor in the browser.  That's pretty rock-n-roll.  Free for open science publications, paid for private publications.  Nice model!

Tiled Text Engine

Here's a really neat concept in editing of parsed text.  I like this a lot.

Upgoerfive text editor

Now here's a brilliant little idea: a JavaScript text editor that does stuff in the background for you (checking against a list of the ten hundred word people use most).  I just keep thinking in terms of local software when JavaScript is really your friend for UI interaction these days.

jsPlumb

Graphing UI library jsPlumb - very nice.  Too cartoony for my taste, but I'm sure it's all configurable.  The point is all the heavy lifting's already done.

CodeMirror

CodeMirror is a JavaScript-based online code editor that looks pretty darned snazzy.  I'd like to combine it with other representations of the code - eventually I think this is where I'll be doing for code editing.

Rich text editing

I'm kind of kicking the notion of rich text source code around in my head, although I'm honestly not sure it's a good idea.

The cheapest, easiest way for me to start doing this would simply be to kick some RTF out of Perl into a notes file and call Word on it.  If I go that route, Perl has some RTF support (RTF::Tokenizer) that will probably do what I need it to do.

Alternatives would be to be a different rich text editor.  Scintilla isn't it - but Wx does include a rich text control.  That's one route.  The other would be to run as a server and pop up a CKEditor window.  I have to admit I really like this notion.  (See also Maplat's DocsTextEditor; Maplat in general looks pretty cool and not entirely unlike what I'd like to do in this arena, in terms of the document management aspects.)

The obvious advantage to using a little server to serve up an app is that it's getting to be a lot easier to write UI as HTML5, and of course you get the remote option then.

Code editors again

So somehow I ended up with a bunch of tabs open with code development environment articles.

• IDEs are important to Java because Java has lousy code arrangement - lots of tiny files with framework-induced nomenclature.  So the IDE is a navigational tool.  That squares with my memories of working with Visual Studio back in the day - vast amounts of boilerplate and Studio was really necessary to find the good stuff.
• Textadept is a programming editor written mostly in Lua, that also uses Scintilla as the editor component.  This makes it kinda like Padre (no doubt why it has no Perl tools).
• Zen Coding is ... typing acceleration for HTML and CSS.

I have some pretty decent thoughts about these links, but it's late and the thoughts are rather inchoate.  Short version: every set of code is a text that is written in a formal language in order to express some carefully defined syntactic structures that can be translated into code or actions.  But - and this is again not a new insight - those syntactic structures are a reflection of the deeper semantic structures in the programmer's mind as she comprehends the problem to be solved.

The actual program may or may not solve that problem (hence the need for good testing), but its intent is to do so.  In reading code, we attempt to discover that intent and reconstruct the deep semantics.  What I'd like to do in an IDE and/or editor is to maintain something approximating those semantics in a structure during editing.  As that toolset improves, you could communicate with the editor on a higher level, interacting with the semantics and letting the toolset manipulate the specific code.

Because you don't actually care about the code any more than you care about assembler.  (Unless you care about assembler, but that's a different point.)  You want to solve your problem.

By looking at competitive programming problems and problem statements, I hope I'll be able to have small enough and abstracted enough snippets of semantics that it will be realistic to think about how the semantic comprehension of the problem statement is translated into program structure.