Re: Great SWT Program

On Nov 18, 6:44 pm, twerpina...@gmail.com wrote:


Your point being...?

Given that I do a lot of remote work over the internet at large, I
can't rely on high speed connections to arbitrary hosts -- which
precludes frequently transferring files larger than a few tens of KB
back and forth. Since I often work with several files out of several
codebases, and rarely know in advance exactly which files I need to
work with at the start of a task, I can either

 a) download entire copies of each project in advance, which is slow,
or
 b) download each file on demand, which precludes things like
searching for references to a symbol (since it would have to download
the whole project anyways).
 c) work on the remote machine directly.

Text-mode tools are by far the most amenable to c), and I rely on ad-
hoc manipulation of the workspace far too much to do b) or a)
confortably.

On the other hand, when working locally I use a hybrid of command-line
and graphical tools. Bash is an extremely powerful automation tool,
for all its faults, and the various shell commands that come with unix
complement it well. The GUI tools I use (sometimes including emacs)
have a lot of long-established synergy with them, but are also fully-
fledged GUI applications. Because some workspaces are local, I can
take advantage of the effectively-unlimited bandwidth in my work
habits.

I'm willing to bet that both Bent and blmblm have a fairly similar
profile on the matter.

There is simply no one "right way" to edit text, to write code, to
author articles, to pen a book. Sometimes you have external
constraints that make working remotely the most straightforward way to
accomplish the job. Would you rather work on a responsive UI (that
uses under 1kb/sec to propagate updates and events, but is in exchange
parsimonius) or an unresponsive UI (that displays a lot more
information, but consumes a large amount of bandwidth when updating
the display)? There are no middle ground options that exist right now
between these two extremes (which do exist).


With existing tools, such an environment is rather unpleasant to use.
I've tried it: for example, MacFUSE has an sshfs driver allowing me to
mount sftp services as volumes, or I can use either command-line or
GUI sftp clients to fiddle files around while working locally on
remote files. I found the former to be unpleasantly slow over the
internet and the latter to involve a lot of mental task switching
between "what I'm doing" and "where are the files". On the other
hand, opening emacs on a remote machine in text mode consumes around
than 2kb of actual traffic (for most texts at my default terminal
size), and I tend to only open it when I know where in the file I want
to go anyways. It opens quickly, I'm already comfortable with it, and
it involves a lot less mental effort than switching out of the
terminal, downloading the file somewhere, opening it, making my
changes, and uploading the file back.

If you have some stunning insight into making the process more
streamlined and more transparent, by all means, write the code and
sell it, or share it out of altruism.


Even that's not a good assumption to make. Like many unix users, I've
been using bash for a few years; I tend to keep some of my work state
in shell variables so I can refer to it later in the same session.
Having that state go away without warning is frustrating. Frequently
it means reconstructing the values (often URLs; I use this approach
for subversion and mercurial particularly), which is a tedious amount
of typing -- hence the shell variables. Using screen moves the most
likely point of failure from "the network connection dying", which is
almost certain given enough time, to "screen or the shell crashing",
which is rather less likely, empirically: it's never happened to me or
anyone I could find online at 23.00.

Plus, I can work on some remote-as-in-internet system on my laptop
from a cafe, fold the laptop away without ending the session, and come
back to it later from my desktop at home without having to fire the
laptop up first to recover my state from it. That's a pretty useful
thing for me.


And if pigs grew wings they could fly.

I2 is not going to "replace" the internet; as has already been
happening for years, useful technologies developed for I2 will be
integrated with the existing internetnetwork, organically, when they
mature. I2 itself is just a set of eye-wateringly expensive network
links between some research facilities and universities; the quality
and capacity involved has scaled to remain unfeasible for the internet
at large even as the bandwidth of the internet has grown and will
probably continue to scale until various theoretical limits involving
information density are approached.

Meanwhile, I have remote systems to work on *now*, not in some future
utopia where bandwidth saturates the air, multicast actually works,
and reliability and latency aren't problems. I also have local
systems to work on *now* that have effectively unlimited, or close
enough to make no difference, bandwidth. I have tools which work well
in either, and tools which work well in both, circumstance. If you
don't have some of the same needs, it's not surprising that you don't
find much value in some of the tools.

But I don't think you're stupid (rather the opposite) for using the
tools that best fit your work environments. You, on the other hand,
are apparently hostile towards the very idea that my toolsets could
possibly fit my work environments, and frankly I find it a little
baffling.