Wiki-based IDE

[David Barbour]

Quantity, in the right environment, is a powerful basis for quality.

A wiki-ide as a web service could host tens of thousands of projects - apps, services, extensions. Each project may define hundreds of words - functions, documentation, automatic tests, configurations. Each word would keep a long, linear history. All these words coexist in a flat, global namespace such that they are easily used without boiler-plate import/export statements. 

Since about 2007, I've envisioned a wiki-based development environment. I wrote a bit about it years ago (http://c2.com/cgi/wiki?WikiIde). My vision has since evolved and refined.

To mitigate the conventional issue with huge flat namespaces - e.g. of `foo.projectQux bar.projectQux baz.projectQux` becoming verbose, difficult to read, and painful to write - I would use a editor that can substitute rendering of common prefixes or suffixes with color and style (configurable on-the-fly per user), and that supports auto-completion with fuzzy find. Hypothesis: if color is used well, it could improve readability far beyond conventional languages. 

These days, I favor the notion of "documentation words" as a replacement for comments. Each word `foo` could optionally be documented by `doc.foo` (leveraging a simple naming convention). This enables `doc.foo` to be a function that *generates* documentation, and thus can be refactored, abstracted, and templated just like any other function. I'm interested by possibility of interactive or live documentation, e.g. with full tutorials, puzzle solving, and examples kept up-to-date.

Tests in such a wiki environment could be automatic, zero button, again using a naming convention like `test.foo`. Developers could be told in real-time when they've caused a test to fail or pass. With many projects in a single wiki, integration testing is also quite feasible. 

Some words could also feasibly correspond to a spreadsheet, e.g. `b3$qux` might be a word containing the definition of cell b3 in spreadsheet qux, and be rendered accordingly. I think this an interesting possibility as an alternative to conventional REPL.

Not every PL is equally fit for use in a wiki.

We don't need import/export statements. We don't need a local syntactic way to define words/functions. Conventional structures with named fields/methods are somewhat dubious in utility.  Continuous testing is hugely aided in capability-secure languages because they can easily mockup environments.

I believe that concatenative PLs (e.g. Forth, Factor, Kitten, AO) are a great fit with wiki words, excellent for abstraction (common internal-to-function boilerplate can be refactored)... and even a pretty good fit for type-driven auto-complete. The main weakness of concatenative PLs is the difficulty of visualizing the stack/environment. This weakness would be mitigated by a good editor that can continuously render type information and/or live examples.

I plan to create such an environment for my language, AO, after it bootstraps and compiles. 

(At the moment, I have a more conventional file-based environment and REPL interpreter... and I'm trying to wrap my head around a fixpoint combinator so I can implement the loop words.)

Anyhow, I believe a wiki-based environment can potentially reward growth, whereas most languages seem to punish it. However, integrating many projects into one flat namespace is essential to achieve these benefits.

On Sat, Jan 4, 2014 at 6:00 AM, spir <denis...@gmail.com> wrote:

On 01/04/2014 01:30 AM, David Barbour wrote:

>Few programmers take the time to master a language/library/system.
>  Languages with cookbook answers that are easy to find become more popular.
>
>

True. And this useful observation is, in part, why I'm interested in a more
wiki-based development environment.

What do you mean? (in part.: development of the lang itself, or of apps?)

Denis

--
--
send mail     : pi...@googlegroups.com
unsubscribe   : pilud+unsubscribe@googlegroups.com
home page     : http://groups.google.com/group/pilud
subscribe     : send a short post to   denis <dot> spir <at> gmail <dot> com
Note: reply address is set to the list -- no need to "reply all"

--- You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.