I hate C++

[Farren]

WHY have headers and definitions for classes in seperate files? I can't fucking see why that produces any advantages in compiled code. For fucks sake if it needs headers it can generate them from the class definitions.

WHY have what appear to my novice eyes to be lots of redundant operators? What the hell is the difference between "." and "->"?

WHY does (Microshit) C++ always offer to open C++ source files instead of C++ project files when you click File/Open, forcing you to change the file type filter every time? Its freaking obvious 99% of the time you want to open a project, not a little bitty part of it.

WHY is something as simple as a menu item abstracted to a symbol (using MFC) that somehow connects to an action that I have to go hunt around for - instead of just being a visual element with an event, which would be far more logical.

WHY do I have to wake up at five am tommorow?

WHY? WHY, DAMMIT?

I've been programming since 1980-something. I've programmed in Commdore Basic and machine code, GW Basic (DOS), Cobol, OOP Turbo Pascal, Delphi, Visual Basic, PL/SQL, stored procedures in TRANSACT SQL and Unreal mods in UScript. I've never met a language that scares me, not even C++ - but C++ angers me. Yes it does. It infuriates me. It makes me want to tear my hair out. It makes me want to tear all my dog's hair out and beat him with a hot poker afterwards. Bastard language.

[JoeP]

Agree with all that. You forgot :: - another operator that . works fine for in basic or pascal.

Does C# have all these operators? I think it's cleaner. There are theories that some dude from Borland (anders heilsberg?) went to microsnot to design C#.

Commodore basic - check. Plus Atom basic, APL, several varieties of COBOL, REXX (one of the finest interpreted languages of its day), Delphi, and some other stuff. Pretty limited SQL.

Have you done any APL? Makes C++ look like janet and john. Famous for single line programs to print out primes. Uses a symbol set not available on any modern computer.
http://www.users.cloud9.net/~bradmcc/jpg/apl_PRIMES.jpg (http://www.users.cloud9.net/~bradmcc/APL.html)
And the simplest possible syntax for 'Hello World':
'Hello World'

[seebs]

I will defend headers, and ./->. I won't try to justify C++ in general.

Headers allow you to distinguish between interface and implementation. This is WAY COOL and VERY IMPORTANT.

"." is for non-pointers, "->" is shorthand for pointers.

(a)->b is the same as (*a).b

[Corona688]

Major C junkie replying here. :cool:

I think the problem is they never bother teaching people C anymore, even though it defines the rock-bottom fundamentals of everything C++ uses. Even worse, they tried to hide some of the features of C with "simplifications" like "passing by reference" that only confuse people who don't know what the hell it's simplifying. Learn C, understand how it uses variables structures and pointers, and you shall understand a lot more about it's bastard child C++.

The difference between -> and . goes all the way back to plain C. Use '.' when you're using an object. Use -> when you're using a pointer to an object. a->b is logically equivalent to (*a).b. A pointer is an integer variable that contains a memory address of something, absolutely nothing special about them other than the way the language uses them.

In many languages it can be difficult to tell whether you're passing the object itself or a copy of the object to a function; if you modify it inside the function, does it get modified outside it or not? C solves this problem by making references completely explicit - if you're passing a pointer, you're passing the object itself, if you're not passing a pointer, you're just passing raw copies of the object. That's probably the most important reason for pointers. The other is that passing things by value can be helluva expensive with large arrays or structures. When you pass a large structure by value it has to copy the entire damn thing, but if you're passing a pointer all it passes is an integer value saying where the data it wants is.

Next! Why are headers and source code abstracted? The same reason they are in C: So you can link external libraries. C code doesn't need to know the contents of a function in order to use it - all it needs to know is what it looks like. When the linker finally puts all the pieces together it'll try to find the function, either in your own source code or in an external library. In fact, even if you completely change the code it's calling, it doesn't have to recompile the thing that calls it because all it needed to know in the first place was what it looked like and that didn't change.

C++ is the same way. Source code doesn't need to know the implimentation of a class to use it, it only needs to know what it looks like. It'll compile all by itself and find the bits it needs to call externally later. The class you're using might be in your own code, or in an external library, and with properly-written headers, anything that uses that code'll never know the difference.

Hope that helped. :) I'll happily answer more questions...

[seebs]

Woo! More C folks! Always a good thing.

