OK. You completely miss the point.

Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.

Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.

Well, you really have to try it first to understand the difference.

Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.

And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.

Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)

I can't. Because I do not use Xiki. I use something much simpler coded in VIM.

But the paradigm as I use it, in VIM terms: the command and the output are kept in the same editor window. You can apply exiting VIM functions to both - commands and output. You can save and load both at the same time - since in the essence it is an ordinary text file. With a special ':g//' I can rerun all the statements in file at once. Or I can selectively rerun only particular ones by the mask. I can ':w' and it is all made persistent. (My small creation was born first as a text file to keep the shell pipelines I use often. But with a VIM macro I have integrated also the output of the commands into the file. And then I given names to the commands. And then I allowed in pipes to refer to other pipes by the given names. After adding folding, it is still mostly looks like a text file with shell pipelines. Replaced bunch of terminals I used to keep open to run small monitoring/diagnostic commands. And a calculator, which I use most often (iow, a text file full of formulas, which I can copy/paste/modify and recalculate).)

Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.

I already do something similar in VIM, and xiki is far from been the same as ":r!". You probably should watch the first screencast.

The xiki thing is basically a Ruby shell, with built-in free-form text editor. But primarily it is a wrapper around the Ruby. Thus it limits its appeal to mostly Ruby users and developers.

The concept is definitely interesting. It basically brings back to CLI some capabilities that many have given up to GUIs. Adding something like this to an editor like VIM is definitely possible, but not trivial, since VIM's support for scripting and scripted buffers is very limited.

OTOH the xiki reminds me of what Emacs does to the shell prompt. Unfortunately, Emacs' integration with the shell ends with the repetition of commands and copy-paste from the buffer. Xiki goes a step further.

I use vim almost exclusively (windows or linux), and use it for PHP, Perl, and C++.

It just works, why get all fancy?

Ruby 1.8, which was superseded in 2009 and completely discontinued in 2013.

The majority of the standard library is written in Ruby. The handful of extensions typically have native Java versions under JRuby (and I believe in Ruby under Rubinus).

It may not be "wrong", but it is significantly incomplete. The language has multiple first class implementations, in multiple languages. But the broader point was not the implementation language (which I point out is C in several examples) but other languages in the same class are not interpreters in the classic sense. They are almost universally virtual machines, either from the beginning (like python) or at some point in their evolution (like Ruby, TCL, PHP, etc).

There are many arguments against adding the IDE, but I don't agree with this one. People said the same thing when Google came out with Gmail. "We've already got hotmail and yahoo and a million other free email services. Why do we need another?" If this tool is good enough or simple enough to use that it becomes ubiquitous, then it doesn't matter what's already out there.

- Perl 5 and earlier: An interpreter written in C.

Not exactly. The interpreter compiles the source files into a bytecode and executes it on a stack-based virtual machine: ahref=http://perlbin.sourceforge.net/perlcompiler/perl.internals.pdfrel=url2html-14852http://perlbin.sourceforge.net...>

- Python: An interpreter written in C.

A virtual machine in C: http://www.troeger.eu/files/teaching/pythonvm08.pdf

- Ruby: An interpreter written in C.

A virtual machine in C: http://en.wikipedia.org/wiki/YARV

Or in C++: http://rubini.us/

Or against the JVM (which is written in C++): http://jruby.org/

- Lua: An interpreter written in C.

A virtual machine in C: http://www.lua.org/doc/jucs05.pdf

- Tcl: An interpreter written in C.

A virtual machine in C: https://www.tcl.tk/community/tcl2002/archive/Tcl2002papers/kenny-bytecode/paperKBK.html

- PHP: An interpreter written in C.

Hey, you got one. However the they are currently revising the language to make it compatible with adding a JIT later: http://www.computerworld.com/s/article/9248637/PHP_keepers_plot_radical_revision_of_the_language

And Facebook has their own C++ VM: http://hhvm.com/

- UNIX shells: Interpreters written in C.

Different problem space.

The test is ridiculous.

In any (Perl) program more complicated that helloworld (and in Perl terms that could be already pretty sophisticated piece of code) most of the time would be spent on calling functions.

All the test accomplishes, is testing how well Perl itself is implemented. And that we know already. (This test is basically biased against Java, or in fact, any language with immutable strings. Java just tops it off with slow IO.)

That's the problem: performance of Perl5 with any kind of largish framework would be pretty miserable because Perl's interpretation model is not designed to handle it.

Literally all interpreters decades ago went with p-code interpreters - and only Perl5 is still stuck with the traditional interpretation by (slightly optimized) syntax tree.

In my personal tests I have seen a clear dependency between performance and the size of optree: larger the optree, slower the code.

With any kind of sizable framework, the optree would be enormous. While bytecode allows for more aggressive optimization (inlining or IPO or profile based optimizations; after all, bytecode is just data), optree is very hard to modify (it is structured and inter- and intra-linked).

Remote display is used only if you are locked into the Windows. And comes with bunch of little problems, of which stuck keys and broken clipboard (until server restart) are though most annoying, the least. Recently admins where I work had to reboot PDC simply because a disconnected remote session got stuck and server didn't allow new sessions because RDP supports only one session.

But that's on Windows, where people have no choice. On *NIX, there is no good reason to choose RDP/VNC over X+ssh. But if you wish, you can RDP/VNC too.

Do you even know what you are talking about? Wayland's official statement is that network support is out of scope. Because Wayland is an interface to *local* graphical subsystem.

As network support goes, Wayland has only recently gained support for the X protocol (aka X Server can use Wayland as a display driver).

Yeah, but I am fairly certain one will be able to buy an Amazon Fire Phone, unless one is really lucky at begging, one cannot buy a Oneplus One.

Dalvik is its own VM and bytecode specification.

As a minimum if you don't encrypt it before tossing it out onto unknown public and private networks you don't control, you've already said you don't care who sees / reads / hears / metabolizes your data.

That's just ridiculous. Since when the reliability is measured in how many petabytes can be written?

Spinning disks can be forced into inefficient patterns, speeding up the wear on mechanics.

SSDs can be easily forced to do a whole erase/write cycle just by writing single bytes into the wrong sector.

There is no need to waste bus bandwidth with a petabyte of data.

The problem was never the amount of the information.

The problem was always the IO pattern which might accelerate the wear of the the media.