Fair enough, that was a bad example on my part. As you say, though, my point certainly does hold for many of the current "next gen" FPS types. Storylines do make a difference in single-player, of course -- witness Deus Ex for example -- but again, it's usually the quality of the story that really makes those games stand out, not the funky graphics.
Whereas I do spend a signficant amount of time on the Internet, both at home and at work (and usually in connection with my work, in the latter case). But I could stop any time I wanted to. I know I could. I wouldn't even miss it much. Really, I could. Honest.
Seriously, though, despite there being things I do miss when I'm away from the Net for a while, I have plenty of other things I enjoy doing off-line as well. I just spend more time doing those if there's no net connection around. My biggest concern with being off-line for several days is more the amount of spam I have to wade through when I get back, just in case there's something important in there.:o)
Except that by definition you can't scientifically prove anything. All you can do scientifically is advance a theory and show that is supported by experimental evidence available at the time. That's kinda the point of science: it's only as good as the evidence underlying it, and as new evidence comes to light, theories can and should be revised or dropped if this is what the evidence supports.
You typically sign an agreement that says work that you do on your own time and hardware without any of your previous companies resources is owned by you.
Unfortunately, for many people that isn't true. A lot of employment contracts these days, particularly from big companies, seem to claim blanket IP rights to everything the employee does while employed (regardless of any connection to the employment).
Personally, I refuse to sign such contracts, and in fact after a takeover a couple of years ago so many staff from our formerly small and privately-owned company objected to the aggressive IP clauses in the new contract that the new employer had to throw it out and give us the old wording back, complete with exceptions for things not related to our employment.
But many people, particularly the young and inexperienced, don't appreciate this, and some do get screwed because of it.
Of course games don't have to be next-gen to be fun.
My two favourite games of all time, both first time through and for replay value, are still the Baldurs Gate series and Total Annihilation. In the several years since these were released, I've encountered no RPG with better plot/characters, and no RTS that was better for all-out action combined with genuine strategy.
My other half is a big fan of puzzle games. She has spent many hours enjoying the games from PopCap, and spent more money buying the full versions of her favourites from them than on any trendy 3D FPS.
Sure, funky 3D graphics and a rocking soundtrack can make some games more atmospheric. It's not like there's much comparison between Gears of War and Wolfenstein 3D (or perhaps more fairly, Quake) in the presentation department. But much as I have enjoyed many FPS games over the years, the gameplay is still pretty close to the original Wolf3D/Doom/Quake model that popularised the genre all those years ago, even if I can now use different weapon types, lob grenades with my other hand, and drive vehicles.
Where I personally find the gaming experience lacking is on-line competition/collaboration. Many games I've played are no doubt much more satisfying against real people, but IME pretty much all of the on-line services suck if you're not in the US (lag issues) or not willing to spend silly amounts of time waiting around for an opponent. The only games I've ever played on-line for long and truly enjoyed were Quake and Quake II in my university days, when there was an active student population and getting a good deathmatch game going was easy. For TA, it was too hard to find an opponent of a similar skill level and to set aside an hour or two for a good game. For Neverwinter Nights, I never even worked out what on-line facilities were available, as I'd lost interest because of poor single-player. Lots of people seem to enjoy things like World of Warcraft (and I notice they've been running ads for it on TV here in the UK in the run up to Christmas), but I also hear a lot about powergamers who can arbitrarily spoil it, which puts me off trying it given the cost involved.
Of course, my system is a little long in the tooth now -- it's about time to build a new ueber-PC but I haven't got around to it yet -- so I'm not running much from within the last year or two. Do the latest "next gen" games have good player-matching for on-line competition as well as the snazzy graphics? If they do, then maybe next gen games are the future after all.:-)
You can't protect UI using IP laws in most places. MS can have copyright of their guidelines, but there's nothing to stop the OOo developers going ahead and implementing a ribbon-like UI anyway.
OK, I'll play. Mr AC, I think you have missed my point on several counts, so I'll elaborate.
Documents templates are underpowered in Word. Sure, you can create a document and save it as a.dot file, and you can stuff a few styles and wotnot in there, which is a good start. But when a user creates a document based on that template, they can still edit anything they want, including inadvertently/unknowningly. I want a system where the guys designing the documents need leave nothing but a "fill in the gaps" exercise for their colleagues, without relying on a hideous combination of obscure field codes, macros, document protection and the like to approximate it. As an aside, if we're talking about an integrated Office apps suite, a framework for using these documents as part of established processes wouldn't go amiss either, though that's not quite the same issue.
Neither Word's styles nor the OO stylist have even close to the power the concept should offer. Word these days can't make up its mind whether a paragraph style applies to paragraphs or characters! OO's styling UI doesn't even provide a keyboard shortcut for "cancel extra styles and revert to default". Hint: if I tag a block of text as emphasised, and another short phrase within that block as emphasised again, and your styling system can't deal with the common English convention of setting the extended block italicised but the inner phrase in Roman, then your styling features are underpowered. If I can't define style families so that the first item, last item and middle items of a series each have separate characteristics (e.g., borders and spacing) then your styling features are underpowered. If I can't set up relationships between styles, so that for example a paragraph starts with a drop cap and then sets the first line in small caps, then your styles are underpowered.
Numbered lists have a notoriously clumsy UI in Word, and it's very awkward to do things like breaking out of a list temporarily and then restarting it. That's not even getting into the frankly bizarre way that the list presentation is defined. OO Writer is similarly impaired in the user-friendliness department. The number of bugs in this area in both products is pathetic, as anyone who's written any sort of extended formal report can probably tell you.
If you think the kind of ToC creation in Word and OO Writer is powerful, you simply aren't in the game. Try setting up two tables of contents, one for the chapter headings with a brief description of each chapter under it, and one detailed. Get them to update automatically, without any of this users-playing-with-fields rubbish. Make sure users can actually get the cursor above or below them to insert other content without using obscure keyboard tricks because the UI is broken. Make sure the formatting can do the kind of professional layout seen in published books (which doesn't normally mean using............ leaders with tight spacing in whatever font happens to be in use for the current line's text).
You've acknowledged this one so I won't go into detail.
No, I don't want it to write my papers for me. I just don't want to have to copy and paste my document title in four different places, and then find they're out-of-sync later after we adjust the title because I didn't update the right field before printing. See also use of chapter/section/table entry titles in headers/footers, construction of tables of content and indices, etc.
If it were as easy as you say, the anecdote I gave in another post to this thread about a colleague losing nearly an hour trying to work this out would not have happened. A lot of users just don't appreciate the difference between linking and embedding among all the unnecessary complexity presented, and once a graphic is in a document, it's stupidly difficult to determine whether it's linked or embedded.
The reviewing features are clumsy, with comments stuffed down the side of a page, an awkward annotations s
Unfortunately, on the evidence to date, I fear you are wrong about the relative chances of getting bugs fixed in OpenOffice vs. MS Office (short of forking the OO, anyway).
But what you describe is a management problem. If management (a) hires dummies, (b) doesn't train the dummies, and then (c) gives the dummies tools that aren't making them any more productive (but do look pretty) then.... Ooooh, shiny!
Alternatively, management could bring in tools that will actually help staff to do their jobs, and ignore whingers who want to play instead of doing useful work. Yes, that might just do it!:-)
Whereas for me, bugs with no work around in the PDF export nearly cost a local not-for-profit group I help in my spare time a huge amount of income due to missing a key deadline. For businesses running Windows, however, it's not exactly hard to afford a couple of Acrobat licences if required.
You're right, of course, that things like graphic design and typography are skills that one has to learn. You're also right that the users in question weren't using a very good tool for what they needed to do. That's kinda my point: if we're going to have standard-issue document preparation software on every desktop in the business, it makes sense for the simple, everyday features to be the obvious things, and to hide things like detailed formatting, which only really help if done by a skilled worker, in the depths of the menu system. Right now, all the major players do things backwards.
Personally, I prefer just to edit LaTeX files with my trusty text editor and process them every now and then to see how things are looking. Your point is well taken, however: current typesetting tools are indeed much better at structuring formal documents than current word processing tools. IMHO this is mainly because current word processors are lousy at coping with the semantic significance of any given text, while if you're typesetting, you pretty much always mark up semantically by default.
Your conclusion is fundamentally flawed: it does not follow that there exist a community of programmers working on something just because a lot of people would benefit from it. For a start, that would require a significant number of programmers (a) to appreciate the need, (b) to collaborate in order to produce a solution, and (c) to be willing to do so for little or no compensation if you think they're going to write it as OSS, and (d) to be willing to do so in an apparently crowded market with a dominant commercial player, established OSS projects as competition, and a user base who have been demonstrated for the most part to prefer paying Microsoft for their offering year-on-year rather than investigate alternatives that might suit them better.
As much as you wish it, there is no need to create an application that is easy for masses to use and is at the same time capable of creating advanced documents.
Of course there is. A gazillion people use Word in this role every day. Word isn't very good at it, but most people don't appreciate that because they have little experience of anything else in recent times.
That doesn't change the fact that at a videoconference last week, with several relatively senior members of staff from all around the world and with very limited time available, we wasted upwards of five minutes while the expensive external consultant leading the presentation tried to get his bullet lists in Word to look consistent using Format Painter (which kept turning his text into Greek). He did the same thing the week before, too. Leaving aside the opportunity cost of that time, the cost to the business just to pay all those people to sit around and watch the consultant getting his document in a mess a couple of times was probably $500. In a smart document editor, his new bullet point would have just dropped into the list and formatted itself nicely the moment he typed it, or at worst required a click or two to say "this paragraph is a new item extending the list above it".
At the same company the week before, I spent most of an hour swapping e-mails and calls with a colleague on the same team who couldn't work out why a document with an included image looked fine on her machine but didn't work when uploaded onto the network for others in the team to see; this turned out to be a linking vs. embedding problem. The cost to the business for the time for two of us to fix that and the resources we used in the process was probably $200, and again that excludes the opportunity cost for our time, the time lost as I got back to my own work after the interruption, and so on.
These little things punctuate the daily lives of countless office workers around the world, wasting $100 here or $1,000 there. Those two anecdotes come from just my personal observations of one team at work over the past couple of weeks, and probably total $700 of loss to the business. This is more than enough to send the culprits on a basic training course, or to buy a couple of licences for better software. As the saying goes, if you think training is expensive, try ignorance. Likewise, a smart craftsman with good tools will tend to get better results faster than a low-skilled worker with inadequate tools, even if the latter doesn't realise what he's missing.
OK, here's an immediate reply, right off the top of my head after reading your post. What's more, I'll only refer to the word processing component. I bet I get to ten within two minutes.
Building and using document templates
Defining and using styles for formatting
Numbered/bulleted lists
Tables of contents and indices
Cross-references, citations and bibliographies
Intelligent reuse of key text
UI for importing from or linking to graphic files
Commenting and review by people other than the author
UI for table formatting
Grammar checking
I think that's ten, and I basically haven't stopped typing for more than a few seconds between each.
As for how I'd fix them, well, I gave some description of how I'd organise a document preparation tool above. I wouldn't try to fix them with OOo Writer in its current form, because it has too much baggage: IMHO, you need a fundamental change in approach and UI priorities.
It means that the community actually sees merit in having a free (as in freedom) MS Office clone.
Or just that the groupthink and/or drive from Sun (who pay for the vast majority of OOo development) currently tend towards emulating Microsoft.
I look at it this way: the biggest OSS success stories, IMHO, are Linux and Firefox. They have successfully displaced a worthwhile amount of market share from an established, commercial competitor, something few other big name OSS projects can claim to have achieved so far. And they didn't do it by trying to be Windows and IE, they did it by trying to be a good OS package and a good web browser. I didn't switch to Firefox because of its similarities to IE, I switched because of the differences, from the overall design philosophy (simple main app, plug-in culture) to the subtle UI touches (unobtrusive find bar when I hit Ctrl+F).
Word, in particular, is crying out to be overtaken by a piece of software that provides WYSIWYG cuteness for the masses but makes it easier to create serious documents. Word should have no market: it should be being beaten for those who only write letters and to-do lists by simpler and cheaper tools, for those doing basic DTP by the low-end DTP packages, for those writing heavyweight long documents like books by typesetting packages or high-end DTP, and for the countless users writing diverse documents with a bit of structure and formatting by... an application that no-one's written yet, which is why we still use Word at the office.
I'm sure I'm not the only person who programs, writes lots of different kinds of document, and has had many ideas for alternative document creation tools. IME only, the main activities for a word processor user in a typical office are:
typing into boilerplate documents; and
crucifying document formatting and structure.
Other activities common among more knowledgable users are:
using a spelling checker;
gathering stats, particularly word counts;
inserting cross-references and tables of contents;
using common document structure and formatting features, particularly
headings,
tables,
numbered/bulleted lists,
headers and footers, and
inserting pictures;
and
using collaboration features such as adding/reviewing comments.
Power users also do things like:
mail merges; and
creating templates for various document types.
I have never yet seen a business taking anything like full advantage of the automation interfaces of any word processor, nor any effective use of abominations like WordArt and not much of Equation Editor.
From my own experiences, then, I might guess that a good writing tool (in the sense of being quick and easy for users, and producing high-quality documents) would focus on letting power users set up document structure and formatting, and then presenting a vastly simpler interface to actually edit the document: almost a "fill in the blanks", with simple commands for things like checking spelling and word count. Let people apply predefined formatting and structure (based on things like what power users would call stylesheets, not randomly applying bold, all caps, double-underlined, centred, hand-typed numbering, etc.). Let them insert cross-references, again with predefined appearance. Have the software automatically reuse key text, so typing something in the "title" area on the front page automatically updates the headers as well, and changing a heading automatically updates the table of contents; this is one of the most common "unprofessionalisms" I see in documents, and it's not like it's rocket science!
Basically, put the focus on what the user is writing, with simple interfaces for the common tasks everyone needs. Then leave things like the details of formatting and document structure to the power users who can
OK, I have made my usual Slashdot typo of writing RIAA for RAII. I hereby withdraw from the argument, and will hang my head in shame for the remainder of the week...
I have only one suggestion: stop trying to be a better MS Office than MS Office (which OO never will be, for several unavoidable reasons) and start trying to provide key functionality better than MS Office does, with a different interface if necessary. Seriously, it's not that hard a target!
The best things are always the most popular right? That's why windows is so popular, because its so awesome.
Actually, I think it's more akin to why Linux is very popular for some tasks among geeks and professional sysadmins, yet rarely seen on home user desktops. It's the difference between the adoption of a mass-market, good-enough tool promoted by a wave of corporate advertising, and a tool that an informed group of users choose after serious consideration.
You said that you had to use C++ because D would not do the job.
I said no such thing. I have made no comment on what jobs D can't do at any point in this thread. I have simply argued that for the kind of work I do, D does not offer sufficiently compelling advantages for me to justify choosing it over C++.
Or perhaps, since you have admittedly already invested the time learning about much of C++'s sharp toothed and hungry areas, and you are used to dealing with that crap, you don't notice what a pain C++ is?
You know, it's funny. I've been training a new starter at work recently, someone with a background in Java but little C++. After just a few hours of training, looking at how C++ is put together and why certain things work as they do, he doesn't seem to be falling into all these terrible "traps" that are commonly asked about in on-line forums and the like. So, is this guy a genius, am I the best teacher in history, or have the newbies just not bothered reading the textbooks or getting proper training before trying to use a complicated tool?
Which isn't to say C++ isn't a royal PITA at times, of course, just that it's not usually the silly little gotchas that make it so.
None of this changes the fact that you pretended that C++ having a book full of traps is ok, because "experienced programmers" will have memorized them all and will always remember them.
Of course it's not OK. I'm still waiting to find any programming language I don't consider seriously flawed in many ways. But as a practical tool, C++ has a lot of merit for the kind of work we do, and these gotchas just aren't the show-stopping horrors you make them out to be.
C++ undeniably has an image problem, though: so many of the books are populist "50 ways not to blow the whole leg off" exercises that almost no-one has actually bothered to present the language features in a positive light as an integrated whole. Hence the only people who really appreciate things like the power of the RIAA idiom are the kind of high-flyers who also read things like D&E (or at least to read more than the first half-dozen chapters of a good introductory book). But these people don't learn all the gotchas to avoid them; they understand how the language is put together, and simply don't run into the gotchas in the first place.
Its a great book to read, and a very good example of how you can make reasonable decisions, and end up with a horrible pile of crap.
Why do you persist in calling C++ unpleasant names and advocating D instead? No-one's claiming C++ is perfect. Take a look at my posting history; I've certainly criticised it many times and for varying reasons! But if it were really as bad as you make out, then it wouldn't be one of the most successful programming languages ever, and if D were so much better then surely a lot more smart programmers would have switched over by now?
I don't understand the strength of your advocacy here. You seem to have labelled me as some sort of C++ evangelist, when in fact I'm just a guy using a tool. Since we did our homework into how to use that tool and how it compared with the alternatives, I'm quite willing to stand up and defend a considered choice we made, but that doesn't mean I'd recommend the same choice for others or make the same choice myself under different circumstances. You, on the other hand, seem to think it's up to me to argue that D is not superior to C++, despite the fact that you keep claiming good things about it without actually giving any concrete examples of where it's good while C++ is a "pile of crap".
Incidentally, your claim about Bright having more practical experience with C++ than Bjarne does not ring true. He may (or may not) know more about writing C++ compilers, but C++ is useful for a great deal more than writing compilers, and being good at writing compilers is far from the same as being good at designing programming languages. I find much of Bright's reasoning behind his "improvements" in D to be flawed, while Stroustrup's considered arguments for many of the "tricky bits" of C++ that you dislike so much generally stand up to scrutiny. Perhaps this is why I like C++ as a practical tool for real programming jobs, but saw few real improvements over it in the design of D.
However, this thread seems to be going nowhere. I see now why Bjarne stays well clear of language politics. I should spend more time using the tools to do useful things and less time talking about them.
I have read your posts, but you keep moving the goalposts. I stated, several posts ago, my conclusions about D: some possible improvements over C++, some steps backwards, but overall nothing spectacular that motivates me to move. I didn't say D was in some sense unacceptable, just that it offers me no sufficiently compelling advantages to consider it far superior to C++ as you seem to. Then again, I also don't seem to suffer from all these terrible problems you ascribe to C++.
You, however, wrote:
"Take D for example, its basically C++ as DESIGNED by someone who actually has experience having to write code."
What qualifies Walter Bright and co as "actually having experience having to write code"? Do you think Bjarne Stroustrup never wrote any real code?! He wrote a whole book on how he reached his decisions about how C++ would work, and it's an enlightening study of how to make a highly successful programming language.
So, what advantages does D really offer over C++, ignoring that hopelessly misleading feature comparison chart on the Digital Mars web site? Why should I, as a professional programmer with a tool that works well for the job I'm doing, invest the time and effort to learn a new language and port about 50 man-years of code to a relatively untried language with no standard, little formal support and minor commercial backing, and few users? What compelling advantage does your/Bright's proposed alternative offer me?
I don't understand what you're getting at with OCaml, either. Again, I have nothing against the language. On the contrary, I think in many ways it's rather nice. However, I have seen nothing to suggest that its impressive performance relative to other functional programming languages comes from anything other than its imperative roots. Moreover, if the example you quoted is your idea of typical functional programming then we have very different ideas indeed about what characterises that particular programming style. Merely using functions is not the same as functional programming, even if one of them happens to be recursively defined.
FWIW, the number is actually 5 for a large portion of the game (about halfway thru Act 2). The older ones were 6 maximum, correct? In any event, it beats the number NWN1 imposed in the single player campaign;).
That's a great relief.
I loved the BG series, in no small part thanks to the detail of the party-joining NPCs and their custom side-quests on my first couple of runs, and the flexibility in building my own power-gaming party on another occasion. I had been looking forward to NWN with great anticipation, yet never got beyond the first few hours of gameplay. An adventurer and random side-kick do not a party make. I've heard good things about the expansion packs, player-written campaigns and DM stuff, but never experienced any of them; I lost interest. If NWN2 offers some party-based game-play with the same kind of visual appeal and detailed character development that underpinned NWN1, it may yet be worth playing...
Wow, I must have really touched a nerve there somewhere! You seem to have much stronger feelings on this than I do, so let me assure you that I am in no way a "C++ man" and in every way a "right tool for the job" man. At work, I currently write C++ for the heavyweight mathematical stuff and Perl for the analysis tools. At home, I am currently maintaining a web site, which involves PHP, Perl, SQL and occasionally Javascript. I've worked with countless other languages from C and various assemblers through Java and C# to various functional languages.
Now, to address your major points quickly...
When I'm talking about safety vs. flexibility, I'm really talking about the sort of low-level fiddling common in systems programming and high-performance fields. Either you can ignore things like type systems and just twiddle bits and hack memory, or you can't. If you can, your language is flexible in this sense but unsafe. If you can't, your language may be safer, but it will not allow some flexibility. There is a fundamental dichotomy here.
As for the numerical performance issue, I have several years of professional experience in this field, and I work with a large number of other people who do likewise, both at my own office and those we work with. We've heard this argument before, done the benchmarks, looked at the assembly. Your comments about FORTRAN are simply wrong. Think about it: what magical gift does FORTRAN have that means it can generate faster mathematical code than C++, or any other low-level language for that matter? Sure, FORTRAN effectively has built-in support for common optimisations that aren't possible using naive code in other languages, but techniques to avoid the overheads were developed for C++ years ago. Moreover, as I said before, some of the more useful FORTRAN-based numerical libraries can readily be wrapped and called from C++ to avoid unnecessary porting effort anyway.
Your assembly language argument also misses the point. We ship on probably a dozen different hardware platforms today, and the assembly languages for those are constantly evolving with the release of new processors. C++ has been standardised for nearly a decade, with only minor changes in the 2003 revision. The effort to learn C++, warts and all, is tiny compared to the effort to learn and stay up to date with a dozen different assembly languages. Why would we take the time to reinvent a wheel that specialist compiler writers have already crafted to a high standard?
As for D, check my posting history for many times I've criticised it on various objective grounds. In this particular context, one might add that AFAIK there isn't even a D compiler available on several of the platforms we support.
Incidentally, I notice that you used the word "shootout" while talking about that. I do hope your assessment of the relative performance of different programming languages isn't based mainly on a single well-known web site of relatively trivial benchmarks.
As for OCaml and getting performance out of functional code, I will simply ask you to provide a single, non-trivial example where this has been shown to be the case. I note that in everything from the kiddie benchmarks on the shootout site to the high-scoring submissions in the ICFP, the fast OCaml pretty much invariably falls back on imperative techniques. The overheads incurred in dealing with functional techniques appear to be too great for current compilers to keep up with imperative code. Perhaps this will change with the development of better optimisation techniques in time, but I'm talking about today.
Why do you make the assumption that well designed languages that aren't full of horrible ways to accidently shoot your feet off are "safer but less flexible"?
Because by their nature, safety and flexibility are almost invariably opposite ends of a programming language spectrum.
Take D for example, its basically C++ as DESIGNED by someone who actually has experience having to write code. Where is D or ocaml or SML or lisp any less flexible than C++?
I spent a bit of time exploring D. And then I dropped it, in the same pile as Java, as having a few improvements over C++ and a few steps backwards, but overall nothing revolutionary that would help me enough to justify the switch. The fact that the Digital Mars web site has a grossly misleading feature comparison chart between D and other somewhat similar languages did not exactly fill me with faith, either (and no, listing a gazillion footnotes under C++ entries by way of disclaimer is not the professional programmer's answer to such a situation, it's the marketing droid's answer).
OCaml is a nice language, in many ways, but not a good tool for systems programming. To get sane performance out of it, you have to throw away much of the functional programming stuff anyway, and its syntax for more imperative styles is cumbersome.
SML is a different tool entirely, and doesn't even have those imperative tools. In exchange for the neat features, you give up any semblance of ability to do systems programming with it.
The same is true to some extent of LISP, and in any case, some of us don't consider a near-uniform syntax for everything and anything to be a positive trait in a programming language, macros or no.
And high performance mathematical code is not exactly a great fit for C++, why aren't you using fortran if performance matters so much? Hell, if you have so much time on your hands to study C++ so much that you don't get bitten by its hundreds of stupidities, why not do it in ASM?
Why would we use FORTRAN? We typically get better performance out of C++, we can build our stuff on platforms that don't even have FORTRAN compilers, we can write stuff other than mathematical code with some degree of elegance, and in any case where there are things like BLAS and LAPACK implemented in FORTRAN, we can get ports and link directly to them via C calling conventions anyway.
As for ASM, it's not exactly portable, now is it? In any case, with modern optimising compilers and processing architectures, it's rather rash to assume that anyone but a serious platform expert would get better performance out of assembly than the compiler does.
Thanks for the hint. I've noticed from reviews on Amazon and the like that Programming Language Processors in Java by Watt and Brown seems to cover similar ground, but get more favourable feedback (sometimes in direct comparison to Appel's book). OTOH, I'm also wary of customer reviews on web sites, since often these are written by people who have limited understanding of a subject themselves and therefore aren't really qualified to criticise a book on technical grounds. Have you by any chance seen the Watt and Brown book, and if so, what did you think?
Slashdot Mirror
Fair enough, that was a bad example on my part. As you say, though, my point certainly does hold for many of the current "next gen" FPS types. Storylines do make a difference in single-player, of course -- witness Deus Ex for example -- but again, it's usually the quality of the story that really makes those games stand out, not the funky graphics.
Sorry, it's been a long day. Not so much broken as out of gas. ;-)
Whereas I do spend a signficant amount of time on the Internet, both at home and at work (and usually in connection with my work, in the latter case). But I could stop any time I wanted to. I know I could. I wouldn't even miss it much. Really, I could. Honest.
Seriously, though, despite there being things I do miss when I'm away from the Net for a while, I have plenty of other things I enjoy doing off-line as well. I just spend more time doing those if there's no net connection around. My biggest concern with being off-line for several days is more the amount of spam I have to wade through when I get back, just in case there's something important in there. :o)
Except that by definition you can't scientifically prove anything. All you can do scientifically is advance a theory and show that is supported by experimental evidence available at the time. That's kinda the point of science: it's only as good as the evidence underlying it, and as new evidence comes to light, theories can and should be revised or dropped if this is what the evidence supports.
Unfortunately, for many people that isn't true. A lot of employment contracts these days, particularly from big companies, seem to claim blanket IP rights to everything the employee does while employed (regardless of any connection to the employment).
Personally, I refuse to sign such contracts, and in fact after a takeover a couple of years ago so many staff from our formerly small and privately-owned company objected to the aggressive IP clauses in the new contract that the new employer had to throw it out and give us the old wording back, complete with exceptions for things not related to our employment.
But many people, particularly the young and inexperienced, don't appreciate this, and some do get screwed because of it.
Of course games don't have to be next-gen to be fun.
My two favourite games of all time, both first time through and for replay value, are still the Baldurs Gate series and Total Annihilation. In the several years since these were released, I've encountered no RPG with better plot/characters, and no RTS that was better for all-out action combined with genuine strategy.
My other half is a big fan of puzzle games. She has spent many hours enjoying the games from PopCap, and spent more money buying the full versions of her favourites from them than on any trendy 3D FPS.
Sure, funky 3D graphics and a rocking soundtrack can make some games more atmospheric. It's not like there's much comparison between Gears of War and Wolfenstein 3D (or perhaps more fairly, Quake) in the presentation department. But much as I have enjoyed many FPS games over the years, the gameplay is still pretty close to the original Wolf3D/Doom/Quake model that popularised the genre all those years ago, even if I can now use different weapon types, lob grenades with my other hand, and drive vehicles.
Where I personally find the gaming experience lacking is on-line competition/collaboration. Many games I've played are no doubt much more satisfying against real people, but IME pretty much all of the on-line services suck if you're not in the US (lag issues) or not willing to spend silly amounts of time waiting around for an opponent. The only games I've ever played on-line for long and truly enjoyed were Quake and Quake II in my university days, when there was an active student population and getting a good deathmatch game going was easy. For TA, it was too hard to find an opponent of a similar skill level and to set aside an hour or two for a good game. For Neverwinter Nights, I never even worked out what on-line facilities were available, as I'd lost interest because of poor single-player. Lots of people seem to enjoy things like World of Warcraft (and I notice they've been running ads for it on TV here in the UK in the run up to Christmas), but I also hear a lot about powergamers who can arbitrarily spoil it, which puts me off trying it given the cost involved.
Of course, my system is a little long in the tooth now -- it's about time to build a new ueber-PC but I haven't got around to it yet -- so I'm not running much from within the last year or two. Do the latest "next gen" games have good player-matching for on-line competition as well as the snazzy graphics? If they do, then maybe next gen games are the future after all. :-)
You can't protect UI using IP laws in most places. MS can have copyright of their guidelines, but there's nothing to stop the OOo developers going ahead and implementing a ribbon-like UI anyway.
OK, I'll play. Mr AC, I think you have missed my point on several counts, so I'll elaborate.
Unfortunately, on the evidence to date, I fear you are wrong about the relative chances of getting bugs fixed in OpenOffice vs. MS Office (short of forking the OO, anyway).
But what you describe is a management problem. If management (a) hires dummies, (b) doesn't train the dummies, and then (c) gives the dummies tools that aren't making them any more productive (but do look pretty) then.... Ooooh, shiny!
Alternatively, management could bring in tools that will actually help staff to do their jobs, and ignore whingers who want to play instead of doing useful work. Yes, that might just do it! :-)
Whereas for me, bugs with no work around in the PDF export nearly cost a local not-for-profit group I help in my spare time a huge amount of income due to missing a key deadline. For businesses running Windows, however, it's not exactly hard to afford a couple of Acrobat licences if required.
You're right, of course, that things like graphic design and typography are skills that one has to learn. You're also right that the users in question weren't using a very good tool for what they needed to do. That's kinda my point: if we're going to have standard-issue document preparation software on every desktop in the business, it makes sense for the simple, everyday features to be the obvious things, and to hide things like detailed formatting, which only really help if done by a skilled worker, in the depths of the menu system. Right now, all the major players do things backwards.
Personally, I prefer just to edit LaTeX files with my trusty text editor and process them every now and then to see how things are looking. Your point is well taken, however: current typesetting tools are indeed much better at structuring formal documents than current word processing tools. IMHO this is mainly because current word processors are lousy at coping with the semantic significance of any given text, while if you're typesetting, you pretty much always mark up semantically by default.
Your conclusion is fundamentally flawed: it does not follow that there exist a community of programmers working on something just because a lot of people would benefit from it. For a start, that would require a significant number of programmers (a) to appreciate the need, (b) to collaborate in order to produce a solution, and (c) to be willing to do so for little or no compensation if you think they're going to write it as OSS, and (d) to be willing to do so in an apparently crowded market with a dominant commercial player, established OSS projects as competition, and a user base who have been demonstrated for the most part to prefer paying Microsoft for their offering year-on-year rather than investigate alternatives that might suit them better.
Of course there is. A gazillion people use Word in this role every day. Word isn't very good at it, but most people don't appreciate that because they have little experience of anything else in recent times.
That doesn't change the fact that at a videoconference last week, with several relatively senior members of staff from all around the world and with very limited time available, we wasted upwards of five minutes while the expensive external consultant leading the presentation tried to get his bullet lists in Word to look consistent using Format Painter (which kept turning his text into Greek). He did the same thing the week before, too. Leaving aside the opportunity cost of that time, the cost to the business just to pay all those people to sit around and watch the consultant getting his document in a mess a couple of times was probably $500. In a smart document editor, his new bullet point would have just dropped into the list and formatted itself nicely the moment he typed it, or at worst required a click or two to say "this paragraph is a new item extending the list above it".
At the same company the week before, I spent most of an hour swapping e-mails and calls with a colleague on the same team who couldn't work out why a document with an included image looked fine on her machine but didn't work when uploaded onto the network for others in the team to see; this turned out to be a linking vs. embedding problem. The cost to the business for the time for two of us to fix that and the resources we used in the process was probably $200, and again that excludes the opportunity cost for our time, the time lost as I got back to my own work after the interruption, and so on.
These little things punctuate the daily lives of countless office workers around the world, wasting $100 here or $1,000 there. Those two anecdotes come from just my personal observations of one team at work over the past couple of weeks, and probably total $700 of loss to the business. This is more than enough to send the culprits on a basic training course, or to buy a couple of licences for better software. As the saying goes, if you think training is expensive, try ignorance. Likewise, a smart craftsman with good tools will tend to get better results faster than a low-skilled worker with inadequate tools, even if the latter doesn't realise what he's missing.
OK, here's an immediate reply, right off the top of my head after reading your post. What's more, I'll only refer to the word processing component. I bet I get to ten within two minutes.
I think that's ten, and I basically haven't stopped typing for more than a few seconds between each.
As for how I'd fix them, well, I gave some description of how I'd organise a document preparation tool above. I wouldn't try to fix them with OOo Writer in its current form, because it has too much baggage: IMHO, you need a fundamental change in approach and UI priorities.
Or just that the groupthink and/or drive from Sun (who pay for the vast majority of OOo development) currently tend towards emulating Microsoft.
I look at it this way: the biggest OSS success stories, IMHO, are Linux and Firefox. They have successfully displaced a worthwhile amount of market share from an established, commercial competitor, something few other big name OSS projects can claim to have achieved so far. And they didn't do it by trying to be Windows and IE, they did it by trying to be a good OS package and a good web browser. I didn't switch to Firefox because of its similarities to IE, I switched because of the differences, from the overall design philosophy (simple main app, plug-in culture) to the subtle UI touches (unobtrusive find bar when I hit Ctrl+F).
Word, in particular, is crying out to be overtaken by a piece of software that provides WYSIWYG cuteness for the masses but makes it easier to create serious documents. Word should have no market: it should be being beaten for those who only write letters and to-do lists by simpler and cheaper tools, for those doing basic DTP by the low-end DTP packages, for those writing heavyweight long documents like books by typesetting packages or high-end DTP, and for the countless users writing diverse documents with a bit of structure and formatting by... an application that no-one's written yet, which is why we still use Word at the office.
I'm sure I'm not the only person who programs, writes lots of different kinds of document, and has had many ideas for alternative document creation tools. IME only, the main activities for a word processor user in a typical office are:
Other activities common among more knowledgable users are:
and
Power users also do things like:
I have never yet seen a business taking anything like full advantage of the automation interfaces of any word processor, nor any effective use of abominations like WordArt and not much of Equation Editor.
From my own experiences, then, I might guess that a good writing tool (in the sense of being quick and easy for users, and producing high-quality documents) would focus on letting power users set up document structure and formatting, and then presenting a vastly simpler interface to actually edit the document: almost a "fill in the blanks", with simple commands for things like checking spelling and word count. Let people apply predefined formatting and structure (based on things like what power users would call stylesheets, not randomly applying bold, all caps, double-underlined, centred, hand-typed numbering, etc.). Let them insert cross-references, again with predefined appearance. Have the software automatically reuse key text, so typing something in the "title" area on the front page automatically updates the headers as well, and changing a heading automatically updates the table of contents; this is one of the most common "unprofessionalisms" I see in documents, and it's not like it's rocket science!
Basically, put the focus on what the user is writing, with simple interfaces for the common tasks everyone needs. Then leave things like the details of formatting and document structure to the power users who can
OK, I have made my usual Slashdot typo of writing RIAA for RAII. I hereby withdraw from the argument, and will hang my head in shame for the remainder of the week...
I have only one suggestion: stop trying to be a better MS Office than MS Office (which OO never will be, for several unavoidable reasons) and start trying to provide key functionality better than MS Office does, with a different interface if necessary. Seriously, it's not that hard a target!
Actually, I think it's more akin to why Linux is very popular for some tasks among geeks and professional sysadmins, yet rarely seen on home user desktops. It's the difference between the adoption of a mass-market, good-enough tool promoted by a wave of corporate advertising, and a tool that an informed group of users choose after serious consideration.
I said no such thing. I have made no comment on what jobs D can't do at any point in this thread. I have simply argued that for the kind of work I do, D does not offer sufficiently compelling advantages for me to justify choosing it over C++.
You know, it's funny. I've been training a new starter at work recently, someone with a background in Java but little C++. After just a few hours of training, looking at how C++ is put together and why certain things work as they do, he doesn't seem to be falling into all these terrible "traps" that are commonly asked about in on-line forums and the like. So, is this guy a genius, am I the best teacher in history, or have the newbies just not bothered reading the textbooks or getting proper training before trying to use a complicated tool?
Which isn't to say C++ isn't a royal PITA at times, of course, just that it's not usually the silly little gotchas that make it so.
Of course it's not OK. I'm still waiting to find any programming language I don't consider seriously flawed in many ways. But as a practical tool, C++ has a lot of merit for the kind of work we do, and these gotchas just aren't the show-stopping horrors you make them out to be.
C++ undeniably has an image problem, though: so many of the books are populist "50 ways not to blow the whole leg off" exercises that almost no-one has actually bothered to present the language features in a positive light as an integrated whole. Hence the only people who really appreciate things like the power of the RIAA idiom are the kind of high-flyers who also read things like D&E (or at least to read more than the first half-dozen chapters of a good introductory book). But these people don't learn all the gotchas to avoid them; they understand how the language is put together, and simply don't run into the gotchas in the first place.
Why do you persist in calling C++ unpleasant names and advocating D instead? No-one's claiming C++ is perfect. Take a look at my posting history; I've certainly criticised it many times and for varying reasons! But if it were really as bad as you make out, then it wouldn't be one of the most successful programming languages ever, and if D were so much better then surely a lot more smart programmers would have switched over by now?
I don't understand the strength of your advocacy here. You seem to have labelled me as some sort of C++ evangelist, when in fact I'm just a guy using a tool. Since we did our homework into how to use that tool and how it compared with the alternatives, I'm quite willing to stand up and defend a considered choice we made, but that doesn't mean I'd recommend the same choice for others or make the same choice myself under different circumstances. You, on the other hand, seem to think it's up to me to argue that D is not superior to C++, despite the fact that you keep claiming good things about it without actually giving any concrete examples of where it's good while C++ is a "pile of crap".
Incidentally, your claim about Bright having more practical experience with C++ than Bjarne does not ring true. He may (or may not) know more about writing C++ compilers, but C++ is useful for a great deal more than writing compilers, and being good at writing compilers is far from the same as being good at designing programming languages. I find much of Bright's reasoning behind his "improvements" in D to be flawed, while Stroustrup's considered arguments for many of the "tricky bits" of C++ that you dislike so much generally stand up to scrutiny. Perhaps this is why I like C++ as a practical tool for real programming jobs, but saw few real improvements over it in the design of D.
However, this thread seems to be going nowhere. I see now why Bjarne stays well clear of language politics. I should spend more time using the tools to do useful things and less time talking about them.
I have read your posts, but you keep moving the goalposts. I stated, several posts ago, my conclusions about D: some possible improvements over C++, some steps backwards, but overall nothing spectacular that motivates me to move. I didn't say D was in some sense unacceptable, just that it offers me no sufficiently compelling advantages to consider it far superior to C++ as you seem to. Then again, I also don't seem to suffer from all these terrible problems you ascribe to C++.
You, however, wrote:
What qualifies Walter Bright and co as "actually having experience having to write code"? Do you think Bjarne Stroustrup never wrote any real code?! He wrote a whole book on how he reached his decisions about how C++ would work, and it's an enlightening study of how to make a highly successful programming language.
So, what advantages does D really offer over C++, ignoring that hopelessly misleading feature comparison chart on the Digital Mars web site? Why should I, as a professional programmer with a tool that works well for the job I'm doing, invest the time and effort to learn a new language and port about 50 man-years of code to a relatively untried language with no standard, little formal support and minor commercial backing, and few users? What compelling advantage does your/Bright's proposed alternative offer me?
I don't understand what you're getting at with OCaml, either. Again, I have nothing against the language. On the contrary, I think in many ways it's rather nice. However, I have seen nothing to suggest that its impressive performance relative to other functional programming languages comes from anything other than its imperative roots. Moreover, if the example you quoted is your idea of typical functional programming then we have very different ideas indeed about what characterises that particular programming style. Merely using functions is not the same as functional programming, even if one of them happens to be recursively defined.
That's a great relief.
I loved the BG series, in no small part thanks to the detail of the party-joining NPCs and their custom side-quests on my first couple of runs, and the flexibility in building my own power-gaming party on another occasion. I had been looking forward to NWN with great anticipation, yet never got beyond the first few hours of gameplay. An adventurer and random side-kick do not a party make. I've heard good things about the expansion packs, player-written campaigns and DM stuff, but never experienced any of them; I lost interest. If NWN2 offers some party-based game-play with the same kind of visual appeal and detailed character development that underpinned NWN1, it may yet be worth playing...
Wow, I must have really touched a nerve there somewhere! You seem to have much stronger feelings on this than I do, so let me assure you that I am in no way a "C++ man" and in every way a "right tool for the job" man. At work, I currently write C++ for the heavyweight mathematical stuff and Perl for the analysis tools. At home, I am currently maintaining a web site, which involves PHP, Perl, SQL and occasionally Javascript. I've worked with countless other languages from C and various assemblers through Java and C# to various functional languages.
Now, to address your major points quickly...
When I'm talking about safety vs. flexibility, I'm really talking about the sort of low-level fiddling common in systems programming and high-performance fields. Either you can ignore things like type systems and just twiddle bits and hack memory, or you can't. If you can, your language is flexible in this sense but unsafe. If you can't, your language may be safer, but it will not allow some flexibility. There is a fundamental dichotomy here.
As for the numerical performance issue, I have several years of professional experience in this field, and I work with a large number of other people who do likewise, both at my own office and those we work with. We've heard this argument before, done the benchmarks, looked at the assembly. Your comments about FORTRAN are simply wrong. Think about it: what magical gift does FORTRAN have that means it can generate faster mathematical code than C++, or any other low-level language for that matter? Sure, FORTRAN effectively has built-in support for common optimisations that aren't possible using naive code in other languages, but techniques to avoid the overheads were developed for C++ years ago. Moreover, as I said before, some of the more useful FORTRAN-based numerical libraries can readily be wrapped and called from C++ to avoid unnecessary porting effort anyway.
Your assembly language argument also misses the point. We ship on probably a dozen different hardware platforms today, and the assembly languages for those are constantly evolving with the release of new processors. C++ has been standardised for nearly a decade, with only minor changes in the 2003 revision. The effort to learn C++, warts and all, is tiny compared to the effort to learn and stay up to date with a dozen different assembly languages. Why would we take the time to reinvent a wheel that specialist compiler writers have already crafted to a high standard?
As for D, check my posting history for many times I've criticised it on various objective grounds. In this particular context, one might add that AFAIK there isn't even a D compiler available on several of the platforms we support.
Incidentally, I notice that you used the word "shootout" while talking about that. I do hope your assessment of the relative performance of different programming languages isn't based mainly on a single well-known web site of relatively trivial benchmarks.
As for OCaml and getting performance out of functional code, I will simply ask you to provide a single, non-trivial example where this has been shown to be the case. I note that in everything from the kiddie benchmarks on the shootout site to the high-scoring submissions in the ICFP, the fast OCaml pretty much invariably falls back on imperative techniques. The overheads incurred in dealing with functional techniques appear to be too great for current compilers to keep up with imperative code. Perhaps this will change with the development of better optimisation techniques in time, but I'm talking about today.
Because by their nature, safety and flexibility are almost invariably opposite ends of a programming language spectrum.
I spent a bit of time exploring D. And then I dropped it, in the same pile as Java, as having a few improvements over C++ and a few steps backwards, but overall nothing revolutionary that would help me enough to justify the switch. The fact that the Digital Mars web site has a grossly misleading feature comparison chart between D and other somewhat similar languages did not exactly fill me with faith, either (and no, listing a gazillion footnotes under C++ entries by way of disclaimer is not the professional programmer's answer to such a situation, it's the marketing droid's answer).
OCaml is a nice language, in many ways, but not a good tool for systems programming. To get sane performance out of it, you have to throw away much of the functional programming stuff anyway, and its syntax for more imperative styles is cumbersome.
SML is a different tool entirely, and doesn't even have those imperative tools. In exchange for the neat features, you give up any semblance of ability to do systems programming with it.
The same is true to some extent of LISP, and in any case, some of us don't consider a near-uniform syntax for everything and anything to be a positive trait in a programming language, macros or no.
Why would we use FORTRAN? We typically get better performance out of C++, we can build our stuff on platforms that don't even have FORTRAN compilers, we can write stuff other than mathematical code with some degree of elegance, and in any case where there are things like BLAS and LAPACK implemented in FORTRAN, we can get ports and link directly to them via C calling conventions anyway.
As for ASM, it's not exactly portable, now is it? In any case, with modern optimising compilers and processing architectures, it's rather rash to assume that anyone but a serious platform expert would get better performance out of assembly than the compiler does.
Thanks for the hint. I've noticed from reviews on Amazon and the like that Programming Language Processors in Java by Watt and Brown seems to cover similar ground, but get more favourable feedback (sometimes in direct comparison to Appel's book). OTOH, I'm also wary of customer reviews on web sites, since often these are written by people who have limited understanding of a subject themselves and therefore aren't really qualified to criticise a book on technical grounds. Have you by any chance seen the Watt and Brown book, and if so, what did you think?