[squian]

Does C# have all these operators? I think it's cleaner. There are theories that some dude from Borland (anders heilsberg?) went to microsnot to design C#.

It's not just theory. From a page at Microsoft (http://msdn.microsoft.com/vcsharp/homepageheadlines/hejlsberg/default.aspx):
After 13 years with Borland, Hejlsberg joined Microsoft in 1996, where he initially worked as an architect of Visual J++ and the Windows Foundation Classes (WFC). Then, Hejlsberg was chief designer of C# and a key participant in the creation of the Microsoft .NET Framework. Today, he leads the ongoing development of the C# programming language.

C# is cleaner because of 20/20 hindsight on Java. And Java cleaner because of 20/20 hindsight on C++.

Farren, it sounds like half your problems are from the tooling. Why not use something else? Try Eclipse with the CDT. You can even plug-in the Microsoft compiler.

Personally, I can't live without good OO constructs anymore. I tried to help a friend with some C a while back and realized I had forgotten how to solve things with long procedural methods. And pointers?!? Ugh, thank goodness I never need to write device drivers and the like. Or what about macros? Give me aspects anyday.

[seebs]

Honestly, I like Java a lot better than C#.

But... I still like C. I use C. A lot. If I weren't unemployed, I'd be at C committee meetings; as is, I may have to lose my voting rights for lack of money to attend meetings. (Asshole Microsoft arranged a meeting that's very hard to get to except from a hotel that's $150/night.)

[Corona688]

Personally, I can't live without good OO constructs anymore. I tried to help a friend with some C a while back and realized I had forgotten how to solve things with long procedural methods. C code that uses only long procedures is badly written C code. :) People don't often explain this but you can write object oriented C code. You just need to do everything explicitly. For instance:#include <stdlib.h>
/* object */
typedef struct myobject
{
int value;
} myobject;

/* constructor */
myobject *myobject_create(int val)
{
myobject *obj=(object *)malloc(sizeof(myobj));
if(obj==NULL) return(NULL); /* out of memory */
obj->value=0;
return(obj);
}

/* destructor */
void myobject_free(myobject *obj)
{ if(obj!=NULL) free(obj); }

/* member function */
int myobject_dosomething(myobject *obj, int a)
{
if(obj!=NULL)
{
obj->value+=a;
return(0);
}
else
return(-1);
}

int main(int argc, char *argv[])
{
myobject *obj=myobject_create(3);
if(obj==NULL) return(1);

if(myobject_dosomething(obj,13)<0)
{
myobject_free(obj);
return(1);
}

myobject_free(obj);
return(0);
} This is logically equivalent to: class myobject
{
public:
myobject() { value = 0; }
int dosomething(int a) { value += a; }
private:
int value;
};

int main(int argc, char *argv[])
{
myobject *obj=new myobject;
myobject->dosomething(13);
delete obj;
return(0);
} The C version is more wordy than C++ or C#, but, you can trace every single thing it does, it does absolutely nothing you didn't tell it to, and you've properly accounted for error conditions. Errors are very hard to deal with object-oriented C++... usually the best you can do in is throw an assert, or wait until errors screw things up then try to recover. Hell, C++ behavior isn't even defined in out-of-memory conditions - memory allocations will fail, but there's no guaranteed way to tell when they have.And pointers?!? Ugh, thank goodness I never need to write device drivers and the like. If you don't understand pointers, you don't understand computing, and that's a fact. Pointers are a fundamental concept of computer memory, not a C invention, and languages that don't include them are often forced to bodge them in later.Or what about macros? Give me aspects anyday. Macros have a purpose, but yes, they are frequently abused and not the best-designed feature of C.

The one C++ feature I feel the lack of in C is a good template operator. Macros just don't cut it.

[squian]

If you don't understand pointers, you don't understand computing, and that's a fact.
No arguments. But I don't have to like it when the language needs me to consciously reference and dereference pointers.

An object reference is a pointer to a space in memory. There are many cases where it's important to know if you have passed a reference or passed a copy. Without an understanding of pointers, this becomes a difference without a distinction.

Pointers are a fundamental concept of computer memory, not a C invention, and languages that don't include them are often forced to bodge them in later.

I don't think this is so much an aspect of the language but the environment in which they run. With virtual machines such as the JVM or the CLR, do you think pointers will need to be "bodged" in later?

