I've been writing documents for roughly 20 years now, most of them
with several other authors, and the "change tracking" feature as it is
implemented in SM (sic!) Word, OO etc. has proven to be totally
useless, if not counter-effective.

What is required to make multi-author document editing work in a
reasonable way is a subversion client built into the document
processing software together with the possibility to visually diff and
merge branches. So that each contributor can work in his/her own branch
and only one author, who is responsible for the entire document, can
review contributions and merge them into the trunk.

Sincerely,

Wolfgang

On Tue, 10 Apr 2012 17:06:14 +0100

Dr. Robert B.K. Dewar and Dr. Edmond Schonberg wrote an an interesting
critique of CS education today, "Computer Science Education: Where Are
the Software Engineers of Tomorrow?":

http://www.crosstalkonline.org/storage/issue-archives/2008/200801/200...

"Because of its popularity in the context of Web applications and the
 ease with which beginners can produce graphical programs,Java has
 become the most widely used language in introductory programming
 courses. We consider this to be a misguided attempt to make programming
 more fun, perhaps in reaction to the drop in CS enrollments that followed
 the dot-com bust. What we observed at New York University is that the Java
 programming courses did not prepare our students for the first course in
 systems, much less for more advanced ones. Students found it hard to write
 programs that did not have a graphic interface, had no feeling for the
 relationship between the source program and what the hardware would
 actually do, and (most damaging) did not understand the semantics of
 pointers at all, which made the use of C in systems programming very
 challenging.

   Let us propose the following principle: The irresistible beauty of
 programming consists in the reduction of complex formal processes to a
 very small set of primitive operations. Java, instead of exposing this
 beauty, encourages the programmer to approach problem-solving like a
 plumber in a hardware store: by rummaging through a multitude of
 drawers (i.e. packages) we will end up finding some gadget (i.e. class)
 that does roughly what we want. How it does it is not interesting! The
 result is a student who knows how to put a simple program together, but
 does not know how to program. A further pitfall of the early use of
 Java libraries and frameworks is that it is impossible for the student
 to develop a sense of the run-time cost of what is written because it
 is extremely hard to know what any method call will eventually execute.
 A lucid analysis of the problem is presented in [4]."

As far as *users* go, I find it remarkable that a group of natural
scientists don't seem to have a good grasp on the concepts and
operation of a filesystem. If they have trouble with a file on a USB
drive, how can they be expected to accurately import data, say,
collected from the field, into their PC of laptop for further
processing?

Of course, computers can be used like interactive DVD players.
However, their real strength is in being able to accurately move
and process data be it tax forms, photo images or text files.

IMHO, something is amiss when even "ordinary"/most users cannot
do that.

  Cheers,

  Mike Shell

On 13/04/12 22:37, Jail Bush Cronies wrote:

TAB-completion takes care of that.

Which I mentioned elsewhere.

Yes. There are some cases such as random selection where a graphical
preview and cumulative click and drag is better. That's why I said
"probably".

I won't even mention voice-input commands...

///Peter

On 14/04/12 10:29, Wolfgang Keller wrote:
[...]

I find that I work faster when correcting from a proofreader's paper marks.

Which is exactly what a proper XML document respository and document
management system does. It takes care of versioning and checkin/checkout
and locking, and because it decomposes the document to a specified level
of granularity based on the markup, you can even checkout a document
fragment to work on, leaving others to edit other parts.

///Peter

The ultimate CLI.

--
John Wingate                        Mathematics is the art which teaches
joh...@tds.net                      one how not to make calculations.
                                                         --Oscar Chisini

On 14/04/12 21:28, John Wingate wrote:

No, just a CI :-)

///Peter

On 04/14/2012 07:03 PM, Michael Shell wrote:

Beautifully put and illustrated, Mike.  My sentiments precisely.  The
problem is people brought up in this mode of 'programming' go on to
teach subsequent generations - it becomes entrenched.  Is the whole
thing not called "dumbing down"?  When I raised such issues in the
school where I taught, I was told industry expects this approach (Java,
etc etc) to be taken.  Natural scientists represent a real problem to CS
because they still do something called 'maths' which is too hard for CS
students - as indicated by the Java model.

Ross

On 14/04/2012 10:27 PM, Ross Maloney wrote:

No, no, no, you're both wrong.

All this really indicates is that CS is no longer a monolithic field.
There are now several major emerging subspecialties, and some of them
really are like plumbers, for instance web devs. How often does a
plumber need to invent a new kind of elbow joint? Having reusable parts
means less need to reinvent the wheel.

There are still systems programmers that work in the guts of the system,
and everyone is still expected to learn the basics of algorithms and
data structures, the last time I checked.

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 14/04/2012 2:41 PM, Peter Flynn wrote:

If the first one or two letters are enough to disambiguate which file,
maybe. Often it will take a longer prefix than that.

Too verbose, much of the time. ;)

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 13/04/2012 8:36 PM, John Wingate wrote:

Then why did you post it to a TeX newsgroup, Wingate?

What, copy and paste? I described that below. Even with that silly
"select auto-copies" thing turned on, you'd need five input gestures
minimum per file: double-click name to select (and copy) it, tab to
terminal window, paste, tab back to file list window.

Versus *one* per file with control-clicking or separate click-dragging.

Tab completion is less predictable as it depends on how long a prefix
each file name has to have before it's enough to uniquely specify it. If
many of the file names start with the same long prefix, tab completion
starts sucking pretty badly. Consider having dozens of files named
"2012_vacation_in_Yellowstone_National_Park_nnn.jpg" versus if "af"<tab>
suffices to get you "afghanistan-war-politics-rant.txt" as nothing else
starts with "af" in that directory.

I'm quite sure I've run into several over the years.

That's only if you're using that crazy select-auto-copies setting that
causes so many problems elsewhere, and no, the click isn't the paste.
*A* click may be the paste but there's also a click (or alt-tab or
something) needed to focus the terminal window first, and maybe even
another one to correctly position point where you want to paste (though
if there's a click that pastes it presumably positions the point at the
click site, then pastes). The only way you *might* be able to save one
more click is if you have the windows positioned such that the leading
edge of the command line you're building up is never covered by the
other window. Then you *might* be able to do your paste-click right
there and it *might* work even when the window isn't focused, focusing
it, placing the point, and pasting.

Even then, it's three input gestures per file: double-click to select
name, paste-click, and switch back to the first window again. Reducible
to two if you make the windows wholly nonoverlapping so the double-click
needn't be preceded by an explicit window switch, but then you lose half
the screen real estate for the file list and need to scroll it twice as
often. And back up to three if double-click to select filenames doesn't
work (either at all, or selects just a part of a filename with hyphens,
dots, spaces, or etc.) as you then need to click, shift-click to select
a name.

Versus one control-click or click-drag with the Windows method.

The most compact ls view looks like this:

file1   file2   file3   file4   file5   file6   file7   file8   file9
file10  file11  file12  .       ..

The most compact Explorer view, List view, is basically identical except
that the files are clickable objects and there's a back button instead
of .. and any empty space in the display serves as . for the purposes
of, say, right-click "properties". You can hide the left sidebar and
much else, if you need more space.

Oh, except for one thing: the Explorer view is probably close to 140
columns instead of 80 in terms of characters, even with the little
folder or file icon left of each name, and there's a lot more than 24
rows, too -- probably about 40. And you can probably get even more by
fiddling with a font size option somewhere. ;)

How so? Generally, whatever goes off the top of the console simply
evaporates. If you capture it to a file, then open it in a (GUI!) text
editor, you can scroll through it in that, though.

 From http://unix.stackexchange.com/questions/12618/clipboard-for-images
we have this:

     The original X Window System does only have a X11 selection, which
     is only text. There are several extensions to implement a clipboard
     but the applications, which use them are not fully compatible to
     each other.

So yeah, that's true. Unless you're willing to a) install something
extra and b) still not have it work reliably between some pairs of
applications. Unlike the Windows one, which just works. (Arguably one of
the few things on Windows that DOES "just work"!)

Already have.

What does your classic unsubstantiated and erroneous claim have to do
with TeX, Wingate?

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

Any subversion-style revision control system does this, more or less.
But this was /not/ my point.

My point was about the integration of the corresponding client into the
authoring software. /And/ especially about the visual diff and merge
capability. LyX has taken a step in the right direction since version
2.0, away from braindeadly cloning the mis-idea of SM Word, OO etc. I
haven't found another LaTeX editor that integrates similar
functionality.

