Context : SocialCoding, CloudBasedIDEs are getting closer.

Update : CardiganBay is my platform for experiments in this direction. Now allows ClojureScript to be embedded etc.

Other things getting closer GlamorousToolkit gets TiddlyWiki content and makes comments into SmartAscii :

https://blog.feenk.com/code-comments-as-live-wikis-in-ides-7mqg3clsbn5imjoxb5yj97ts2/

I added this here : http://www.c2.com/cgi/wiki?ProgrammingInWiki hoping in LazyWeb style someone would go out and implement it)

Why shouldn't programming be as easy as Wiki?

Easy to navigate, easy to document, easy to share comments, easy to peer review, programming by gradual accretion ... massive re-use through linking to defining WikiWords, can be programmed linearly, chaotically, rapidly.

Why shouldn't an IntegratedDevelopmentEnvironment be like Wiki?

Why shouldn't an IDE BE Wiki?

Why is programming harder than sketching algorithms and diagrams in a notebook?

Increasingly the PainOfProgramming? comes from managing such rigid development environments. Think of the multiple files we manage, in different languages, in different file systems. The XML configuration files. The SQL scripts to build databases etc.

Now imagine all these different files replaced by WikiPages.

Imagine if we could

  • embed all code (Java, perl, SQL, config data etc) in freeform text pages;
  • allow free text annotations, (Compare LiterateProgramming)
  • allow easy Wiki linking to related pieces of info :
    • from code to config "file",
    • from bug reports to code blocks,
    • code blocks to programmer homepages (with contact details)

At the moment WE do the hard job of arranging things for the environment. But a make script could easily crawl a Wiki picking up various pieces of code, data in order to build source files, config files, etc.

The make script would itself be written on a wiki page for easy reference. It could save the various components in their traditional places before calling the compiler.

My distinction between concrete and abstract in DoesAbstractionScale could be similar to code and data as described here : http://www.itworld.com/nl/ebiz_ent/03112003/

A Wiki based IDE would mix code, data and annotations on one type of page. It should support incremental development from concrete examples to abstraction and scripting, it would support LiterateProgramming

On http://groups.google.com/groups?selm=16e613ec.0304242346.6c54cd25%40posting.google.com&rnum=7&filter=0

jorn@enteract.com (Jorn Barger) wrote in message news:16e613ec.0304242346.6c54cd25@posting.google.com...

There seems to be a deep analogy between objects in object-oriented programming and pages in web-hypertext.

Jorn, I've been thinking a bit about this from a different angle. I've been building a personal wiki this year and I've started thinking about how to combine wiki's free style organization with a scripting language. The basic idea would be to allow certain "marked-up" fields or slots to be placed within pages.

Then the language could be used to write macros which could, for example, allow data from one page to be used in a dynamic calculation on another. But if the macro-scripts were also notionally placed in named slots on the pages, we'd effectively be able to write

PageName.methodSelector within the script. All pages would become potential objects.

Why do this? One reason is a kind of literate programming, but instead of embedding comments in code, embed code in free-form wiki pages. The wiki or hypertext nature of the collection of object descriptions would give the language the ease of organization and refactorability of wiki. Something I think would be a big improvement over other development environments.

Wiki is just a complex filter. Ideally it should be able to translate WikiCode to and from any other language, using some sort of ContextSensitivity to DoTheRightThing. WikiIsNotLimitedToHTML. If you're editing a C program, for example, the WikiEngine should be able to output dependencies for make, prerequisites for configure, necessary libraries for ld, RegressionTest scripts for maintainers, and HTML documentation for developers, as well as the actual annotated C source code. In the opposite direction, users may submit BugReports, FeatureRequests, and suggestions via the wiki. WikiWillAbsorbCVS and all other development tools.

On web-browsers

A web-browser gives me access to billions of pages (packets) of information through the same interface

In contrast :

a typical IDE makes me access different packets of information through different interfaces :

getting to the source code I'm working on is different from

getting to my UML diagram is different from

getting to the GUI form I'm designing

getting to documentation for the library I'm using is different from

getting to the "help" for the IDE itself is different from

accessing the database is different from

the command line where the program runs

etc.

A web-browser doesn't confuse things with overlapping windows or attempts to cram lots of things into little corner windows of the screen. Because it's so easy to flow from one page to another (and backwards with the BackButton) you can leave a page, safe in the knowledge you can easily return to it.

With Google I can search those billions of pages through a single interface. Once again, I can seldom do this in an IDE

The tabbed web-browser model is interesting. In most MultipleDocumentInterface type applications a window contains one document or application. In a web-browser each window or tab is bound to a separate navigation history. Or to put it another way, the frames are dynamically (or late) bound to documents. In MDI frames are statically bound. If you want to open a new document, you open a new window and vice versa. This creates a certain extra complexity and cognitive cost to opening and closing documents which doesn't occur in the web-browser model. (LateBinding)

See also :