[JoeP]

I will defend headers, and ./->. I won't try to justify C++ in general.

Headers allow you to distinguish between interface and implementation. This is WAY COOL and VERY IMPORTANT.

"." is for non-pointers, "->" is shorthand for pointers.

(a)->b is the same as (*a).b
But why in separate files? 'interface' and 'implementation' serve exactly this purpose in delphi/pascal and enable fast compilation.

And it seems to me the need for different member notations is solved by strong typing. object.member works in delphi because the compiler knows object is a pointer and automatically dereferences it. Likewise :: - class functions are class funtions and declared as such. You don't need a different notation to access them.

[Farren]

Why not make function headers implicit in the definition of a function and simply declare external functions in a different way, as is done in VB with the DECLARE statement? Its more economical and no less elegant. It means you're not stating information redundantly (syntax of function) and you're still pointing the compiler in the right direction.

The explanations make sense, but what they explain doesn't seem the intrinsicly "right" solution to the problem. In fact, given C's reputation for economy of expression the method adopted seems to run counter to the purported strengths of C and C++.

Similarly for "->" the explanation makes sense but the method it describes doesn't necessarily. Since P.method or P.Variable is not allowed as a valid syntax when P is a pointer, why not have the compiler simply assume (in a similar manner to implicit typing) that Pointer.Blah always means (*Pointer).blah? ...OK, with further thought I could see how this could be considered less articulate in the sense that the source code tells you less at a glance so I can kind of see the point of that. Thanks.

Still the seperate header thing makes no real sense to me.

[Farren]

Farren, it sounds like half your problems are from the tooling. Why not use something else? Try Eclipse with the CDT. You can even plug-in the Microsoft compiler.


My problem is that the stuff I'm working on in C++ (a game based on the brilliant Torque game engine) has a ready made project file for Microshit VC++. I dread the thought of hand-assembling all the source files into another IDE and specifying all the include directories and tons of other shit that seems to be required again.

I'm just going to have to grit my teeth until I love C++ and relish its inherent logic and elegance (which, from past experience with other languages I know I will eventually). I just wish I hadn't moved away from OO Borland Pascal to simpler languages like VB and PL/SQL for a few years because I haven't used a proper pointer in years. In order to use API stuff you have to do things in VB like Dim lngP as long; lngP=ObPtr(MyObject) but it doesn't make staring at code full of *P, P* any easier. Its all so alien looking right now.

Christ, I've just realised I haven't used inheritance in about five years. Looking at virtual methods and minimally defined descendant classes is confusing the hell out of me. I've gotta learn a whole bunch of reflex mental habits now.

Oh shit. Threading! I'm going to have to get used to things not always being apartment threaded! Ga!

[pescifish]

C++ is for weanies.

[Farren]

C++ is for weanies.

:poke:

Poke. Poke. :D

"As long as I can continue to post my opinions without backing them up with any valid reasoning or facts, I'm all for a computing forum!"

The inimitable Pescifish
September 18, 2004.

p.s. Its "Weenies"

[pescifish]

Exactly!!!!
See now, I couldn't post as I did in this thread until I made that [warning] statement quoted above. :yup: Now, I'm off and running...

p.s. Its "Weenies" Yeah, I shoulda listened to my officemate, that was her third and final answer when I asked how to spell it. Thank you! I'll need that when we start talking about Unix. ;)

[Farren]

Exactly!!!!
p.s. Its "Weenies" Yeah, I shoulda listened to my officemate, that was her third and final answer when I asked how to spell it. Thank you! I'll need that when we start talking about Unix. ;)

Don't forget to spell it UNIKS and make at least one obnoxious comment about the Colonel. :wink:

[Corona688]

But why in separate files? 'interface' and 'implementation' serve exactly this purpose in delphi/pascal and enable fast compilation. It's a consequence of the way that C compiles and links code.

Combined interface/code is not necessarily faster, since it means that if you're using an object, the code for that object must be compiled before anything that uses it. If it's not compiled yet, it doesn't know the interface yet, so it has to wait.

C source files, on the other hand, can be compiled in any order - it doesn't care if the object definition's been compiled or not, all it needs is the interface. On a system with more than one processor, like mine, compilation speed is literally doubled because it can compile two source files at the same time without waiting for anything else.