Which is pretty incomprehensible for me, because, ever since I learned
to know what revision control systems are (subversion in particular), it
has been perfectly evident to me that /any/ "document" (in the widest
sense) editing application would need to integrate a subversion client
in order to allow reasonable use in a "corporate" environment. And by
"documents" in this context I understand pretty much /any/ kind of file
that's processed in a typical "office" environment, including e.g.
spreadsheets etc.

Sincerely,

Wolfgang

Not with the ls listing in the same xterm window as the command line
being constructed--no back and forth between windows.  (Even with two
windows involved, I merely move the mouse to change focus; your
preferences may differ.)

I'd still like to know.  Please rack your memory.

http://en.wikipedia.org/wiki/X_Window_selection

X11 was originally released in 1987.  It has progressed a bit since then.
Read http://en.wikipedia.org/wiki/X_Window_selection, particularly the bit
about active selections.

--
John Wingate                        Mathematics is the art which teaches
joh...@tds.net                      one how not to make calculations.
                                                         --Oscar Chisini

On 15/04/12 13:39, Wolfgang Keller wrote:

Sorry, my misunderstanding. Actually, doc repository and mgt systems may
well use svn under the hood when it comes to dealing with whole files.

But that *is* precisely what you get in XML-based doc mgt systems.
Arbortext's EPIC, for example, is a denominated editor for several of
them, so that it will open when you select a file or file fragment to
edit; and if it's already open, you can select a file or file fragment
to edit. Its interface becomes the interface to the doc mgt system.

That too.

I have 2.0.0 installed, although I very rarely use it. What is it doing
that versions <2 didn't do? (You -- someone -- mentioned change control).

Emacs, of course...

In document engineering and professional tech doc, certainly. Most other
"office productivity solutions" just use Sharepoint or a bunch of shares
on servers, IMHE.

Quite so. Usually the veru documents that need such a service don't get it.

///Peter

On 15/04/2012 9:13 AM, John Wingate wrote:

No, then there's a whole lot of scrolling: up before each copy, down
before each paste, up, down, ... I imagine that would get very annoying
very fast.

And that's assuming scrolling up works. If it doesn't and the listing
won't fit on one screen then it's time to play games with multiple ls
commands and wildcards, or redirection to a file, and then you
definitely need multiple windows.

The most recent one was an NT box at work. I'm not sure which was the
last Unix one.

Apparently not. After the text above the web page says:

     answered May 6 '11 at 13:33

Unless they've standardized on a single clipboard extension and all
applications have released updates that make them use the new standard
in the last 11 months, guess what? BZZZT! YOU'RE WRONG!

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 04/15/2012 11:00 AM, javax.swing.JSnarker wrote:

I disagree.

A plumber is expected to be good with his instruments (tools).  He
follows standard designs in his implementation.  By contrast, a CS
student is being taught to both design and implement.  The emphasis
should be on the fundamentals so he can design well with less emphasis
on the tools, Java being one such tool.  Over the CS student's working
life, the tools will change, but the fundamentals will (should) remain
constant.  All CS students need to know the 'guts.  Medicine also has
many specialities.  Although a surgeon does not do basic design but uses
instruments of all sorts, it is nice to believe/hope/pray he knows
fundamentals such as anatomy.  There is certain knowledge which is
fundamental to any profession, even when a profession has specialities.
  The fundamentals are the core.  As an engineering student I spend the
first two years of my four year degree doing common courses with those
who were going off into other engineering specialities.

With the fundamentals in place, the other bits and pieces can be put in
place on the job.  Should a web designer know about using an operating
system and the hardware which underlies it?  I would say yes.  Just as
that knowledge is necessary for the systems programmer.  Algorithms and
data structures are part of the core knowledge of CS.  Both the web
designers and systems programmers need such knowledge.  They can then
build upon it as appropriate for their specialization.

Java is an example of a tool which aims to hind the hard realities of
computer hardware from the programmer.  This is why it is inappropriate
for educating CS students.

Ross

On 16/04/2012 12:30 AM, Ross Maloney wrote:

Oh, if only! If only! But not anymore. *Some* people are going to go on
to design and not just implement. But others are going to go on to sit
in a cubicle farm somewhere, told by the boss to make this doodad talk
to this doodad or make this thingy have a web interface, and pretty much
given the design and left only to decide the details and actually hook
all the parts up into a working solution. Where by "working" tends to
mean "occasionally has odd hiccups and failures but has 95% uptime".

Business requirements are quite different from theoretically-ideal
engineering.

So, in short, where programmers used to be engineers, artists even, the
Gustav Eiffels of computing, now some are engineers and some are, well,
plumbers.

These days, for a lot of career programming work the fundamentals are
"how to read all these API docs and how to keep on top of an
ever-shifting set of TLAs and other thingys you're supposed to know
about -- JDBC, Hadoop, WebGL, EC2, EJB, Struts, Hibernate, Tomcat..."

People die if a surgeon gets anatomy wrong. When a Microsoft webdev gets
the guts wrong, we get all those 500 Internal Server Errors and other
irritating hiccups that plague our web browsing, particularly when
browsing to sites that are run by M$ or use M$ IIS instead of Apache as
their web server. This is apparently considered acceptable by the
bean-counters, as long as it doesn't get *too* severe.

One thing in common, consequence-wise, between a bad surgeon and M$
server use, though: in both cases you can come down with an infection as
a result of an unpatched hole.

I'd say that's the ideal, but the reality, to judge by how wonky and
rickety a lot of web servers out there are, seems to be different. ;)

Again, that's the ideal, but there are sites that get real slow
displaying much info at once, and even native apps like Shareaza, and
one suspects somebody used bubblesort when these cases occur ...

I don't know. I'd say that they should get some C, to see what's near
the bare metal, and some of a higher level language that gets memory
management, display handling, file I/O, and other clutter mostly out of
the way and lets them focus on a particular problem or algorithm or data
structure. If teaching them OO, Java is widely used in industry so may
be a natural choice. Lisp has a high degree of abstraction but is less
used in industry, but algorithms can be particularly cleanly expressed
in, say, Scheme.

Probably different courses should use different ones. FWIW, when I took
CS the place I was at used C for systems level stuff and Smalltalk for
OO, rather than Java for either.

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

At Mon, 16 Apr 2012 01:39:19 -0400 "javax.swing.JSnarker" <gharri...@boojum.mit.edu> wrote:

This sounds like two *different* disiplines: one that is (like plumbing)
taught in a technical high school or a trades school and another that is
a 4+ year college degree program.

--
Robert Heller             -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

On 16/04/2012 9:52 AM, Robert Heller wrote:

So it does.

P.S. Mind fixing your newsreader so it sets the References: header
properly? Your replies appear in random places in the thread instead of
directly beneath the parent article.

The last reference in the header seems to be correct, but the earlier
ones seem to go off the rails. For example, the post I'm replying to has
this header:

References:
<132d3da7-7cb3-4546-bffb-6303436e9...@h5g2000vbx.googlegroups.com>
     <qfobrgh6iq....@dev-rf10-linux.cl.cam.ac.uk>
     <f2e8b6f7-8931-4e5e-8c67-f7c4c8234...@x17g2000vba.googlegroups.com>
     <slrnjns6uf.3il.Jim.Diam...@jdiamond-nb2.acadiau.ca>
     <9u8b2lFka...@mid.individual.net> <qfzkamy1no....@danube.cl.cam.ac.uk>
     <injgr.9309$ie6.1...@newsfe14.iad> <20120409062508.0e3baa85@X>
     <9ug73sFe4...@mid.individual.net>
     <ve2dnREvqrHfmR7SnZ2dnUVZ_s6dn...@posted.localnet>
     <9ugk38Fia...@mid.individual.net> <201204100548
     <jmgbaa$8r...@speranza.aioe.org>

The last one is the one for my article last night. The one before it
isn't even syntactically valid. The one before that is wrong, though
syntactically OK, etc. The actual references chain should be:

<132d3da7-7cb3-4546-bffb-6303436e9...@h5g2000vbx.googlegroups.com>
<qfobrgh6iq....@dev-rf10-linux.cl.cam.ac.uk>
<f2e8b6f7-8931-4e5e-8c67-f7c4c8234...@x17g2000vba.googlegroups.com>
<slrnjns6uf.3il.Jim.Diam...@jdiamond-nb2.acadiau.ca>
<9u8b2lFka...@mid.individual.net>
<qfzkamy1no....@danube.cl.cam.ac.uk>
<injgr.9309$ie6.1...@newsfe14.iad>
<20120409062508.0e3baa85@X>
<9ug73sFe4...@mid.individual.net>
<ve2dnREvqrHfmR7SnZ2dnUVZ_s6dn...@posted.localnet>
<9ugk38Fia...@mid.individual.net> (1)
<20120410054812.5defd997@X> (2)
<xDYgr.39639$yD7.34...@newsfe15.iad>
<qfehrvpo5l....@dev-rf10-linux.cl.cam.ac.uk>
<20120414070306.2f922647@X>
<05ednVcaUqPkrBfSnZ2dnUVZ_jidn...@westnet.com.au>
<jmddkp$o6...@speranza.aioe.org>
<z56dneKb-p5IAhbSnZ2dnUVZ_tedn...@westnet.com.au>
<jmgbaa$8r...@speranza.aioe.org> (3)

Note that your post's is the same up to, and including, (1) above. It is
(2) above that it mangles, cutting it short after the < and first twelve
other characters. The only message ID after that in your post's header
is (3), the post by me that you're replying to. It threads in my (and
probably most) newsreader as a reply to (1) rather than to (3) because
of this manglage.

Obviously, your problem is that you're using a butt-ugly Unix
newsreader, though at least you chose a graphical one. That isn't enough
to save you from the Unix disease, however. In this case, it seems to be
the evil and terrible tendency to use fixed-length buffers to hold C
strings that's the cause. Your precious "TkNews 2.0" is, instead of
simply reading the parent's references header, appending a space and the
parent's message-ID, and using that as the new post's references header,
is reading the parent's references header, cutting it off at 511 bytes
(plus terminating NUL), and *then* appending the parent's message-ID.

Of course, doing this job correctly in Java is trivial:

String references = parent.getReferences();
if (references == null) references = "References:";
references = references + " " + parent.getMessageID();
setReferences(references);

whereas doing it correctly in C requires explicitly manipulating malloc
buffers, copying arrays, and other nuisance housekeeping work that the
authors of TkNews 2.0 obviously were too lazy to bother with.

As ugh.pdf says:

     According to the empirical evidence of Unix programs and utilities,
     a more accurate summary of the Unix Philosophy is:

     • A small program is more desirable than a program that is
       functional or correct.
     • A shoddy job is perfectly acceptable.
     • When faced with a choice, cop out.

     Unix doesn’t have a philosophy: it has an attitude. An attitude
     that says a simple, half-done job is more virtuous than a complex,
     well-executed one. An attitude that asserts the programmer’s time
     is more important than the user’s time, even if there are thousands
     of users for every programmer. It’s an attitude that praises the
     lowest common denominator.

This attitude is quite evident in the misdesign of TkNews 2.0 and,
particularly, its handling of References header construction.

HTH, HAND, and all that. ;)

--
public final class JSnarker
extends JComponent
A JSnarker is an NNTP-aware component that asynchronously provides
snarky output when the Ego.needsPuncturing() event is fired in cljp.

On 2012-04-16, Ross Maloney <rmatyc...@iinet.net.au> wrote:

All languages are designed to do that. That is their purpose. Even
assembler. Would you also advocate that allo CS students shoule be as
familiar witht ehhardware as EE students ae-- know exactly how the
various instructions in the cpu/bus/graphics card are implimented as
transistors etc? That is surely even more fundamental. Or perhaps They
should know how to derive the behaviour of all the hardware from QCD or
string theory. After all that is even more fundamental. The ability to
hide the lower layers from the level you are working at is one of the
strengths of human endeavour. (at least I assume you meant "hide" when
you said hind).

At Mon, 16 Apr 2012 11:40:28 -0400 "javax.swing.JSnarker" <gharri...@boojum.mit.edu> wrote:

It was not the newsreader, but the program I use to get the news
articles off the newserver (uqwk).  It was using an old nntp client
library that was using the 512 byte buffer used for command and status
lines (which are limited to 512 bytes as specificed in RFC 3977).  I
just fixed it to use a 4096 byte buffer when reading articles. The code
in question is from rn-1.4.4 Copyright 1991 by Stan Barber) and
modified by Ken Whedbee (3/31/93) to work with uqwk.

