At some point there was an internal study at Bell Labs
after WYSIWYG word processors were beginning to be available
that found most people spent 20% of their time
futzing with how the document looked instead of writing.
Do you have chapter and verse on that?
Figures quoted at the XML-in-Practice conference in Boston in 2007 put it at 30-60% and a new study claimed to have seen 75-90%. I have raised this on a related mailing list but have been unable to identify the source as the organisation who ran the conference has erased all trace of it from their web site.
Most of that time was wasted because subsequent changes were
going to wipe out whatever the little tweaks had been intended to accomplish.
For stuff that customers do edit, we are stuck with MS trash, unfortunately
Let them use Word 2010 and up, but write a Word template and insist on them using it. It's then not hard to write an XSLT transformation of the document.xml into LaTeX, and they will never be any the wiser.
If you're "typing that amount of markup" then yr doin it wrong. There are LaTeX editors which let you go clickity-click for that nowadays.
Not quite clear what you mean about expecting graphics to look shit: perhaps you're thinking of the old default article/report/book styles? There are lots of alternatives nowadays.
With the number and range of packages now available for LaTeX (over 4,000) you probably don't need to spend half a day doing it. Half an hour is probably enough.
If you had a [near-]monopoly on the ready-to-use water supply in space, or even be one of several competing suppliers, you wouldn't even have to bother stripping the metals from the asteroids.
When I was in college and enamored with all things OSS I tried really hard to get into LaTeX. But it seems to me that as time progresses and our method of interacting with our computers via GUIs is more entrenched that it's kind of a dying notion. Of course, there are people who still use it (and will undoubtedly loudly criticize this post), but I would be willing to wager that it's dwindling.
Certainly not in my experience. On the contrary, what I see of LaTeX is growing. A lot of people who encountered it in college were poorly taught, poorly advised, and were given very poor documentation, and they assumed it was just for math/phys/eng geeks. But the quality of doc has improved massively, and the biggest growth area now is the Humanities, who have outgrown Word and are looking for something more controllable.
Talking with peers in the TeX world, I find that few professionals are writing in LaTeX directly anymore. LaTeX's typesetting abilities remain sexy, but it is far [better] to keep a document in a semantic markup like Docbook XML, transforming it to LaTeX via an XSL stylesheet only when one wants to produce final print output.
We use this route all the time: DocBook through XSLT through LaTeX to PDF. It's fast, effective, and utterly reliable. I haven't written a document of any significance directly in LaTeX for at least two decades.
There is a pretty good looking editor for Latex called Bakoma. What I have never understood with latex is that it is hard to find an editor that does exactly what this website does. You type on the left and it appears on the right. But I want one step further. You also can edit on the right.
The problem with that is that for many graphical interactions there will be more than one interpretation, so a computer cannot know what you actually wanted to do: all it can see is the effect of you having done it. If you can solve that non-contiguity, you'll have a really nice, saleable product...
No, the OP misses the point. S/he thinks that using a GUI molecule-drawing program is "better" than chemfig because it's GUI. It may be quicker than chemfig for one molecule, but if you want to generate PDFs for a whole bunch of them from a database, using LaTeX as an API for PDFs is significantly more effective than drawing them all by hand.
My consultancy develops LaTeX systems for various industries, and we also do typesetting for publishers through LaTeX. It's used extensively outside academia (see the list of consultants at but most people keep it quiet because it gives them an advantage over their competitors (there now! I've let the cat out of the bag...)
Oooh handy! I was just trying to figure out how I'd get some people at my company to face the terrifying interface of LaTeX (seriously, it looks like an IDE)
That's basically what it is: an IDE for creating PDFs.
Exactly. And what kind of dickhead types File:/// with a capital F?
I would have been more impressed if the error had been for the right reason: the file:/// URI is essentially a request for an ls -l / which is something the end user probably shouldn't get without authenticating.
And remember: unlike Apple, Android device makers, and the wireless carriers who offer Android smartphones to their customers, need ways to differentiate their products.
No they fucking well do not.
Only in the USA would this be regarded as a virtue or a requirement. I don't want to have to choose between crippled-version-of-Android-1, crippled-version-of-Android-2, crippled-version-of-Android-3, etc when what I want is a decent device knowing that the system will be the same no matter which device I choose.
The last thing on earth we need is wireless carriers and telcos who bugger around with the OS because they think their ghastly sucky software is sooooo terribly important.
In the USA, pretty much anyone can buy or sell a gun with little or no safety or sanity check, particularly at gun shows; kids clearly have easy access to them, as schools find it necessary to check for them on entry.
Nothing to do with Java. It comes from the same place that all lag comes from: the developers' insistence that their background processes are more important than the user's interaction with the interface.
When a user clicks (touches, slides, speaks, whatever) an object in the interface, the expectation is that the response will be immediate. Leaving aside communications delays, which users largely understand they have to live with, there is nowadays no excuse whatsoever for the device failing to respond instantly, even if only to provide feedback that acknowledges the interaction (for example when it involves an operation that is known to take measurable time such as opening an image file).
But the OS's own processes are regarded as sacrosanct, so the user interface just has to wait until they condescend to allow the user a few of their precious cycles. This happens on all end-user systems running multiple processes (leave IBM mainframes out of this:-) — just look at the time it takes to get a response from the Unity Dash, or the Gnome menu button, or the Windows Start button (or whatever it's called this week), or the Mac menu button...the first time you click it. It sits there loading its menus. Finally it lets you see them. You run your application, and for a short while, another click on the dash/start/menu will get a fairly swift response. Leave it a little longer, and it's been swapped out and takes another age to reload.
Developers, achitects, engineers, and programmers need to grasp the fact that their background processes must take a back seat when the user wants to do something. Their reply, quite naturally, is that their background processes are vital, essential, cannot be delayed or interrupted, etc etc. And quite right, some of them are. But it's their job to see to it that they are written and scheduled in such a way as not to interfere with the interface. Anything else is a design failure.
Yah. And Perl still looks like modem noise. Python is even worse. But JavaScript is like someone on acid tried to breed a zombie computer language in his basement.
Most corporate documents are transient: they are critical for a very short time, until a high-level decision is made, and then they're basically landfill. Contracts, sure, you might want to go back and look at them, but pretty much everything else is ephemeral. They use change tracking and comments, but hardly ever stylesheets.
Documentation, particularly professionally-written documentation, on the other hand, needs named styles, and this is where OO, LO, and GD fall flat on their faces. Word lets you set a style margin, where each paragraph-level object's style name can be seen at a glance. In other systems you have to hover or click or something on each object in turn. Editing or writing in this mode is a snap compared to OO, LO, and GD. Named styles are the only way that you can reliably get a reusable XML document out of a wordprocessor (ie not OOXML), and without proper facilities in the interface to manage styles, a wordprocessor is a dead duck.
Latin itself doesn't enhance logical thinking abilities. It's the highly-structured way it was taught and presented.
But yes, if you wanted to learn a language not for the purposes of travel or getting a job or communicating with co-workers or getting further with that cutie you were chatting to last night, then Latin would do fine. At least the process would teach you more about language structure, which is a useful thing in itself; and it's undeniably useful if you then go on to learn other languages.
Otherwise, Spanish or an Asian language; or French or German or Italian.
Slashdot Mirror
At some point there was an internal study at Bell Labs after WYSIWYG word processors were beginning to be available that found most people spent 20% of their time futzing with how the document looked instead of writing.
Do you have chapter and verse on that? Figures quoted at the XML-in-Practice conference in Boston in 2007 put it at 30-60% and a new study claimed to have seen 75-90%. I have raised this on a related mailing list but have been unable to identify the source as the organisation who ran the conference has erased all trace of it from their web site.
Most of that time was wasted because subsequent changes were going to wipe out whatever the little tweaks had been intended to accomplish.
I keep tellin' 'em but they never listen.
For stuff that customers do edit, we are stuck with MS trash, unfortunately
Let them use Word 2010 and up, but write a Word template and insist on them using it. It's then not hard to write an XSLT transformation of the document.xml into LaTeX, and they will never be any the wiser.
Not quite clear what you mean about expecting graphics to look shit: perhaps you're thinking of the old default article/report/book styles? There are lots of alternatives nowadays.
With the number and range of packages now available for LaTeX (over 4,000) you probably don't need to spend half a day doing it. Half an hour is probably enough.
...water is good for other reasons...
If you had a [near-]monopoly on the ready-to-use water supply in space, or even be one of several competing suppliers, you wouldn't even have to bother stripping the metals from the asteroids.
When I was in college and enamored with all things OSS I tried really hard to get into LaTeX. But it seems to me that as time progresses and our method of interacting with our computers via GUIs is more entrenched that it's kind of a dying notion. Of course, there are people who still use it (and will undoubtedly loudly criticize this post), but I would be willing to wager that it's dwindling.
Certainly not in my experience. On the contrary, what I see of LaTeX is growing. A lot of people who encountered it in college were poorly taught, poorly advised, and were given very poor documentation, and they assumed it was just for math/phys/eng geeks. But the quality of doc has improved massively, and the biggest growth area now is the Humanities, who have outgrown Word and are looking for something more controllable.
Talking with peers in the TeX world, I find that few professionals are writing in LaTeX directly anymore. LaTeX's typesetting abilities remain sexy, but it is far [better] to keep a document in a semantic markup like Docbook XML, transforming it to LaTeX via an XSL stylesheet only when one wants to produce final print output.
We use this route all the time: DocBook through XSLT through LaTeX to PDF. It's fast, effective, and utterly reliable. I haven't written a document of any significance directly in LaTeX for at least two decades.
There is a pretty good looking editor for Latex called Bakoma. What I have never understood with latex is that it is hard to find an editor that does exactly what this website does. You type on the left and it appears on the right. But I want one step further. You also can edit on the right.
The problem with that is that for many graphical interactions there will be more than one interpretation, so a computer cannot know what you actually wanted to do: all it can see is the effect of you having done it. If you can solve that non-contiguity, you'll have a really nice, saleable product...
No, the OP misses the point. S/he thinks that using a GUI molecule-drawing program is "better" than chemfig because it's GUI. It may be quicker than chemfig for one molecule, but if you want to generate PDFs for a whole bunch of them from a database, using LaTeX as an API for PDFs is significantly more effective than drawing them all by hand.
My consultancy develops LaTeX systems for various industries, and we also do typesetting for publishers through LaTeX. It's used extensively outside academia (see the list of consultants at but most people keep it quiet because it gives them an advantage over their competitors (there now! I've let the cat out of the bag...)
Oooh handy! I was just trying to figure out how I'd get some people at my company to face the terrifying interface of LaTeX (seriously, it looks like an IDE)
That's basically what it is: an IDE for creating PDFs.
You can never find anyone reporting the same issue, and then 30 seconds after posting, your report is trashed as "Duplicate of #32786".
If not, they then get the wrong end of the stick and spend the next decade discussing the wrong thing.
I would have been more impressed if the error had been for the right reason: the file:/// URI is essentially a request for an ls -l / which is something the end user probably shouldn't get without authenticating.
And remember: unlike Apple, Android device makers, and the wireless carriers who offer Android smartphones to their customers, need ways to differentiate their products.
No they fucking well do not.
Only in the USA would this be regarded as a virtue or a requirement. I don't want to have to choose between crippled-version-of-Android-1, crippled-version-of-Android-2, crippled-version-of-Android-3, etc when what I want is a decent device knowing that the system will be the same no matter which device I choose.
The last thing on earth we need is wireless carriers and telcos who bugger around with the OS because they think their ghastly sucky software is sooooo terribly important.
Oh, wait, we already have them...
Some applications need to represent times before 1970
Historians need to deal with calendar dates from the earliest recorded documents (those clay tablets from about 5500 BC? IANAH)
In the USA, pretty much anyone can buy or sell a gun with little or no safety or sanity check, particularly at gun shows; kids clearly have easy access to them, as schools find it necessary to check for them on entry.
But you can't buy your kid a Kinder Egg, and now you can't even play making your hand into a gun.
You people over there need to make some serious changes to your laws before you become the laughing-stock of the westernised world.
Why Do Entrepreneurs Innovate Better Than Managers?
Because they are entrepreneurs, not managers, perhaps?
When a user clicks (touches, slides, speaks, whatever) an object in the interface, the expectation is that the response will be immediate. Leaving aside communications delays, which users largely understand they have to live with, there is nowadays no excuse whatsoever for the device failing to respond instantly, even if only to provide feedback that acknowledges the interaction (for example when it involves an operation that is known to take measurable time such as opening an image file).
But the OS's own processes are regarded as sacrosanct, so the user interface just has to wait until they condescend to allow the user a few of their precious cycles. This happens on all end-user systems running multiple processes (leave IBM mainframes out of this :-) — just look at the time it takes to get a response from the Unity Dash, or the Gnome menu button, or the Windows Start button (or whatever it's called this week), or the Mac menu button...the first time you click it. It sits there loading its menus. Finally it lets you see them. You run your application, and for a short while, another click on the dash/start/menu will get a fairly swift response. Leave it a little longer, and it's been swapped out and takes another age to reload.
Developers, achitects, engineers, and programmers need to grasp the fact that their background processes must take a back seat when the user wants to do something. Their reply, quite naturally, is that their background processes are vital, essential, cannot be delayed or interrupted, etc etc. And quite right, some of them are. But it's their job to see to it that they are written and scheduled in such a way as not to interfere with the interface. Anything else is a design failure.
But, hey, lots of people like them, so they must be good, right? https://www.destroyallsoftware.com/talks/wat
MS did have some legitimate reasons for changing to the ribbon. The myriad toolbar buttons on classic Office toolbars is confusing to naive users.
Like this example which I often use: http://silmaril.ie/downloads/wordscreen.gif
LaTeX users find this amusing when people say how much easier Word is...
Right. And of course there aren't any porn sites or groomers active before 10pm, are there?
What could possibly go wrong?
[...] basically the entire enterprise world.
Most corporate documents are transient: they are critical for a very short time, until a high-level decision is made, and then they're basically landfill. Contracts, sure, you might want to go back and look at them, but pretty much everything else is ephemeral. They use change tracking and comments, but hardly ever stylesheets.
Documentation, particularly professionally-written documentation, on the other hand, needs named styles, and this is where OO, LO, and GD fall flat on their faces. Word lets you set a style margin, where each paragraph-level object's style name can be seen at a glance. In other systems you have to hover or click or something on each object in turn. Editing or writing in this mode is a snap compared to OO, LO, and GD. Named styles are the only way that you can reliably get a reusable XML document out of a wordprocessor (ie not OOXML), and without proper facilities in the interface to manage styles, a wordprocessor is a dead duck.
Setting application preferences is hardly a "skill."
Oh yes it is. Most users have absolutely no idea you can even do this.
Do you really have to be a geek to get that far?
Unfortunately, yes.
But yes, if you wanted to learn a language not for the purposes of travel or getting a job or communicating with co-workers or getting further with that cutie you were chatting to last night, then Latin would do fine. At least the process would teach you more about language structure, which is a useful thing in itself; and it's undeniably useful if you then go on to learn other languages.
Otherwise, Spanish or an Asian language; or French or German or Italian.
Klingon or Elvish, anyone?