Compiling C code produces a bunch of little independent 'object' files. They contain variable definitions and function implementations in binary form. They are incomplete by themselves - they need functions and maybye variables from each other to work, and probably some stuff from system libraries too. They are then linked with each other and aforementioned libraries to produce an actual executable.

[Corona688]

Why not make function headers implicit in the definition of a function and simply declare external functions in a different way, as is done in VB with the DECLARE statement? Its more economical and no less elegant. It means you're not stating information redundantly (syntax of function) and you're still pointing the compiler in the right direction. Because it means that the objects you're using have to be compiled BEFORE anything that uses them is, because until it's compiled the interface is unknown. Having a seperate, explicit interface means you can compile in any order without waiting for anything else. On a 16-processor machine you can fork off 16 seperate compile jobs and do the whole thing all at once, then link the mess together while a delphi compiler would still be figuring out which one it has do to first.The explanations make sense, but what they explain doesn't seem the intrinsicly "right" solution to the problem. Nope, and I don't recall claiming it was. But it works, and is very good at what it does - try writing an operating system in Visual Basic.In fact, given C's reputation for economy of expression the method adopted seems to run counter to the purported strengths of C and C++. Not exactly. You *could* cram all the code into a header file if you wanted to. That's just not the way it's usually done, since it forces the compiler to reprocess the entire frigging thing every single time it compiles a file.

#include "file.h" is very literal, you see. It does exactly that - includes it, reading the literal contents of file.h and plunking them down inside the source during preprocessing.Similarly for "->" the explanation makes sense but the method it describes doesn't necessarily. Since P.method or P.Variable is not allowed as a valid syntax when P is a pointer, why not have the compiler simply assume (in a similar manner to implicit typing) that Pointer.Blah always means (*Pointer).blah? More work for the compiler, more complexity in the language, more potential for ambiguous statements, etc. Having operators do one and ONLY ONE thing makes it easier on everybody.

That, and the strict difference between pointer operators and object operators is there to remind you of the difference. Things that you dereference with -> ought to be checked for validity first, unless you can guarantee they're valid pointers. That's what bugs me about the 'pass by reference' in C++, by the way - It's a hidden pointer, and by hiding it you make people think you don't need to error-check it. You do.

[Corona688]

No arguments. But I don't have to like it when the language needs me to consciously reference and dereference pointers. A matter of taste, I guess. I prefer explicit pointers, because you can error-check them.I don't think this is so much an aspect of the language but the environment in which they run. With virtual machines such as the JVM or the CLR, do you think pointers will need to be "bodged" in later? Possibly, though not in the form of absolute pointers, more stack offsets.

[JoeP]

Christ, I've just realised I haven't used inheritance in about five years. Looking at virtual methods and minimally defined descendant classes is confusing the hell out of me. I've gotta learn a whole bunch of reflex mental habits now.

So what have you been doing? Dirty capitalist commercial database stuff? :wink:

[ceptimus]

Anything you can do in C++, you can do in plain C. C++ was originally, and sometimes still is, implemented as a preprocessor that converts the C++ code into plain C before passing it to a C compiler.

I like pointers. You can have pointers to pointers, pointers to functions pointers to arrays of pointers and so on. One of the things I hate about VB, when I have to use it, is that there are no function pointers.

I mostly don't use the C++ extensions. I find I can do most everything I want using plain C. I think the object oriented stuff comes into its own on really huge projects, or where a team of programmers are working on a project.

[Ronin]

I mostly don't use the C++ extensions. I find I can do most everything I want using plain C. I think the object oriented stuff comes into its own on really huge projects, or where a team of programmers are working on a project.



:faint:

[Farren]

Anything you can do in C++, you can do in plain C. C++ was originally, and sometimes still is, implemented as a preprocessor that converts the C++ code into plain C before passing it to a C compiler.

I like pointers. You can have pointers to pointers, pointers to functions pointers to arrays of pointers and so on. One of the things I hate about VB, when I have to use it, is that there are no function pointers.

I mostly don't use the C++ extensions. I find I can do most everything I want using plain C. I think the object oriented stuff comes into its own on really huge projects, or where a team of programmers are working on a project.

