Re:All data structures are *not* equal!
on
Design Patterns
·
· Score: 2
OK, against my better judgement I am going to post a rebuttal of some of these points.
"Structure" is also relative. True about the operations, but that behavior is rarely globally consistent.
I'm sorry, I don't understand what you're saying here. Could you explain it again in different words?
One task may need a stack view, another a tree view, etc. The "rules" for "stack" in one place may not apply to another. A different process may want to fiddle with the middle of the stack instead of just push/pop.
Then you're not using a stack any more, you're using something else.
Of course, a stack is more of an interface than a data structure per se. It's implemented using a data structure, such as an array or linked list, but that's not quite the same thing.
the results of parsing text representing regular expressions or mathematical formulae come to mind.
(warning: sarcasm ahead)
Which is a nice custom business application, no doubt. We parse math all day. It increases sales.
You better believe it, because under the hood of your treasured database front-end, that's exactly what's going on. Without this kind of technique, you would be nowhere. You choose to use a tool that writes it, and for your application domain, that's fine. Me, I might be the guy writing that tool, so you'd better hope I get the tools I need to do it properly.
I never said an RDB was good for *all* uses. Its good for when information will be used in multiple different ways by multiple people and processes and the usage requirements for the same info will likely change in the future in unanticipated ways.
That's not necessarily true, of course. The app I'm currently working on demonstrably meets all of your above criteria. It often handles several megabytes of interrelated data at once, it performs some reasonably serious algorithms on that data to get the answers our customers want, and our customers' requirements vary widely. And yet, we have managed to produce some very efficient data structures, which have stood the test of time from many customers and for more than a decade, without ever having any sort of problem adapting to new requirements.
If your approach can provide all of these: [...] then you are in the running. If not, then please leave the decathlon before you embarass your country.
You miss the point entirely. My requirements are not the same as yours. Pretty much no-one's requirements outside of your database niche are, at least not in any major niche I've ever worked in. I don't want remote backup and full transactions every time I look up whether two nodes in a graph are connected, and if so, the data associated with that connection. I just need the answer, and fast.
One line of code? Bullsh8t! You are polling my leg (pun he he).
You asked about having the same data available in different structures, to suit different needs. I explained that the typical approach to this is to store your master data in a single structure, and then refer to it indirectly from each of the others you will use for look-up. Setting up that indirection requires only a single line of extra code in each case. In practice, if you're doing this in an OO program, your data is probably stored in some sort of object that ensures the integrity of the different data structures, and provides a single method that is written once and thereafter always used to add new items of data, again using only a single line. This is absolutely routine.
Faster at a specific, narrow task perhaps, but I doubt at the simultaneous multiview decathlon.
That depends on what you mean by "narrow". As I've mentioned before, several of the applications I've worked on have had lifetimes of several years, with the basic data structures within them adapting gracefully and staying useable and maintainable throughout. That's not narrow by any useful definition. I don't need the "flexibility" of your database. I do, however, need things done today.
All data structures are *not* equal!
on
Design Patterns
·
· Score: 2
"Trees" and "hashes" are simply one of many possible views of the same information.
But they do not necessarily represent the same information. They have different structures that provide different behaviour. You require different basic operations to hold on a key or value type to use it in a binary search tree compared to a hash table, for instance. To add data to a hash table, you require a definition for a hashing function on the keys. To add data to a binary search tree, the keys must support a suitable ordering relation.
Further, trees have wider uses beyond storing key-value pairs for fast look up as well. As naturally recursive data structures, they provide a clean and easily manipulataed representation of many things: the results of parsing text representing regular expressions or mathematical formulae come to mind.
Just as importantly, different data structures have different performance characteristics. A balanced tree can provide O(log N) insertion, deletion and searching. A hash table typically provides amortized constant time operations, but in the worst case is O(N).
Consider graphs, a common structure in much mathematical work. There are two major data structures used to represent a graph: adjacency matrices and adjacency lists. Each has its uses, and offers different performance trade-offs. You simply have to understand your data, and the ways you want to access it, in order to decide which data structure(s) are most appropriate to represent it.
"Type" is relative. I want them all without having to overhaul my code to see each one. In the real world a given "node" may participate in something resembling a tree, a stack, a queue, and a hash all at the same time. Gee, how do we manage that?
It is mathematically impossible to achieve all of the optimal performance characteristics from conflicting data structures without any of the downsides. It cannot be done. You are telling me that you want to swap between all the different approaches at will, but in doing so, you ask the provably impossible. I am telling you that the approach you have with a database is a compromise, a good one perhaps, but still a suboptimal solution for most problems, and one over which you lack the fine control to make it optimal. Sometimes, that's good enough. For many applications, of the type I write, it is so far from optimal that it is not a practical solution to the problems I need to solve.
Oh, and the customary answer to your question about storing data in multiple places, by the way, is simply to store the data nodes in some central structure and then store some form of reference, pointer, or index to them in your various look-up structures. I'm sure you're thinking that sounds like a database, but to the rest of us, that's a rather grand title and it's really just data structures 101. We still do it in one line of code, and ours runs a hell of a lot faster than your generic database look-up algorithms do.
Don't worry about Tabilizer...
on
Design Patterns
·
· Score: 2
Again, if you're now claiming that your observations are from the point of view of a very narrow (by definition) niche of software development, how can you possibly extrapolate that OO and design patterns in general are just so much "snake oil," simply because you don't find that they apply to your niche so well?
This is exactly the problem with Tabilizer's arguments. I've worked him out now.;-)
His only experience is with low performance databases. He uses terms like "custom biz apps", but this is what he means. Unsurprisingly, in this particular field, tools designed specifically for the job (databases) tend to be more applicable than general purpose programming tools.
Unfortunately, due to his lack of outside experience, he fails to appreciate the vast number of other programming fields, many of which need rather better control over things. By his own admission elsewhere in this discussion, he doesn't see much use of tree structures, which tells you a lot. After a few of us started throwing back not just anecdotes but real world examples where databases just don't cut it -- your instant messaging application being another one -- he started adding this disclaimer you've seen: now he's only referring to his "niche", and not any others, all the time, and OMMV.
He also has an irritating habit of reducing anything he hasn't seen personally to anecdotal evidence. I actually worked on a large (1M+ LOC) project that was essentially an OO rewrite of an old procedural app, moving to a new platform. In spite of having a smaller team to develop it and having only two domain specialists available instead of the dozens when it was first written, we managed to exceed the functionality and reliability that the original had after around 100 man-years of development, by clearly and objectively defined criteria on which the continued funding of the project depended, and we did it in about 25 man-years.
Presumably, this was entirely down to the stunning increase in in the ability of the newer development team compared to the older. The past experience also helped us more than we were hindered by having to work out most of the low level protocols and firmware idiosyncrasies from scratch because the documentation had long since been lost. None of it had anything to do with one being written in C using purely procedural techniques, and the other being written in C++ and making use of OO, though.
Now, to me, this is as close as you're ever realistically going to get to seeing the same thing developed with and without OO to compare them. Yet, apparently, it's just another unsupported anecdote. He wants to see the code. What does he expect, for me to give him 1M+ lines of my employer's copyrighted source code? What would he do with it anyway, spend the same six months as the rest of us learning it so that he could try to pick holes in the OO model (which, clearly, worked quite well for us most of the time)?
Now me, I'm quite prepared to accept that when you're programming database apps, a database is the way to go. I just happen to find OO useful in programming instrument control apps that interface with external hardware, embedded control software, games, high performance mathematical code, system tools, and communications software, all of which I've worked on in the past.
OO is no panacea, but like many other developers out there, I find it helps to organise larger applications in my niches (plural). The reason Tabilizer gets so frustrated is that he's quite short-sighted, and while he may expect and demand that the rest of the world show him some sort of evidence of OO's superiority that meets impossible criteria, vast numbers of us have seen it for ourselves and made up our own minds from personal experience. He's not going to convince us we're wrong by telling us that all our anecdotes (which we happen to know are true ourselves) aren't good enough for him.
Some relational query languages have tree-friendly operators. It is possible. The reason it is not included more often is that the demand for it is not strong in my observation.
You don't need trees much? Presumably you also don't need hash tables, or graph structures either?
Thank you, Mr Tabilizer. You have just proved beyond all doubt my long-held belief: your views don't work for most programmers because in your world, you only need one type of data structure, a database table, while those of us in most domains need a little more than that, and the tools to manipulate them.
That would explain an awful lot about why you see so little value in many OO concepts.
The reason you separate content from presentation is precisely so that the latter can be changed independently of the former. By all means don't litter your HTML with font tags, but what's the problem with presenting a nice visual stylesheet with it? Modern CSS can even specify multiple stylesheets for different media, so you can have whizzy visual effects on screen, nicely readable black and white for printing, and potentially audio hints and such for sightless users as well. WTP?
Your use of a browser may be displaying information in an efficient way. I'll wager that 90+% of people using a browser want a visually interesting experience. The web is no longer the preserve of just the odd academic paper, and there is no reason it shouldn't be presented nicely even if it is. If you want a straightforward, no-frills presentation, that's fine, but don't tell everyone else that they're using the web wrong just because it's not your own way. They'll just ignore you, and rightly so.
I think you could reasonably argue that both LaTeX 2e and, probably, the AMS stuff for (La)TeX are standard among the community.
The TeX community is surely one of the first and best examples of collaborative development. It's free, multi-platform and there's a package available to do almost anything. Sadly, it's also an example of the single biggest drawback: sometimes (the LaTeX 3 project), it just stops when no-one has the time available any more, and everyone using it and waiting for their pet peeves to be fixed is stuffed.
And by the way, since when was putting Computer Modern and Times near each other even remotely sane? That's why you get alternative math fonts for LaTeX if you're going to be writing in Times!:-)
It seems to be hit and miss, but for some people, basic functionality like saving downloaded files seems to be messed up. My guess is that there is/was a bad build around somewhere on the beta site, and a whole chunk 'o stuff doesn't work in that build. I'm sure they'll fix it before 1.2 is released, it just means that some of us who'd like 1.2 features now can't have them yet, which is a shame if we're going to go bashing IE about security flaws.;-)
The one you mention about not saving the address is annoying as hell, I agree. Here are a couple other pet peeves of mine that I really wish they'd fix...
Contrary to the 101 list's claims, some basic XSLT support is missing from Moz at present. Try using xsl:number anywhere. There are numerous bugs in about this, and apparently it should be fixed in 1.2, but the advice they gave previously was "don't use it". They don't do much work with XML/XSLT, do they?
My #1 biggest Moz peeve in the universe: if a page is served with the wrong MIME type, Moz in standards mode insists on ignoring it. Say what you like about standards compliance, this sucks when it doesn't get CSS or XSLT stylesheets properly. I'll take an IE that renders the page sensibly over a holier-than-thou Moz that doesn't any day. If the web designer provides the right content in the file, and I as the user ask to see it, one wrong text string from a server shouldn't screw it up.
IE is effectively the standard for end-users, at present, yes. However, it very much is in the interests of those users for the developers to get standards compliance out there, simply because the current standards allow those developers to do way more than IE's hacks. If you're talking about improving the user experience, you have to talk about letting developers use the cool tools instead of writing hacks to get IE to behave itself, and only write the damn thing once, so they can spend the rest of their time improving usability and such.
Also, note that IE's 9x% market penetration is only if you count all its currently popular versions, each of which behaves very differently in some key areas. You cannot write one page in "IE HTML" and expect them all to display it correctly. That kinda defeats the whole "you should write for IE" argument without further ado.
It's "the same old argument" because it remains true and there still hasn't been a valid rebutal to the statement.
Here's your undeniable rebuttal: there are still security flaws in the current version of Mozilla.
Would you like to take a quick look at the code, and point out where to fix the remaining one of these six bugs, which is still in 1.1? I'm sure they'd be grateful to receive your patch.
Now, me, I like Moz. I use it in preference to IE most of the time, though I keep the latter around because Moz is too picky for its own good sometimes. I've even taken a look at the source code to see whether I might be able to help out, and one of these days I may submit a patch or two if no-one else has gotten there first.
However, having done that, and speaking as a guy who writes software for a living, I can promise you that most people who use Moz could not just go fix such a bug if they wanted to, even with the source code available to them. And bear in mind that the user base of Moz is likely to be considerably more technically competent than the average PC user.
Most development on big open-source projects is still done by a very small group of people, with a second layer of enthusiastic volunteers who are prepared to spend the time learning enough about the overall framework to get into it and write the patch they want. It takes a very significant amount of time invested before you can do this, which is why most people never will. Anyone who hasn't gains no benefit from the open-source nature of the product, as they are still dependent on third parties for both the code, and assurances about its security and robustness.
Unfortunately, what you say is not quite true. While most of the six bugs on BugTraq were fixed in Moz 1.0.1 or 1.1, there is still one outstanding. And bear in mind that 1.1 is actually the current version of Mozilla. There's a beta out of 1.2, but I tried it and reverted to 1.1 when lots of basic stuff broke (and from other posts on this thread, I am far from alone). So in fact, there are security bugs in the current version of Mozilla, and they are not yet patched.
Alas, often the only thing we learn from history is that we do not learn enough from history. Maybe that's why so many development shops still regard patterns as some sort of academic exercise, and continue to reinvent the wheel in a slightly less round way...
Sorry, didn't mean to suggest that MS had come up with all of this stuff from scratch, just that they were the first people to provide this functionality in a useful form on the PC. Thus they really did have a genuine and compelling technical advantage over the opposition at the time.
I agree that it's nice when high level languages support common programming idioms. I agree that a "for each" construct, and indeed list-based data structures in general, are often tidier than the equivalent "for loop" and array-based data structures. However, while Dominus has a good point here, he's downright misleading at times.
To use his own example, Perl's "universal" solution to iteration -- the foreach concept -- isn't. It's very elegant in the trivial case, when you want to process the entirety of a single list. However, suppose your data is in some non-list-like format, or you don't want to iterate forwards over everything. Then your data first needs converting into a suitable list. With the Iterator pattern, the logic to do this is encapsulated in its own class. With foreach, you have to provide a suitable conversion function. But the code to do it is still there. Using foreach simply replaces one idiom with another equivalent idiom.
Other styles of programming language each have their own answer to this. In a functional language, you would typically provide high level functions to iterate over your data structures, effectively replacing the foreach statement with a set of customised statements, each with a certain type of iteration built-in. Of course, now the logic that was in the iterator class or the list-producing function has to go in the high-level function instead.
One could certainly argue that the foreach approach (and the accompanying use of list-based data structures, to give credit where it's due) is more elegant than the use of iterators, though clearly it also has downsides (ahem, performance issues). One could definitely argue that the higher-level function approach is more powerful than either of the above. But I think it's rather unfair to imply that they somehow remove the need to provide whatever underlying logic you need for your iteration. The examples given in this presentation show a biased case, where the iterator approach offers no benefits over a simple for loop, and the foreach construct is simplicity itself, but it ain't necessarily so under other circumstances.
Re:What exactly is a "pattern"? Need good def
on
Design Patterns
·
· Score: 2
If so, then why are unproven patterns not "worthless"?
Part of your definition for patterns should include the fact that they are recurring design idioms, that have been used successfully in a variety of different places. Indeed, this is the very reason they are useful. Thus, by definition, there is no such thing as an unproven pattern.
In general, the illustrations of patterns in the book aren't actually that well-implemented; some would go so far as to say they are actually bad. Their code to implement Singleton in C++ is horrible!
To berate them for this would be to miss the point, however. As you observed yourself, the really important bit about Iterator is the fact that you have a separate counter from the container itself, which abstracts the process of iteration, and produces several useful effects as a result (which the book describes). The STL-based stuff in C++ is a good illustration of how this can be used in practice. The actual mechanism you use to implement this is really pretty irrelevant to the underlying point, and it's the underlying point that the book is all about.
Using patterns after implementation
on
Design Patterns
·
· Score: 2
This really frightens me, as the patterns are not discussed at the planning stage, but as an afterthought to implementation.
I can see where you're coming from, and I certainly agree with the "blind use" problem. On the other hand, I think design patterns are useful in two ways.
They provide inspiration and ideas when you're initially designing something.
They provide alternative possibilities as your design evolves.
While the latter is hardly an afterthought, it's definitely not the (initial) planning stage. As you implement a design, and discover which bits work and which don't in practice, that design evolves. I find design patterns quite useful as a way to guide that evolution: maybe something you planned one way didn't work, but it's naturally tending towards some standard idiom and you just didn't realise it yet.
If anything, I'd say this is actually more useful than having the patterns to hand during initial planning, when you don't really know how things are going to turn out. If you look for patterns (and not just the ones listed in the GoF book!) constantly during your adjustments, you naturally tend towards cleaner, more consistent designs.
...is the sound of a hundred/.ers picking up the GOF book and thumbing to page 18.
Oh, and he's right, by the way.:-)
I think perhaps you read him wrong
on
Design Patterns
·
· Score: 2
I wish you would have signed this so I would know to never hire you. Something that you are most likely too young and inexperienced to understand yet is that you do not write code for yourself to maintain.
I think perhaps you (and the AC who responded to the same post) have misread this post. While it was written in a flamey style, my take is that it's written by someone who has been there and done that plenty of times.
Look at the two big things that he (I assume) says.
He values working code above theoretical niceties. He would rather have something that does the job than something that's technically excellent but doesn't work.
He wants the code to be the documentation (via header files), not a mountain full of paperwork.
Personally, I think there's a lot of truth in both of those. I disagree with his take on design patterns, in that I do value and use them. Then again, I've seen plenty of people who tried to work them into a design "just because". They are truly and completely missing the point of patterns. I'd rather work with someone who didn't see the point and avoided them than someone overly clever who tried to use them without a good reason.
Further, many (most?) managers are among the worst people in this respect. If you don't produce your 1,000 pages of buzzword-laden documentation this year, you're obviously not working hard enough. (These are the same people who judge productivity by how many lines of code you write per day.) It's a sadly overlooked truth that your code really should need little paper documentation if it's done properly, and the best low-level documentation -- indeed probably the only worthwhile low-level documentation -- is the code itself. Just follow some simple basic steps:
use sensible names for code and data
use comments in the source where they actually help (make your header files document the interface, outline a complex algorithm in pseudocode, etc.)
keep a clear design, with the responsibilities of functions/classes/whatever well defined and unambiguous.
At this point, your paper documentation should be limited to something like:
requirements documents (to discuss with clients in their own language)
high-level design documentation and overviews of features (to keep the big picture clear)
some testing docs (though even this sort of thing is often best automated).
Everything else really is just waste paper, yet how many projects have you seen where they print out what every single function does and file it away, even though 99% of it will be redundant next week since we changed everything? I have watched projects collapse under the weight of unhelpful or downright obstructive paperwork and procedures, and seen the light.:-)
So seriously, while this guy comes across as flamebait, just stop and ask yourself whether he's really a pimply 15-year-old L337 Hax0r, or whether he's a 20-year veteran who's seen it all before and knows that at the end of the day, working code and lightweight procedures are worth far more than any management buzzwords and formal process certifications you care to mention.
Of course, he could still be a 15-year-old s'kiddie, too. If he is, though, I think he writes with more than a slight ring of truth.
Re:Since the author didnt mention it...
on
Design Patterns
·
· Score: 2
I was once asked in an interview to rough out an OO design for the project they would be hiring me for. I quickly came up with a design which was good and based on patterns in my head based on my experience. Then the interviewer asked me what patterns I could see in my design and because I hadn't read the book yet I didn't have the proper lingo to feed back to him even though my patterns matched the books patterns very closely.
If you didn't get the job on that basis, at least you know you didn't want to work there. After all, the smart-ass doing the interview completely missed the point of patterns.:-)
I do crossplatform day in day out, its NOT THAT HARD
I seriously question whether your claim is true.
I work on a serious cross-platform app at present. We build on something like 15 different platforms, from the latest Metrowerks CodeWarrior on the Mac and VS.NET on Windoze to antiquated HP-UX things and God knows how many Solaris builds.
Today, I wrote a singly linked list class. I wanted it to be generic, so I defined it all using macros. Am I insane? Not at all. Several of our compilers don't support even basic templates properly, and if you look up STL in the help, you'll find no match. You can't get more modern compilers on some of these platforms, and even if we could, we're supplying to other development companies and are constrained to make our code work on whatever compilers they develop with.
I could have written everything much more cleanly using templates, in much less time, or even faster still just used std::list, but then it wouldn't have built on something like half of our compilers. These things get confused when you combine overloading and overriding sometimes (what's the using keyword, anyway?) so more advanced techniques are right out of the Window.
Boost is a fabulous thing. I sincerely hope that several parts of it make the next C++ standard, and fix up some of the glaring gaps in the current one. But while it's intended to be written in standard C++, and as time goes by it will become more widely useful, you could never call the sort of code they use "portable" in an industrial engineering sense at present. Portable amongst recent compilers on popular platforms, yes, but outside that scope, it's an academic toy that is of no practical use.
While MS' success certainly took off when they started packaging things as "Microsoft Office", I think we should also give credit where it's due. Until that point, if I wanted to produce a document with more than just words in it, I needed to spend hundreds of pounds on specialist DTP software that really did almost nothing except import data from other formats and stuff it together on a page. With the advent of the combined office suite, and technologies such as DDE in Windows, it became pretty straightforward to produce a Word document (or, later, a Powerpoint presentation) incorporating tables or charts from the spreadsheet. I could finally have some decent formatting for my database reports, too, if I exported them via Word.
Couple this with the relatively uniform support for screen display and printing provided realistically for the first time on a PC by Windows, and the advent of fonts worth using for those of us without the money to buy Adobe Type Manager with Windows 3.1, and these things genuinely did allow Joe User to produce a much nicer document than he ever could using the old DOS kit. (Not that many people did, but the power was there for those who learned to use it.)
I can't understand why any of this is remotely abusive of any sort of power MS may then have had. It simply was better than the opposition, and for its time, much of this stuff was revolutionary. We take it for granted today, and cite a half dozen big examples where MS bought someone out and sold the product as their own, but people around here are pretty quick to forget the genuine innovations they have produced in the past, IMHO.
But why is Excel the best? Is it because they just made a better product and everybody else gave up because they couldn't innovate?
Actually, yes, it is. Around the time of Windows 3.x, there was a fairly fundamental shift in the patterns of PC use towards a Windows platform. At that point, Excel smoked everything else on the market. Lotus 1-2-3 for Windows was a sad shadow of the once dominant spreadsheet, while Excel got the job done for a lot of people.
Or is it because Microsoft crushed the opposition by exploiting their monopoly? I think you'll find that Microsoft ensured that the "best product" never got made, because they knew it wouldn't be theirs.
Erm... Microsoft didn't have a monopoly on anything much back then, though Windows was starting to become dominant. Word was up against WordPerfect and WordStar, and new kid on the block Ami Pro, which was arguably a better word processor at that time. Excel was up against a port of 1-2-3 to Windows, with a near 100% market share to break into. Even Windows itself wasn't a sure thing; OS/2 was a serious candidate, GEM was around albeit never really going anywhere, and of course Macs and such were there if you were doing serious design/publishing.
So, given that Microsoft had pretty much zilch leverage and no monopoly, how exactly were they going to ensure that their product won, other than by being better than the competition? I realise that you probably weren't born yet when all this happened, but do please try to write something vaguely correct if you're going to flame.
Slashdot Mirror
OK, against my better judgement I am going to post a rebuttal of some of these points.
I'm sorry, I don't understand what you're saying here. Could you explain it again in different words?
Then you're not using a stack any more, you're using something else.
Of course, a stack is more of an interface than a data structure per se. It's implemented using a data structure, such as an array or linked list, but that's not quite the same thing.
You better believe it, because under the hood of your treasured database front-end, that's exactly what's going on. Without this kind of technique, you would be nowhere. You choose to use a tool that writes it, and for your application domain, that's fine. Me, I might be the guy writing that tool, so you'd better hope I get the tools I need to do it properly.
That's not necessarily true, of course. The app I'm currently working on demonstrably meets all of your above criteria. It often handles several megabytes of interrelated data at once, it performs some reasonably serious algorithms on that data to get the answers our customers want, and our customers' requirements vary widely. And yet, we have managed to produce some very efficient data structures, which have stood the test of time from many customers and for more than a decade, without ever having any sort of problem adapting to new requirements.
You miss the point entirely. My requirements are not the same as yours. Pretty much no-one's requirements outside of your database niche are, at least not in any major niche I've ever worked in. I don't want remote backup and full transactions every time I look up whether two nodes in a graph are connected, and if so, the data associated with that connection. I just need the answer, and fast.
You asked about having the same data available in different structures, to suit different needs. I explained that the typical approach to this is to store your master data in a single structure, and then refer to it indirectly from each of the others you will use for look-up. Setting up that indirection requires only a single line of extra code in each case. In practice, if you're doing this in an OO program, your data is probably stored in some sort of object that ensures the integrity of the different data structures, and provides a single method that is written once and thereafter always used to add new items of data, again using only a single line. This is absolutely routine.
That depends on what you mean by "narrow". As I've mentioned before, several of the applications I've worked on have had lifetimes of several years, with the basic data structures within them adapting gracefully and staying useable and maintainable throughout. That's not narrow by any useful definition. I don't need the "flexibility" of your database. I do, however, need things done today.
But they do not necessarily represent the same information. They have different structures that provide different behaviour. You require different basic operations to hold on a key or value type to use it in a binary search tree compared to a hash table, for instance. To add data to a hash table, you require a definition for a hashing function on the keys. To add data to a binary search tree, the keys must support a suitable ordering relation.
Further, trees have wider uses beyond storing key-value pairs for fast look up as well. As naturally recursive data structures, they provide a clean and easily manipulataed representation of many things: the results of parsing text representing regular expressions or mathematical formulae come to mind.
Just as importantly, different data structures have different performance characteristics. A balanced tree can provide O(log N) insertion, deletion and searching. A hash table typically provides amortized constant time operations, but in the worst case is O(N).
Consider graphs, a common structure in much mathematical work. There are two major data structures used to represent a graph: adjacency matrices and adjacency lists. Each has its uses, and offers different performance trade-offs. You simply have to understand your data, and the ways you want to access it, in order to decide which data structure(s) are most appropriate to represent it.
It is mathematically impossible to achieve all of the optimal performance characteristics from conflicting data structures without any of the downsides. It cannot be done. You are telling me that you want to swap between all the different approaches at will, but in doing so, you ask the provably impossible. I am telling you that the approach you have with a database is a compromise, a good one perhaps, but still a suboptimal solution for most problems, and one over which you lack the fine control to make it optimal. Sometimes, that's good enough. For many applications, of the type I write, it is so far from optimal that it is not a practical solution to the problems I need to solve.
Oh, and the customary answer to your question about storing data in multiple places, by the way, is simply to store the data nodes in some central structure and then store some form of reference, pointer, or index to them in your various look-up structures. I'm sure you're thinking that sounds like a database, but to the rest of us, that's a rather grand title and it's really just data structures 101. We still do it in one line of code, and ours runs a hell of a lot faster than your generic database look-up algorithms do.
This is exactly the problem with Tabilizer's arguments. I've worked him out now. ;-)
His only experience is with low performance databases. He uses terms like "custom biz apps", but this is what he means. Unsurprisingly, in this particular field, tools designed specifically for the job (databases) tend to be more applicable than general purpose programming tools.
Unfortunately, due to his lack of outside experience, he fails to appreciate the vast number of other programming fields, many of which need rather better control over things. By his own admission elsewhere in this discussion, he doesn't see much use of tree structures, which tells you a lot. After a few of us started throwing back not just anecdotes but real world examples where databases just don't cut it -- your instant messaging application being another one -- he started adding this disclaimer you've seen: now he's only referring to his "niche", and not any others, all the time, and OMMV.
He also has an irritating habit of reducing anything he hasn't seen personally to anecdotal evidence. I actually worked on a large (1M+ LOC) project that was essentially an OO rewrite of an old procedural app, moving to a new platform. In spite of having a smaller team to develop it and having only two domain specialists available instead of the dozens when it was first written, we managed to exceed the functionality and reliability that the original had after around 100 man-years of development, by clearly and objectively defined criteria on which the continued funding of the project depended, and we did it in about 25 man-years.
Presumably, this was entirely down to the stunning increase in in the ability of the newer development team compared to the older. The past experience also helped us more than we were hindered by having to work out most of the low level protocols and firmware idiosyncrasies from scratch because the documentation had long since been lost. None of it had anything to do with one being written in C using purely procedural techniques, and the other being written in C++ and making use of OO, though.
Now, to me, this is as close as you're ever realistically going to get to seeing the same thing developed with and without OO to compare them. Yet, apparently, it's just another unsupported anecdote. He wants to see the code. What does he expect, for me to give him 1M+ lines of my employer's copyrighted source code? What would he do with it anyway, spend the same six months as the rest of us learning it so that he could try to pick holes in the OO model (which, clearly, worked quite well for us most of the time)?
Now me, I'm quite prepared to accept that when you're programming database apps, a database is the way to go. I just happen to find OO useful in programming instrument control apps that interface with external hardware, embedded control software, games, high performance mathematical code, system tools, and communications software, all of which I've worked on in the past.
OO is no panacea, but like many other developers out there, I find it helps to organise larger applications in my niches (plural). The reason Tabilizer gets so frustrated is that he's quite short-sighted, and while he may expect and demand that the rest of the world show him some sort of evidence of OO's superiority that meets impossible criteria, vast numbers of us have seen it for ourselves and made up our own minds from personal experience. He's not going to convince us we're wrong by telling us that all our anecdotes (which we happen to know are true ourselves) aren't good enough for him.
You don't need trees much? Presumably you also don't need hash tables, or graph structures either?
Thank you, Mr Tabilizer. You have just proved beyond all doubt my long-held belief: your views don't work for most programmers because in your world, you only need one type of data structure, a database table, while those of us in most domains need a little more than that, and the tools to manipulate them.
That would explain an awful lot about why you see so little value in many OO concepts.
The reason you separate content from presentation is precisely so that the latter can be changed independently of the former. By all means don't litter your HTML with font tags, but what's the problem with presenting a nice visual stylesheet with it? Modern CSS can even specify multiple stylesheets for different media, so you can have whizzy visual effects on screen, nicely readable black and white for printing, and potentially audio hints and such for sightless users as well. WTP?
Your use of a browser may be displaying information in an efficient way. I'll wager that 90+% of people using a browser want a visually interesting experience. The web is no longer the preserve of just the odd academic paper, and there is no reason it shouldn't be presented nicely even if it is. If you want a straightforward, no-frills presentation, that's fine, but don't tell everyone else that they're using the web wrong just because it's not your own way. They'll just ignore you, and rightly so.
I think you could reasonably argue that both LaTeX 2e and, probably, the AMS stuff for (La)TeX are standard among the community.
The TeX community is surely one of the first and best examples of collaborative development. It's free, multi-platform and there's a package available to do almost anything. Sadly, it's also an example of the single biggest drawback: sometimes (the LaTeX 3 project), it just stops when no-one has the time available any more, and everyone using it and waiting for their pet peeves to be fixed is stuffed.
And by the way, since when was putting Computer Modern and Times near each other even remotely sane? That's why you get alternative math fonts for LaTeX if you're going to be writing in Times! :-)
...to good ol' WordPerfect, eh? For its time, its ability to display equations was miles ahead of any other word processor!
It seems to be hit and miss, but for some people, basic functionality like saving downloaded files seems to be messed up. My guess is that there is/was a bad build around somewhere on the beta site, and a whole chunk 'o stuff doesn't work in that build. I'm sure they'll fix it before 1.2 is released, it just means that some of us who'd like 1.2 features now can't have them yet, which is a shame if we're going to go bashing IE about security flaws. ;-)
The one you mention about not saving the address is annoying as hell, I agree. Here are a couple other pet peeves of mine that I really wish they'd fix...
IE is effectively the standard for end-users, at present, yes. However, it very much is in the interests of those users for the developers to get standards compliance out there, simply because the current standards allow those developers to do way more than IE's hacks. If you're talking about improving the user experience, you have to talk about letting developers use the cool tools instead of writing hacks to get IE to behave itself, and only write the damn thing once, so they can spend the rest of their time improving usability and such.
Also, note that IE's 9x% market penetration is only if you count all its currently popular versions, each of which behaves very differently in some key areas. You cannot write one page in "IE HTML" and expect them all to display it correctly. That kinda defeats the whole "you should write for IE" argument without further ado.
Here's your undeniable rebuttal: there are still security flaws in the current version of Mozilla.
Would you like to take a quick look at the code, and point out where to fix the remaining one of these six bugs, which is still in 1.1? I'm sure they'd be grateful to receive your patch.
Now, me, I like Moz. I use it in preference to IE most of the time, though I keep the latter around because Moz is too picky for its own good sometimes. I've even taken a look at the source code to see whether I might be able to help out, and one of these days I may submit a patch or two if no-one else has gotten there first.
However, having done that, and speaking as a guy who writes software for a living, I can promise you that most people who use Moz could not just go fix such a bug if they wanted to, even with the source code available to them. And bear in mind that the user base of Moz is likely to be considerably more technically competent than the average PC user.
Most development on big open-source projects is still done by a very small group of people, with a second layer of enthusiastic volunteers who are prepared to spend the time learning enough about the overall framework to get into it and write the patch they want. It takes a very significant amount of time invested before you can do this, which is why most people never will. Anyone who hasn't gains no benefit from the open-source nature of the product, as they are still dependent on third parties for both the code, and assurances about its security and robustness.
Unfortunately, what you say is not quite true. While most of the six bugs on BugTraq were fixed in Moz 1.0.1 or 1.1, there is still one outstanding. And bear in mind that 1.1 is actually the current version of Mozilla. There's a beta out of 1.2, but I tried it and reverted to 1.1 when lots of basic stuff broke (and from other posts on this thread, I am far from alone). So in fact, there are security bugs in the current version of Mozilla, and they are not yet patched.
Alas, often the only thing we learn from history is that we do not learn enough from history. Maybe that's why so many development shops still regard patterns as some sort of academic exercise, and continue to reinvent the wheel in a slightly less round way...
Sorry, didn't mean to suggest that MS had come up with all of this stuff from scratch, just that they were the first people to provide this functionality in a useful form on the PC. Thus they really did have a genuine and compelling technical advantage over the opposition at the time.
I agree that it's nice when high level languages support common programming idioms. I agree that a "for each" construct, and indeed list-based data structures in general, are often tidier than the equivalent "for loop" and array-based data structures. However, while Dominus has a good point here, he's downright misleading at times.
To use his own example, Perl's "universal" solution to iteration -- the foreach concept -- isn't. It's very elegant in the trivial case, when you want to process the entirety of a single list. However, suppose your data is in some non-list-like format, or you don't want to iterate forwards over everything. Then your data first needs converting into a suitable list. With the Iterator pattern, the logic to do this is encapsulated in its own class. With foreach, you have to provide a suitable conversion function. But the code to do it is still there. Using foreach simply replaces one idiom with another equivalent idiom.
Other styles of programming language each have their own answer to this. In a functional language, you would typically provide high level functions to iterate over your data structures, effectively replacing the foreach statement with a set of customised statements, each with a certain type of iteration built-in. Of course, now the logic that was in the iterator class or the list-producing function has to go in the high-level function instead.
One could certainly argue that the foreach approach (and the accompanying use of list-based data structures, to give credit where it's due) is more elegant than the use of iterators, though clearly it also has downsides (ahem, performance issues). One could definitely argue that the higher-level function approach is more powerful than either of the above. But I think it's rather unfair to imply that they somehow remove the need to provide whatever underlying logic you need for your iteration. The examples given in this presentation show a biased case, where the iterator approach offers no benefits over a simple for loop, and the foreach construct is simplicity itself, but it ain't necessarily so under other circumstances.
Part of your definition for patterns should include the fact that they are recurring design idioms, that have been used successfully in a variety of different places. Indeed, this is the very reason they are useful. Thus, by definition, there is no such thing as an unproven pattern.
In general, the illustrations of patterns in the book aren't actually that well-implemented; some would go so far as to say they are actually bad. Their code to implement Singleton in C++ is horrible!
To berate them for this would be to miss the point, however. As you observed yourself, the really important bit about Iterator is the fact that you have a separate counter from the container itself, which abstracts the process of iteration, and produces several useful effects as a result (which the book describes). The STL-based stuff in C++ is a good illustration of how this can be used in practice. The actual mechanism you use to implement this is really pretty irrelevant to the underlying point, and it's the underlying point that the book is all about.
I can see where you're coming from, and I certainly agree with the "blind use" problem. On the other hand, I think design patterns are useful in two ways.
While the latter is hardly an afterthought, it's definitely not the (initial) planning stage. As you implement a design, and discover which bits work and which don't in practice, that design evolves. I find design patterns quite useful as a way to guide that evolution: maybe something you planned one way didn't work, but it's naturally tending towards some standard idiom and you just didn't realise it yet.
If anything, I'd say this is actually more useful than having the patterns to hand during initial planning, when you don't really know how things are going to turn out. If you look for patterns (and not just the ones listed in the GoF book!) constantly during your adjustments, you naturally tend towards cleaner, more consistent designs.
...is the sound of a hundred /.ers picking up the GOF book and thumbing to page 18.
Oh, and he's right, by the way. :-)
I think perhaps you (and the AC who responded to the same post) have misread this post. While it was written in a flamey style, my take is that it's written by someone who has been there and done that plenty of times.
Look at the two big things that he (I assume) says.
Personally, I think there's a lot of truth in both of those. I disagree with his take on design patterns, in that I do value and use them. Then again, I've seen plenty of people who tried to work them into a design "just because". They are truly and completely missing the point of patterns. I'd rather work with someone who didn't see the point and avoided them than someone overly clever who tried to use them without a good reason.
Further, many (most?) managers are among the worst people in this respect. If you don't produce your 1,000 pages of buzzword-laden documentation this year, you're obviously not working hard enough. (These are the same people who judge productivity by how many lines of code you write per day.) It's a sadly overlooked truth that your code really should need little paper documentation if it's done properly, and the best low-level documentation -- indeed probably the only worthwhile low-level documentation -- is the code itself. Just follow some simple basic steps:
At this point, your paper documentation should be limited to something like:
Everything else really is just waste paper, yet how many projects have you seen where they print out what every single function does and file it away, even though 99% of it will be redundant next week since we changed everything? I have watched projects collapse under the weight of unhelpful or downright obstructive paperwork and procedures, and seen the light. :-)
So seriously, while this guy comes across as flamebait, just stop and ask yourself whether he's really a pimply 15-year-old L337 Hax0r, or whether he's a 20-year veteran who's seen it all before and knows that at the end of the day, working code and lightweight procedures are worth far more than any management buzzwords and formal process certifications you care to mention.
Of course, he could still be a 15-year-old s'kiddie, too. If he is, though, I think he writes with more than a slight ring of truth.
If you didn't get the job on that basis, at least you know you didn't want to work there. After all, the smart-ass doing the interview completely missed the point of patterns. :-)
I seriously question whether your claim is true.
I work on a serious cross-platform app at present. We build on something like 15 different platforms, from the latest Metrowerks CodeWarrior on the Mac and VS.NET on Windoze to antiquated HP-UX things and God knows how many Solaris builds.
Today, I wrote a singly linked list class. I wanted it to be generic, so I defined it all using macros. Am I insane? Not at all. Several of our compilers don't support even basic templates properly, and if you look up STL in the help, you'll find no match. You can't get more modern compilers on some of these platforms, and even if we could, we're supplying to other development companies and are constrained to make our code work on whatever compilers they develop with.
I could have written everything much more cleanly using templates, in much less time, or even faster still just used std::list, but then it wouldn't have built on something like half of our compilers. These things get confused when you combine overloading and overriding sometimes (what's the using keyword, anyway?) so more advanced techniques are right out of the Window.
Boost is a fabulous thing. I sincerely hope that several parts of it make the next C++ standard, and fix up some of the glaring gaps in the current one. But while it's intended to be written in standard C++, and as time goes by it will become more widely useful, you could never call the sort of code they use "portable" in an industrial engineering sense at present. Portable amongst recent compilers on popular platforms, yes, but outside that scope, it's an academic toy that is of no practical use.
While MS' success certainly took off when they started packaging things as "Microsoft Office", I think we should also give credit where it's due. Until that point, if I wanted to produce a document with more than just words in it, I needed to spend hundreds of pounds on specialist DTP software that really did almost nothing except import data from other formats and stuff it together on a page. With the advent of the combined office suite, and technologies such as DDE in Windows, it became pretty straightforward to produce a Word document (or, later, a Powerpoint presentation) incorporating tables or charts from the spreadsheet. I could finally have some decent formatting for my database reports, too, if I exported them via Word.
Couple this with the relatively uniform support for screen display and printing provided realistically for the first time on a PC by Windows, and the advent of fonts worth using for those of us without the money to buy Adobe Type Manager with Windows 3.1, and these things genuinely did allow Joe User to produce a much nicer document than he ever could using the old DOS kit. (Not that many people did, but the power was there for those who learned to use it.)
I can't understand why any of this is remotely abusive of any sort of power MS may then have had. It simply was better than the opposition, and for its time, much of this stuff was revolutionary. We take it for granted today, and cite a half dozen big examples where MS bought someone out and sold the product as their own, but people around here are pretty quick to forget the genuine innovations they have produced in the past, IMHO.
Actually, yes, it is. Around the time of Windows 3.x, there was a fairly fundamental shift in the patterns of PC use towards a Windows platform. At that point, Excel smoked everything else on the market. Lotus 1-2-3 for Windows was a sad shadow of the once dominant spreadsheet, while Excel got the job done for a lot of people.
Erm... Microsoft didn't have a monopoly on anything much back then, though Windows was starting to become dominant. Word was up against WordPerfect and WordStar, and new kid on the block Ami Pro, which was arguably a better word processor at that time. Excel was up against a port of 1-2-3 to Windows, with a near 100% market share to break into. Even Windows itself wasn't a sure thing; OS/2 was a serious candidate, GEM was around albeit never really going anywhere, and of course Macs and such were there if you were doing serious design/publishing.
So, given that Microsoft had pretty much zilch leverage and no monopoly, how exactly were they going to ensure that their product won, other than by being better than the competition? I realise that you probably weren't born yet when all this happened, but do please try to write something vaguely correct if you're going to flame.