TkNews itself is written (by me) in Tcl/Tk and in fact uses much the
same logic as your java example used (it is using Tcl lists rather than
strings, but the effect is the same).

--
Robert Heller             -- 978-544-6933 / hel...@deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

On Mon, 16 Apr 2012 12:59:41 -0500

Impressive ... very impressive. :) I sometimes wonder what the average
IQ of posters on comp.text.tex is. I suspect that it is shockingly high.

No problems with copying files or calling malloc() around these parts.
LOL.

  Mike

The average IQ would be _much_ higher if we could reduce the spamming and trolling.

Regards,

Marc van Dongen

This is, to some extent, an off-opic discussion. Still, I'd like to chime in.

I think, the question whether the CLI or the GUI is more efficient is mute.
There are things which can be solved extremely quickly in the GUI (point & click).
There are other things that can be solved extremely quickly on the CLI.
Even when we restrict the discussion to file management only.
For instance, sometimes, I use the GUI (I live on a Mac) to open an application.
Sometimes, it is just quicker to type 'open /Appl<tab>/MyApp<tab>'  in the Terminal.

Moving a file is often times quite efficiently done in the GUI.
But some other tasks can be done much more efficiently on the CLI, such as 'rm */*/*.aux'

It also depends very much on the level of computer literacy of the user.
I'd guess that 90% of the casual computer user won't grasp the concept of the CLI, let alone be willing to spend the time learning it.
(I was teaching several times a Unix class to a large audience, 50% of which was students of economics and business administration.)
And they don't have to, because 90% of their work is writing documents, doing mail, or surfing the web.

Except that neither XeTeX nor LuaTeX seems to have all of it, none of them is 100% cross-platform, and development of XeTeX seems to have halted ...

Well, well, ... I think that is a rash conclusion.

In the 21 century, I think, only those tools will survive where the learning curve is NOT too steep at the beginning.
In other words, tools where you can sit down people and they can learn the tool *while* getting something (albeit limited) done.
(Programming languages are, to some degree, different, of course.)

BaKoMa seems to be going in the right direction in this regard: novice users can type in the preview window and see the corresponding latex commands (such as \textbf) in the latex source window.
Expert users can type in the latex source window, and get the benefit of (almost) instant previews.

LyX has improved a lot since I last checked (about 5 years ago), but I think it hides way too much from the user.
It tries to become a Word-WYSIWYG-like editor.
The problem with this approach is, it seems, that it has to implement special GUI features for every feature a user might want to use.
(Yes, I know you can paste some Latex source into Lyx, but I don't think that is sufficient.)

Overall, in the Latex software ecosystem, we have three tiers, I think:
1. at the bottom, there is the TeX engine (Tex, pdfTex, LuaTex, etc)
2. in the middle, there is Latex and all the wonderful packages
3. at the top, there is the GUI (Bakoma, TexWorks, TexShop, LyX, etc.)

It seems to me that the largest part of efforts happens in the middle layer (packages). This is good.
There also seems to be some activity at the bottom layer, but it seems a bit limited in terms of man power.

But the problem is that at the top layer, there is too little activity.
There are probably a number of reasons for that:
- it is a much larger piece of software than, say, a single Latex package, so the burden in terms of time becomes very large
- making it really cross-platform is even harder
- a really good GUI (like the one I'm envisioning) makes the software quite complex
- it probably needs fairly tight integration with the bottom layer (the engine), because it needs a lot of hooks into the engine, but the development "communities" between the top and the bottom layer seems to be very far apart
- "old school" Latex users don't need such a GUI, so there is little appreciation for the efforts from that side

Well, it makes the kind of GUI I'd like to see a bit more difficult.
(And besides, TeX needs to be batch oriented to be able to produce high-quality typographic output.)
But the TeX engine would probably need much more hooks for the GUI, so that, for instance, the GUI knows which image path was meant when the user double-clicks on an image in the PDF output.
And the Tex engine would need to "quit gracefully" if the source is malformed, and not leave corrupt aux files around.

Gabriel.