Sounds like John Carmack. I read a rant of his in an old .plan file about how he'd been crunching his way through DirectX for 6months and decided it was simply a vast web of excess terms, then proceeded to extol the virtues of procedural code for both speed and economy of size. At the time I knew nothing about C++ or existing commercial game engines and I thought "Wow if John Carmack says it all those OO-bots must be wrong"

Zoom forward a bit and I've spent 6 months modding Unreal in the sublime Uscript, which is like C++-lite, and using the WOTGreal editor, which is so full featured it looks like a commercial IDE. The entire Unreal architecture is just incredible. It's the very picture of elegance. Everything makes perfect sense. And its very, very fast, easily as fast as the Quake engine.

About six months after this I decided to try my hand at modding Jedi Knight II, which is based on Quake Arena. Compared to Unreal - compared to any commercial thing I've seen - the code is horrible, horrible, spaghettified nightmare zone stuff.

Its not difficult to read because there is so little of the extended C++ stuff, just functions and more functions winding all over the place in a manner that can be followed step by step but is completely, utterly, arbitrary.

And when I say arbitrary I don't mean optimised arbitrary. I've done a fair amount of optimisation, even in my boring VB work stuff, like unwrapping loops for speed and converting strings to byte arrays before working with them for ditto. I know it can make code ugly.

The Quake code was just crap. There was one function with a for next loop looping through all possible combinations to arrive at a result, when clearly a single computation would do the trick. I ran it by two other programmers to see if I was missing something but no, it was just crap code. Perhaps it was the LucasArts guys addition to the code but it was ugly.

There was code just dumped in functions that had a completely different purpose to what the snippet at the end was doing. Just dumped there because that function happened to be called when they wanted a completely unrelated bit of logic to execute as well.

I can't remember the exact details but it was something like if I wrote some code to check the keyboard and I dumped it in another function, like DateTime() that returns the date because somewhere else in the code a statusbar checks the date and time with about the same amount of frequency that I want to check the keyboard. That kind of shit. Where you decide you're no longer going to display a clock and suddenly keyboadr input stops working.

Horrible. Later I spoke to an absolute C nutter and long time modder who said he's found Wolfenstein-era code in the Quake engine.

Uh uh. When I first encountered OO I was a big skeptic but I can't imagine a project of any reasonable magnitude, including game code, not being entirely OO. IMHO procedural stuff is OK if you're going to be the only person working on a project and you're not going to have go away for two years then come back and understand it again. That, and sticky tape stuff like small utilities and Internet scripts.

[Corona688]

Uh uh. When I first encountered OO I was a big skeptic but I can't imagine a project of any reasonable magnitude, including game code, not being entirely OO. IMHO procedural stuff is OK if you're going to be the only person working on a project and you're not going to have go away for two years then come back and understand it again. That, and sticky tape stuff like small utilities and Internet scripts. OO has it's uses, definitely. And as I demonstrated above, it is entirely possible to do object-oriented code in pure C. You can even do inheritance with the 'union' operator, and virtual functions with function pointers.

Not that I advocate everything being pure C. No, no, nonono. I just think it's always a good idea to know what the language is doing underneath all these pretty time-saving constructs, else they do something you not expect. And external libraries should be the lowest common denominator in all possible circumstances - that way, both C and C++ can use them. It's no big deal to wrap C libraries in a sparkly C++ class if you really need it. Nobody gets screwed.

Bad code is bad code, period. You can write bad code in C, C++, VB, Java, assembler, perl, sh, forth, and intercal. You can also write good code in any of these(with the possible exception of intercal).

[Farren]

Bad code is bad code, period. You can write bad code in C, C++, VB, Java, assembler, perl, sh, forth, and intercal. You can also write good code in any of these(with the possible exception of intercal).

True. And you can write a novel in Vi. Its just a LOT easier to write large, elegantly structured and readable programs using an object oriented language.

[Corona688]

True. And you can write a novel in Vi. Its just a LOT easier to write large, elegantly structured and readable programs using an object oriented language. And I maintain that it is practical do to so in C. Many object-oriented constructs and libraries have been created and used in C, including the linux kernel, X, openssl, Gnome, SDL, and gcc. I do not consider them any less usable or comprehensible for being written in C, but they are much more sturdy and portable for having been written in C. Even when I write libraries in C++, I am very careful to ensure they export to the C namespace so both languages can use it.

[seebs]

But why in separate files? 'interface' and 'implementation' serve exactly this purpose in delphi/pascal and enable fast compilation.

What makes you think there's a single file to implement a header?

Consider something like <stdio.h>, which has a number of files some of which are public and some private, but all of which are related.

Anyway, it's nice to be able to give out the interface without exposing code. If you use <stdio.h>, you don't even have a COPY of the real code, you're just using the defined interface - and it is, indeed, faster to parse that interface than to parse the whole file.

And it seems to me the need for different member notations is solved by strong typing. object.member works in delphi because the compiler knows object is a pointer and automatically dereferences it. Likewise :: - class functions are class funtions and declared as such. You don't need a different notation to access them.

C is strongly typed enough that you could do this; the notation is probably partially historical from BCPL-era programming, where an object was an object and you could use it either way.

I actually like having the different notation, because it makes it easier to see what the object is that I'm using, and catches the possible errors where I mistakenly think I have one thing rather than another.

[seebs]

True. And you can write a novel in Vi. Its just a LOT easier to write large, elegantly structured and readable programs using an object oriented language.

Er.

What should I be using instead of vi?

I ask sincerely. I am a full-time writer, and I have written a book, not to mention hundreds of thousands of words of non-book stuff.

I wrote the book in vi. It was dramatically faster than any of the alternatives I've seen.

[Farren]

Holy shit seebs! You wrote a book in vi? vi is an abomination, a horror, a counter productivity tool!

Seriously though, back in the day when I was a journalist for a while (DOS era) Caxton press used a word processing program called xywrite which like vi had lots of fiddly command line stuff. It took me about a week to memorise everything, like the codes for multiple columns, justification and so on and then it was plain sailing.

I was chatting to a friend of mine the other day and speculating how, were I to encounter xywrite again, it would probably take forever to learn because of an in-built resistance to the format (like the zen story with the full cup).

I know quite a few guys who are 100% happy with vi, but what I absolutely refuse to believe is that you can do everything you can do in a modern word processor like Word or OpenOffice in vi - at the same speed.

Come on! Inserting pictures, setting the text wrapping to be asthetically pleasing, floating frames, columns, bullet text, numbered bullet text, legal numbered bullet text, editing comments, line spacing, styles, style sheets, automatic insertion of contents, index and footnotes, page headers and footers showing last save file name automatically, automatically updating page number of total page numbers? You gotta be kidding me.

Its bizarre, as some of my friends do, to claim that you can do everything in vi as easily and quickly as it can be done with a visual word processor. I've no doubt for simple scripts and layout an experienced vi user can work at a fair clip, but there are a whole ton of tasks (like working with captioned images) that are just way, way better suited to the WYSIWYG environment.

Hell I haven't written a book ... yet ... but I've written about 110 chapters of various books that never got finished, lots of articles (post xywrite) for various publications and tons of huge needs analysis and specification documents. I wish I could could come over there and take the word processor challenge against you, word for word, and see who gets the same document out in the fastest time using their tool of choice.

On the other hand, we could just compare penis sizes :D

[seebs]

I know quite a few guys who are 100% happy with vi, but what I absolutely refuse to believe is that you can do everything you can do in a modern word processor like Word or OpenOffice in vi - at the same speed.

Ahh, but ninety percent of what you do in a "modern word processor" is not writing, it's formatting. Or, in my experience, fighting with the formatting. Word's attempts to "help" me consumed about 20% of my time when I was using it.

Come on! Inserting pictures, setting the text wrapping to be asthetically pleasing, floating frames, columns, bullet text, numbered bullet text, legal numbered bullet text, editing comments, line spacing, styles, style sheets, automatic insertion of contents, index and footnotes, page headers and footers showing last save file name automatically, automatically updating page number of total page numbers? You gotta be kidding me.

But most of those aren't part of writing a book. I wrote my book in DocBook. Text wrapping? Done automatically. Columns? Don't need 'em. Floating frames? I think I may have used sidebars. Bullet text? Specified as lists, and without the problem that deleting a character somewhere in a line might cause it to become part of a separate list, or having other paragraphs added to the list unpredictably. Line spacing, style sheets? Handled by the formatter. Page headers and footers showing file name? Don't want 'em. Contents, index, and footnotes? Done automatically. Page numbers, done automatically.

But that's rendering.

And not having to wait for the computer to do it, or fuss with it, is a big plus.

So... Here's the thing. All that mousing around is cognitively engaging, so it feels fast, but it actually takes a lot of time. The time it takes, with your hands already on the keyboard, to type ":w<CR>:e flashy.xml" is very short.

Its bizarre, as some of my friends do, to claim that you can do everything in vi as easily and quickly as it can be done with a visual word processor.

Ahh, but I'm not doing everything. I'm writing a book. Formatting it is a job for a program to do without bugging me about it.

I've no doubt for simple scripts and layout an experienced vi user can work at a fair clip, but there are a whole ton of tasks (like working with captioned images) that are just way, way better suited to the WYSIWYG environment.

I dunno. I was pretty happy with:


<figure id="tradeoffs-macif">
<title>Inactive (left) and Active window decorations for
iSync, QuickTime Player, and Terminal under MacOS X 10.2</title>
<graphic fileref="macif" srccredit="Peter Seebach, 2003">
</figure>


Hell I haven't written a book ... yet ... but I've written about 110 chapters of various books that never got finished, lots of articles (post xywrite) for various publications and tons of huge needs analysis and specification documents. I wish I could could come over there and take the word processor challenge against you, word for word, and see who gets the same document out in the fastest time using their tool of choice.

The more tweaking you do per document, the more useful WYSIWYG is, but even then, I tend to write in raw text and apply formatting at the end. What most of the writers I work with have learned is that, once you have your macros or DocBook stylesheet set up, you're done; you never have to think about the formatting again.

Hmm. Here's a frame of reference: I write about a thousand words an hour, give or take. When I was working on my book, I did about 20,000 words in a week, with all the formatting and images done correctly... Automatically.

On the other hand, we could just compare penis sizes :D

... I think the girls would kill me.

[wade-w]

Funny you should mention xywrite, Farren. My mother, who is as non-technical as you can get, but who is also a professional writer/editor, used to swear by it. She claimed she could get more done in less time with xywrite than with any other word processor that was on the market at the time.

This statement was not mere hyperbole; my father was writing a weekly syndicated column on computers at the time, so they got every word processor there was from the vendors for review purposes, along with all updates. (While he was writing that column, Dad used to get 2-3 pieces of software per day on the off chance he'd review it in a column; games, productivity software, office suites, you name, he got it, almost all unsolicited) They also devised a document designed to put the application through it's paces for comparison purposes. I'm told that xywrite was an order of magnitude more effecient than anything else.

Anyway, seebs is correct, imo. Using vi with a markup language such as docbook or some TeX variant is much more effecient than any modern word processor like Word or OpenOffice.

[Corona688]

No way. Use ed (http://www.gnu.org/fun/jokes/ed.msg.html).Ed, man! !man ed

ED(1) UNIX Programmer's Manual ED(1)

NAME
ed - text editor

SYNOPSIS
ed [ - ] [ -x ] [ name ]
DESCRIPTION
Ed is the standard text editor.Let's look at a typical novice's session with the mighty ed:golem$ ed

?
help
?
?
?
quit
?
exit
?
bye
?
hello?
?
eat flaming death
?
^C
?
^C
?
^D
?Note the consistent user interface and error reportage. Ed is
generous enough to flag errors, yet prudent enough not to overwhelm
the novice with verbosity. The Standard. Text Editor. :cool:

[Farren]

You all suck quite a lot. Linux I can understand, even commend. Ditto for C/C++. But ed!!!???? vi!!??!!!??? Geez. Join the rest of us in the twentieth century some time :D

[Farren]

Tell me something, do your cars have holes in front of the drivers seat so you can push them along with your feet, or bicycle-like pedals?

[Corona688]

Oh hell, I don't USE ed. Nothing except some deeply-embedded UNIX scripts use ed. I just thought it would be fun to point out the worst text editor in the history of mankind. Don't use vi, either, it's really efficient but I think you have to learn it from birth.

I do use nano, however; the UNIX-equivalent of MS-DOS edit, but with nifty features like programmable syntax highlighting.

This is because I do a hell of a lot of stuff remotely though. I logon to my home machine via ssh then do stuff from commandline. Commandline's not particularly useful under Windows, but under linux it's eerily powerful. On a properly-equipped machine I can even do graphical things remotely.

[Farren]

Oh hell, I don't USE ed. Nothing except some deeply-embedded UNIX scripts use ed. I just thought it would be fun to point out the worst text editor in the history of mankind. Don't use vi, either, it's really efficient but I think you have to learn it from birth.

I do use nano, however; the UNIX-equivalent of MS-DOS edit, but with nifty features like programmable syntax highlighting.

This is because I do a hell of a lot of stuff remotely though. I logon to my home machine via ssh then do stuff from commandline. Commandline's not particularly useful under Windows, but under linux it's eerily powerful. On a properly-equipped machine I can even do graphical things remotely.

I'll admit when you're connecting through a fancy cell phone at 9600 to a server command line rules.

[Corona688]

I'll admit when you're connecting through a fancy cell phone at 9600 to a server command line rules. command line rules for all sorts of things. Try renaming 300 files with a GUI interface - you can do it, but it'd take either incredible patience or some special-purpose GUI power tool.

If you're accustomed to a windows machine then I understand - windows console is bloody useless. It's aging, weak, inflexible, undocumented, bug-ridden, unhelpful, and hasn't really changed in 20 years. And even if someone were to port bash or korn to Windows(maybye someone has, I dunno) it'd still be useless since xcopy is just about the only good general-purpose utility left standing after 15 years of Microsoft's paring away.

It really doesn't compare to a modern shell with a full set of tools. I run a full-out gui at home, yet half the windows I have open tend to be consoles doing various things.

[seebs]

Authoring Web content with ed(1) (http://www-106.ibm.com/developerworks/web/library/wa-aprilfools.html?ca=dnt-513)

(Annoyingly, the filename spoils this.)

Seriously, though... If you want me to stop using vi, go ahead and recommend something that's faster for ACTUALLY WRITING. I spend very little time on formatting; that's why they have publication asssistants. I occasionally do XML, but it's not my JOB to line up margins, and time spent lining up margins is time spent not actually putting out words.

And yeah, Emacs is genuine competition. So's BBEdit.

[Corona688]

And yeah, Emacs is genuine competition. So's BBEdit.
”On a normal ascii line, the only safe condition to detect is a ‘BREAK’ - everything else having been assigned functions by Gnu EMACS.” (By Tarl Neustaedter)

[seebs]

And yeah, Emacs is genuine competition. So's BBEdit.
”On a normal ascii line, the only safe condition to detect is a ‘BREAK’ - everything else having been assigned functions by Gnu EMACS.” (By Tarl Neustaedter)

Heh. Well, there is a reason I use vi instead of emacs. I don't want a bunch of "mnemonics" I'll never remember; I want cursor keys grouped for my hand to use them.

[Ray]

If you're accustomed to a windows machine then I understand - windows console is bloody useless. It's aging, weak, inflexible, undocumented, bug-ridden, unhelpful, and hasn't really changed in 20 years. And even if someone were to port bash or korn to Windows(maybye someone has, I dunno) it'd still be useless since xcopy is just about the only good general-purpose utility left standing after 15 years of Microsoft's paring away.
Someone has ported not only bash, but a good collection of command line utilities (including cp) to Win32: MinGW (Minimalist GNU for Windows) (http://www.mingw.org/) I've been using it for a year or so, and find it to approach the flexibility of a real Unix system.

[seebs]

There's also cygwin. Which is curiously very similar to an earlier project of porting GNU stuff to the Amiga.

[livius drusus]

Hi Ray! I have no idea what y'all are saying in this thread, but welcome to FF. :welcome2:

[Farren]

If you're accustomed to a windows machine then I understand - windows console is bloody useless. It's aging, weak, inflexible, undocumented, bug-ridden, unhelpful, and hasn't really changed in 20 years. And even if someone were to port bash or korn to Windows(maybye someone has, I dunno) it'd still be useless since xcopy is just about the only good general-purpose utility left standing after 15 years of Microsoft's paring away.
Someone has ported not only bash, but a good collection of command line utilities (including cp) to Win32: MinGW (Minimalist GNU for Windows) (http://www.mingw.org/) I've been using it for a year or so, and find it to approach the flexibility of a real Unix system.

Sweet. I'm downloading it. Thanks for the link.