The nice thing about C is that you can get a portable library to do all that for you. So it's just a matter of finding the library to do what you need, and then including it with your package. Hey presto, code reuse. Basically, if there's a problem you want to solve, there's probably a library with a C binding that you can find with a little Googling.
That's all well and good, but why not have a standard library have it? I'm not saying that it all has to go into one monstrous libc.so. Make it libcutil.so or some other separate library so that people won't whine about bloat. The point I'm trying to make is that linked lists, sets, priority queues, etc. are all solved problems. To a large extent, so is a window, a button, a sound clip, and a database connection.
It reminds me of the PHP database API madness. mysql_select(...)!?! PHP was created after Perl and Java and yet they couldn't figure out that database abstraction and DBI/JDBC were good ideas?
You want choice? Great! I agree with you. Competition is good. But give me a common header file so that to swap implementations, all I need to do is recompile or relink. We don't need twenty billion APIs for "play audio clip" do we?
First off, it helps your argument to state that the C++ spec was standardized in 1998, not 1999. C was (again) standardized in 1999.
Standardization always preceeds implementation. So how long is too long? One year? Two? Six months? It took the STLPort folks 2-3 years for a working implementation after the official spec was published. That doesn't sound too bad to me for a bunch of volunteers.
Well unless you use.data() instead of.cstr() where NT/Solaris use the same implementation for both and libstdc++ doesn't
From the Cygwin mailing list: "data doesn't necessarily return a zero-terminated string, it simply returns a ptr to the raw data. It is only zero-terminated if you call c_str() which is, of course, why there are two functions in the first place."
Do you want a NULL-terminated string? Use.c_str(). Do you want access to the raw buffer from the implementation? Use.data(). Because the implementation may be different, the output of.data() may be different. Imagine that: access to the backend buffer implementation may be different for different implementations. If you want to work with strings, don't call either one; Use the std::string directly. If you need a C-style string, use.c_str() and be done with it. The output of.data() is not portable and was never advertised to be. If however you absolutely need the speed afforded by direct buffer access, the underlying implementation matters. But like speed optimizations in assembly, it should only be done when absolutely necessary.
...or you want to use <strstream.h> er I mean <strstream>... errr I mean <stringstream>
#include <sstream>
Use of the other two is deprecated per the 1998 standard. You couldn't read that part of the spec in the six years that it's been published?
...and the first time you could get something that comes close to a std. c++ implementation is within the last few months.
Bah. GCC 3.x has had a ISO-98 standard C++ library for the last two years. STLPort has been around for even longer.
Umm, the fact that the C libraries don't change is a good thing. See, in the C world, we like to strive for something called "portability".
You'd better laugh when you say that. Open up just about any C program over 1000 lines long. Do you see #ifdefs? Are they for avoiding cross-target compilation issues? So much for portability.
If the standard library keeps adding new features, it kinda makes it hard to compile new programs on old platforms. The fact that the C standard hardly changes is intentional.
Yeah, I know it's intentional. That's the point of my argument. The same is true in Java as well. A program will state "requires Java 1.2 or above" or "requires the use of custom ImageI/O SPIs for formats beyond JPEG and GIF." As long as you state the version, you're covered. People write to a newer API than what you have running on your server? Congrats! You are in the same boat we are now with Qt libraries, Gnome libraries, OpenGL drivers, and ODBC interfaces. API version conflicts have nothing to do with this discussion.
Take a Java program at least 1,000 lines long. Does it run on the equivalent version of the JVM on Linux, Mac OSX, Windows, etc.? Does it run in the IBM build as well as the Sun JVM? Yes. Why? Standardized API. Period.
Basically, C could be fine with no standard library at all. In fact, one of the targets for C included embedded platforms where implementing even C's full standard library is overkill.
No, the STL *is* standardized. ISO C++98. There's a difference between a lack of a standard and incomplete implementations.
If I use std::string or std::vector in my code, it compiles and it works no matter the implementation. You are confusing warts with fundamental deficiencies.
MFC and OWL? Yes, they are a problem. I sure wish C++ would come up with a standard GUI API and let others plug in their own implementation. <sarcasm>Oh wait! That was the point of my original rant, wasn't it?</sarcasm>
Shoot, I should have added that to my list (no pun intended) of C deficiencies.
It's been over thirty years. Linked lists, binary trees, red-black trees, hashtables, sets, priority queues, et al. have not changed all that much. It would be nice to not make everyone reinvent the data structure wheel.
People might complain that the standard JRE installation is getting relatively HUGE, but that is a good thing.
A lot of folks make this claim and yet conveniently forget that Qt/GTK+, ALSA/OSS, ODBC, et al. take up space too. In fact, considering the fact that Qt and GTK+, ALSA and OSS, etc. must all be installed because programs are being written specifically for them instead of a common API and pluggable implementation, it's actually less space to install a JRE.
This is not to say that I think Java couldn't be more modular. I'd welcome some separation like a network module and a sound module (or all in one go like it is now). But, warts and all, Java is at least moving in the right direction. C, on the other hand, isn't moving at all.
Nothing is static. That was my complaint about the standard C library. It is static... stagnant... showing its age.
This does not diminish the fact that AWT was the first Java GUI API. It had limitations. It was redesigned to be truly cross-platform and dubbed Swing. As far as the API is concerned, I happen to like the Swing library. Is it "THE ONE TRUE GUI API?" Of course not. Nothing is or ever will be. It was the best they could come up with at the time. Now, when someone learns the standard Java GUI API (or just about any other Java API for that matter), they can transfer those skills to other Java projects much more easily than C coders can in C projects.
SWT? A nice start. It is not as complete, does not run on as many platforms, nor is as widely used as Swing. But it shows promise. In five more years, who knows? That's the point. Right now, there is a standard API that everyone knows and other APIs (that aren't drastically different from the AWT/Swing API by the way) being tried out to find better ways of doing things.
Mono's choice of GTK# is in my opinion a bad move. It's also unfortunate that Microsoft hasn't opened up the APIs for the Windows GUI libraries. I understand their reasons for doing it (Microsoft patent threats), but the culture of C is too strong. Instead of writing a new, GUI toolkit agnostic interface API, they intimately tied it GTK.
C and the programming culture it fosters is building on sand; New APIs are constantly (and in my opinion, unnecessarily) being written all of the time, but there's no common base for others to work on nor to use as a base API design reference. Imagine how much more software would be written if folks didn't have to battle over GTK/Qt, MySQL/PostgreSQL/ODBC client libraries, ALSA/OSS, etc.? Would it be so terrible to tell people, "OpenGL is the standard API interface for 2D graphics in C. How you implement the OpenGL layer is up to you, but use the standard header files so that people can just recompile/relink to use a different implementation.
Don't think it's necessary? Let's look at the history of UNIX, the original C program. The API wasn't standardized and set in stone. Different vendors went their own way in an attempt to lock the others out of their turf. UNIX programs commonly became a mess of #ifdef statements. The Windows came in touting a common API for Windows with COM. Any language (well, the common ones... VB, C, C++, etc.) could use these objects. They had a well-defined API. New implementations (eg. Perl for Windows) could be modified to access these objects as well. It didn't matter what language the COM object was written in. It didn't matter what language you were using. Write to the interface and be done with it. COM had warts. Everything does..NET fixes many of those warts.
The C community on the other hand just sticks its head in the sand and collectively says, "Look! They didn't do it perfectly. They suck! We rule!"
The C community should be saying, "Look! None of us did it perfectly. Let's make our baby better by taking some of their good ideas and incorporating a bunch of our own."
Mono and Java have warts, but at least they're trying. What's C got show for thirty years? Variable length arrays in function declarations? That is the best thing anyone could come up with for C99? Hey folks! There's an elephant in the corner! It's name is "incomplete standard library." I know no one wants to talk about it, but it's there and taking up too much space at the party!
The real question is this: would you rather program against the pitiful number API's that come with C#, or the huge Free Software diversity that you get with C?
Or read a different way, would you rather program to a uniform API for GUIs that are accessible to many languages including C# or the huge Free Software diversity of GUI APIs that are all incompatible but still just make a button and a checkbox.
Or we can look at it like this: "Wouldn't it be better to have many different toolkits that allow string concatenation and tokenization than one standard library of string functions?"
Or maybe this: "Isn't it great that we have several different native APIs for threads, processes, and IPC depending on underlying platform, five different and incompatible implementations for cross-platform usage, and no way to easily switch between implementations after the project is underway?"
And next shall we talk about databases? Or maybe sound processing? Or regular expressions? Hmmm...
The thing that C zealots fail to recognize is the need for clean, standardized APIs (NOT implementations). If you write code that uses strncmp(...), aren't you glad that you don't have to worry if the C implementation is the BSD libc or glibc or MS Windows' C library? Don't you wish the same could be said for the user interface libraries -- for example being able to swap out the Qt or GTK+ implementations at compile or link time? Or the database libraries? (ODBC? Don't make me laugh.) But you can't because each implementation has its own interface even though a button is a button, a checkbox is a checkbox, a database connect is a database connect, a regexp is a regexp, etc.
This is what.NET gives; Not the mandated implementation, but much better it gives the recommended interface. If the C folks get it together and standardize more than just things like printf(...) and linked lists, you will get no end of gratitude from me and the gratitude of folks who are tired of reinventing the wheel and solving problems that were adequately solved twenty years ago. Unless that happens, you're gonna see more and more people moving to things like.NET and Java, warts and all.
POSIX was a good start, but it has stagnated and is showing its age.
If you choose to make your own XML document schema, you lose out on the preprepared stylesheets and converters. On the other hand, a schema made for the task at hand is usually easier to use and understand.
As a compromise, you might to check out the progress on XHTML 2.0. It has a syntax not too far removed from the HTML we've all seen before, but 2.0 is closer to the DocBook model of semantics rather than presentation. It is also more likely to be supported by 3rd party clients in the future. (There is already an XHTML 2.0 renderer available for Mozilla.)
Whatever you do, make sure the markup relates to meaning and NOT how it looks. Looks change, but if you don't take care to the meaning/semantics from the beginning, it is prohibitively difficult to put in in later. For example, it's easy to make all annotations and citations red. It's not so cut and dried to change all red text to annotations (when citations or emphasized text may be formatted in red).
Maggots clean wounds. When you work on a shoestring budget, you tend to go for homespun remedies. Antibiotics are expensive -- especially in the volume necessary for the number of people she helped. It may offend your delicate sensibilities, but it works, and the money saved can be used for expensive treatments that maggots can't solve.
Twisted and manipulative? She twisted and manipulated her way into helping more people than most. Sucking up to dictators? If they gave her money, good. Shouldn't the relevant question be "why didn't supposedly civilized democracies give her all the support she needed?" She played politics. Big whup.
You want duplicitous? How about the Beastie Boys? They organized huge events in the name of "Free Tibet." Know where the proceeds went? Not to Tibetan resistance groups. Not a check to the Dalai Lama. Not money to Amnesty International. Not to relief organizations.
To the musicians who played and most specifically to the Beastie Boys.
So which is worse? Sucking up to dictators in the name of the sick poor to help the sick poor -- or -- sucking up to rich democracies in the name of social resistance in order to help your bank account.
Cop smokes Pot, heads on over to the local convenience store to grab some munchies, sees a robbery in progress, arrests the guy, continually says, "Hey dude, just chill out man. It's no biggie," buys some twinkies and cheetos, and leaves *without the perp*. (Dude! I totally spaced.)
Cop drops Acid, sees someone with a devil's head. But was it really a devil's head? How would I recognize a devil's head if I saw it? What is so evil about a devil's head? I mean, I don't even go to church often. It's bullshit. This whole Judeo-Christian thing is just out of control. It brainwashes people. Wait... Am I brainwashed too? No way. To question is to be sane, right? But is sanity mutually exclusive to brainwashing? Brainwashing. Like with soap and water? What would that do? I mean. It might hurt. But would it clean your thoughts...y'know...if you could do it right? How would you do it right? Just be very careful. Very very careful. Very very very careful. Okay, gonna clean those thoughts when I get home from work. Okay, back to the grind. Back to work. Hey! That guy has a devil's head. But how would I recognize a devil's head?...
And where's the alcohol? Cop drinks a bunch of shots, and suddenly "everyone" wants to start something. You want some? You want some of this!?! Get over here ya fucking punk! I don't give a shit what you said. You calling me a liar you little...? What's up! Get in the fucking car!
(1 hour later) What Chief? No! They guy was getting in my face. Hell no I didn't do that to his face. Witnesses my ass. I would remember doing that. No! All I'm saying is...
-----
In other news, "the shakes"? From Pot and LSD? LSD and Pot are physically addictive? Since when? I don't know about anyone else, but after 10-12 hours of an LSD, I am more than done for the duration.
Support for Java is at version 1.1.4? That is your "works great" for Kaffe? AWT and Swing are a relatively minor issue. What about Collections, JAXP, scrollable database cursors, non-blocking I/O, references, etc.?
gcj, on the other hand, has much better support for these but only rudimentary support for AWT/Swing.
I'll take the latter thank you. If Kaffe's your metric for sufficient quality, I've got a C compiler compiler for you. It's missing stdlib.h and support for function pointers, but other than that, it works great.
I "wasn't there?" What "there" would that be? You mean when the Apple II came out? I daresay that I was "there." I was "there" when the C-64 came out. I remember loading up blackjack and backgammon on a cassette player hooked up to an Exidy Sorceror that had been upgraded from 16K to a whopping 32K of memory. Woohoo!
CLOAD BJACK
*press play*
This was before the days of Commodore branded cassette players. This tape player was like any other you buy in stores at the time, and it would take about 15-20 minutes to load before playing. It was on this computer that I wrote my first programs. Rocket ships flying across the screen and the like.
The folks who started out doing assembly in the 70s had it easy. The folks before them called their programming language "a soldering iron" and their disk drives "punch cards." The point is, it's all relative. What you would call wizards, some would call Johnny-come-latelys.
I am not at all saying that knowledge of (various dialects of) assembly is bad. Far, far from it. I found it quite enlightening; But taking pride in one's tasks and looking deeper into the "why"s and "wherefore"s makes you a better programmer, not a fixation on assembly. I've known "old-timers" who wrote absolutely horrendous code. They didn't care. I've also met sixteen-year-olds who didn't know C let alone assembly that made JavaScript and Perl routines that are as good as they could have been. They usually did care a great deal.
Could the "wizards" do amazing things with assembly? Yup. Can I do the same? Probably not. Since I learned assembly, I haven't used it at all. I get the job done in C (or a higher-level language) and I get it done faster than the assembly guys. Why? Because assembly is slow and tedious. It can be fascinating when you are in the mood for that kind of minutiae, but most of the time, I prefer other kinds of minutiae.
I know how to make a NOT and a NAND gate. This doesn't help me in my daily life. I was not a crap coder, learned assembly, and voila! I was a great coder. I started learning. I sucked. I kept at it. I had fun. I got better. I kept at it. And now I can hold my own in multiple languages on multiple platforms. Time on task and interest got me going, not assembly.
The reason why there are so many more perceived crap coders is because there are so many more coders. In the 70s, computers were a rarified field and hobbyists were few, far between, and passionate about it. There are just as many (and possibly more) passionate individuals today, but computers are mainstream. With becoming mainstream, the computer field has quite a few new recruits who either just want to make a quick buck or have it as a passing fancy where no real time is spent. And that's fine. It's not like it makes someone a bad or stupid person.
CS graduates take memory for granted for good reason. Memory is cheap and plentiful. 256MB costs $30. I remember saving up $600 after a summer job and purchasing 16MB of RAM. Learning the difference between an O(n) and an O(n^2) algorithm is not something that can only come from the use of assembly. Learning that a CPU has a 128KB L2 cache versus another with 512MB and that certain routines are more prone to cache misses is not dependent upon knowing assembly. Assembly can help you see the mechanics up close and personal, but anyone who knows to look at specs and can multiply can figure it out.
And finally, management is something that happens over time to most folks. It is not because they couldn't do their job. In fact, many knew their job so well that it was getting boring. Rather than problem solving an errant resource leak, many go on to problem solve why some director of operations is harrassing my team over a lower priority item. Skill in one does not mean skill in the other. They both take practice. I take from your attitude that you have never been a manager for any real length of time. That's fine. For what it's worth, I am a better programmer than I am a manager.
I've just pointed out that the salad has roaches and rat feces in it and someone steps up to chastise me for using the wrong fork.
INSERT INTO test
(id, num1, num2, num3, price, code) VALUES (
0,
99999999999999,
NULL,
'A quick brown dolphin...',
21474.83,
'ABCDEFGHIJK' );
Now the syntax should be kosher....and MySQL still acts like a brain dead cat on crack.
All functions I write check that the data I'm getting or putting to the database matches the data type.
And I applaud you for that. It's good to know that you never make mistakes, are always fully rested, are never up against a hard deadline, etc. I'm not questioning your coding skills or your intelligence. On the contrary, I think that extra checks are always worth it. What I am saying is that the database, the final repository for your data, should be making at least the same amount of effort.
When the string 'A quick brown dolphin...' is passed to an integer field because I'm overly tired, a collegue hasn't been as rigorous as I usually am, some crack-smoking intern had a brain fart, or whatever, the fact remains that MySQL detected that it wasn't an integer. It didn't try to throw it in as the first 32-bits of the binary string. The table needed a number, MySQL had no idea what number you meant, and it decided to put in the default value for the column according to its datatype. In other words, it placed a value that I didn't explicitly specify through the client or schema and did not warn the client that it had done so.
Imagine if all of those POSIX networking functions didn't return an error code. Why not? I'm sure there are folks out there who will say, "But my network is always up, the cables are of highest quality, and in all the time I've worked there, I have never had a socket connection fail; so why do I need the error code back?" No matter the preparation, no matter the training, no matter how good the conditions are, when the rubber hits the road, I would like to be able to see out of the windshield to see if I've spun out.
This is the salient point that people (including the pager-adorned gentleman in the parent post) appear to blithely ignore. It's the giant pink elephant in the corner that everyone notices but no one wants to talk about.
By all means, perform the extra checks. Perform a check at compile time, at deploy time, and at runtime. Why are MySQL folks so averse to having a check at insert/update time as well? Why is it such an affront to want your database to do its own data integrity checks? Why is it so horrible to expect a relational database to do its job!? I honestly want to know. I would very much like some insight into this rather than picking on my choice of salad fork.
...where you got that I thought "professional == statically typed." It was the comment about Fortune 100 companies wasn't it? Hmmm...
No, that was not my intent. Truth be told, I doubt they are using Perl or PHP to any large extent. Or even C++ for that matter. Chances are that the workhorses for those companies predate the creation of Perl and PHP...probably even C++ in its CFront days. Those companies have tons of COBOL that, while it works, they will never ever mess with. If their infrastructure were written in Eiffel, it wouldn't be going anywhere. If it were written in BASIC, as long as it has worked for twenty years and continues to work, no one is touching it.
Once again, I brought up those languages because of the legions of 31337 coders whose claim to greatness is a 500 character long, single line Perl script. They're not dumb or inferior. They just don't know any better yet.
Your claim that "professional" companies only use statically typed languages also seems rather unfounded.
I'm looking at my previous post, but I can't seem to find that statement. Where did you see me write that? Nice misquote. You missed not only the spirit, but the letter of what I said. I only brought up Perl and PHP because those are examples of languages where many people are just starting out -- Perl was one of my first as well. I also brought those up because, unlike statically typed languages, errors can go through easily because there's no catch to say "this is supposed to be a number between 0 and 255" for example. Everything else you inferred was from your own defensiveness I think.
As for the PostgreSQL gotchas page, as a user of PostgreSQL, I can safely say that I have not come across anything like what was found on the MySQL gotchas page; There was nothing even close with regard to scope. And in the event that some weird behavior comes up, I'm pretty sure that PostgreSQL will at least warn me about it.
If the MySQL page were written with the rigor of the PostgreSQL page, there would be far more "gotchas" for MySQL. For example, the two PostgreSQL issues were differences with the official SQL spec -- not data consistency issues. If you were to include all of the aspects of MySQL that did not conform to the ANSI SQL standards (any of the ones over the years not to mention the most recent ones), the gotchas page would be about as long as the main MySQL documentation. Yes, it's that bad.
Now then, as for the failure to quote the third sentence, I'd be very surprised to find that "a few more gotchas to follow" would come to equal the twenty seven gotchas that MySQL has. There are twice as many categories of gotchas in MySQL than there are total gotchas for PostgreSQL.
But fair's fair. I'll add a few for PostgreSQL.
"MySQL with MyISAM tables is faster for selects and mostly read-only databases." Then again, I haven't accurately benched it myself. When I make a database schema in PostgreSQL, it cannot be mapped to MySQL easily. The only way to make a comparison is to strip my PostgreSQL database of many of its advantages both in performance and maintainability like triggers, views, rules, stored procedures, foreign keys that actually prevent you from dropping related tables, domains, schemas, real SQL sequences, etc.
Oh wait! MVCC (Multiversion Concurrency Control) doesn't apply when trying to check for duplicates with a SELECT followed by an INSERT. In other words, short of locking the table, you can't guarantee that if a SELECT comes up empty, that another client doesn't INSERT something before you get there. This of course is followed by an error as opposed to silent do-whatevers of MySQL coupled with the fact that MySQL can't do any better with this problem and frequently does worse.
Here's one: PostgreSQL cannot restrict access to just a column. The only workaround is to make a view without that column and set the rights appropriately. Finally, a real issue. I should submit that one to the PostgreSQL gotcha page maintainer.
Is PostgreSQL the end-all be-all? No, of course not. I never said it was. I only assert that MySQL is only fitting to a project with a very loose set of requirements -- requirements that don't include safety of your information, the raison d'etre of a RDBMS.
So if you want to store data, be able to retrieve it quickly, don't do too many inserts or updates, only access from a limited amount of simultaneous clients, don't care too much about crap accumulating in the tables, and have a good reason to eshew a custom data storage structure tailored to your specific needs, then by all means, MySQL is the database for you!
Use what you like, but choosing a toy (Yes! I'm calling it a toy!) to a real RDBMS seems a little bit unfair.
Apple computers came with only BASIC and assembly language, and there were books available on assembly language for kids. This is why the old-timers are often viewed as 'wizards'.
More likely, they're "wizards" because they've been programming since the release of the Apple II. If you had been coding for twenty five years, I sincerely hope that kids just coming up see you as a wizard. Otherwise, you have just wasted the last twenty five years of your life with no visible improvement.
All of the veterens know assembly because that's all they had. In twenty five years, all of the veterens will have started with Java or Perl or Python. They will probably have picked up some assembly along the way, but they will be able to whip out an efficient, global-scale, distributed program far faster than those old assembly coders....and then they'll move into management just as those before them.
At least not ones that conform to the ANSI SQL definition of sequences.
Sending a NULL to an AUTO_INCREMENT field is not the same as an SQL sequence.
Can you skip numbers easily in MySQL (eg. tell the DB to continue from some arbitrary number next)? Can you put explicit values into the column without the AUTO_INCREMENT overriding you silently? (My favorite part: MySQL changing the values you enter without even telling you.) Can you tell a MySQL sequence to have a maximum value lower than the maximum value of the underlying datatype or a starting value of higher than 1? (No, multiple inserts and then deleting them after doesn't count.)
The syntax may be different between all three, but when you pull back the curtain, the one in MySQL are a very different and limited beast.
For varying definitions of "quite a while." Other than that I would agree with you except for the fact that every table involved in the transaction must be an InnoDB table. Have a half-and-half setup? When that transaction rolls back, the InnoDB tables will remove the changes, but the MyISAM tables will still be changed....not that MySQL will tell you this. No. Once again, it will do it all silently without even a warning to let you know that you need to convert one more of your MyISAM tables to InnoDB.
Which doesn't even cover the fact that if you are being hosted by an ISP, using their copy of MySQL, and you type in:
CREATE TABLE foo ( ... ) type=innodb;
and they are either (a) running an older version of MySQL or (b) disabling support for InnoDB tables because of their noticeably higher overhead than MyISAM (yes, both cases happen quite regularly), you will be none the wiser.
MySQL will not issue a warning, error, or valentine's day card for your troubles. So here you are, happily SQLing away without a care because you have InnoDB tables until you notice some strange data...because...you aren't running InnoDB tables after all.
Be honest, how often do you run the following?
SHOW CREATE TABLE foo;
Everytime you create a table? No?
How about the next statement? Here we attempt to give some users on Slashdot 10% more of a clue.
UPDATE slashdot_users SET (clue = (clue * 1.1)) WHERE preferred_db = 'MySQL';
and (oops!) something went wrong halfway through for some reason. Maybe someone killed the process. Maybe someone kicked a cord. Maybe you ran out of memory on the box and the process crashed. The world is an imperfect place. Back to work though: how many Slashdot users had their clues upped? If they were updating a MyISAM table that "didn't need transactions," we have no idea.
Transactions aren't just BEGIN and END statements. They aren't just commit() and rollback() functions. They are intrinsic to a valid datastore. They are the Atomicity in ACID. That UPDATE statement was a transaction in all contexts used to describe databases.
MySQL and transactions are like assembly language and for-loops. They can be made to go together, but they were not originally designed for such a task. In assembly, it's a set of well-placed jump (goto) statements. In MySQL, it's a set of table=innodb flags. Some people do it the hard way for no good reason even when easier, less error prone methods exist. For the rest of us, we use a higher-level language or -- in this case -- a higher-level database. If and only if we see a need to optimize do we drop down to assembly (MySQL). You don't start with assembly and then try to find rationales for a higher-level language.
Even with an O(n) scheduler, an idle daemon is nothing. While some others may be impressed with your use of Big-O notation, many of us are not. Even an O(n^2) algorithm isn't that bad if your dataset is sufficiently small. The O(1) scheduler is a glorious thing only because the number of processes (forks, threads, etc.) reaches very high amounts on a large, loaded system. At hundreds of thousands of processes/threads, the choice of scheduler makes a big difference in overhead. And for that matter, if the number of processes without an idle RDBMS running is 100,000, and the RDBMS pushes it to 100,005, the scheduler isn't going to care. It'll be highly unlikely that you could reliably measure a difference.
At smaller numbers (one or two hundred), who cares? Your server isn't using 100% of your resources (CPU or otherwise). They are just going to waste if there's no RDBMS loaded.;-)
This argument is old. It's like the assembly vs. C debates in the seventies....and just as clear cut. "Premature optimization is the root of all evil." Works for system administration as well as software engineering. The real question isn't "which is more efficient?" The real question is "which gets the job done faster?" If I can start a RDBMS and walk away, that constitutes "faster" to me.
In most modern operating systems, inactive processes can be swapped out in favor of disk buffers and the like as well. Besides that, the memory used by an inactive MySQL process is closer to "rounding error" than "waste of memory."
But if you're still worried about it, an extra 256MB is hovering around $30 on Pricewatch.com. Hmmm... $30 and never having to worry about it or any other inactive daemons on my system again or...
I don't know about you, but my time is worth more than that.
Slashdot Mirror
That's all well and good, but why not have a standard library have it? I'm not saying that it all has to go into one monstrous libc.so. Make it libcutil.so or some other separate library so that people won't whine about bloat. The point I'm trying to make is that linked lists, sets, priority queues, etc. are all solved problems. To a large extent, so is a window, a button, a sound clip, and a database connection.
It reminds me of the PHP database API madness. mysql_select(...)!?! PHP was created after Perl and Java and yet they couldn't figure out that database abstraction and DBI/JDBC were good ideas?
You want choice? Great! I agree with you. Competition is good. But give me a common header file so that to swap implementations, all I need to do is recompile or relink. We don't need twenty billion APIs for "play audio clip" do we?
Standardization always preceeds implementation. So how long is too long? One year? Two? Six months? It took the STLPort folks 2-3 years for a working implementation after the official spec was published. That doesn't sound too bad to me for a bunch of volunteers.
From the Cygwin mailing list: "data doesn't necessarily return a zero-terminated string, it simply returns a ptr to the raw data. It is only zero-terminated if you call c_str() which is, of course, why there are two functions in the first place."
Do you want a NULL-terminated string? Use
#include <sstream>
Use of the other two is deprecated per the 1998 standard. You couldn't read that part of the spec in the six years that it's been published?
Bah. GCC 3.x has had a ISO-98 standard C++ library for the last two years. STLPort has been around for even longer.
You'd better laugh when you say that. Open up just about any C program over 1000 lines long. Do you see #ifdefs? Are they for avoiding cross-target compilation issues? So much for portability.
Yeah, I know it's intentional. That's the point of my argument. The same is true in Java as well. A program will state "requires Java 1.2 or above" or "requires the use of custom ImageI/O SPIs for formats beyond JPEG and GIF." As long as you state the version, you're covered. People write to a newer API than what you have running on your server? Congrats! You are in the same boat we are now with Qt libraries, Gnome libraries, OpenGL drivers, and ODBC interfaces. API version conflicts have nothing to do with this discussion.
Take a Java program at least 1,000 lines long. Does it run on the equivalent version of the JVM on Linux, Mac OSX, Windows, etc.? Does it run in the IBM build as well as the Sun JVM? Yes. Why? Standardized API. Period.
Look up embedded Java. You may be surprised.
No, the STL *is* standardized. ISO C++98. There's a difference between a lack of a standard and incomplete implementations.
If I use std::string or std::vector in my code, it compiles and it works no matter the implementation. You are confusing warts with fundamental deficiencies.
MFC and OWL? Yes, they are a problem. I sure wish C++ would come up with a standard GUI API and let others plug in their own implementation. <sarcasm>Oh wait! That was the point of my original rant, wasn't it?</sarcasm>
Shoot, I should have added that to my list (no pun intended) of C deficiencies.
It's been over thirty years. Linked lists, binary trees, red-black trees, hashtables, sets, priority queues, et al. have not changed all that much. It would be nice to not make everyone reinvent the data structure wheel.
A lot of folks make this claim and yet conveniently forget that Qt/GTK+, ALSA/OSS, ODBC, et al. take up space too. In fact, considering the fact that Qt and GTK+, ALSA and OSS, etc. must all be installed because programs are being written specifically for them instead of a common API and pluggable implementation, it's actually less space to install a JRE.
This is not to say that I think Java couldn't be more modular. I'd welcome some separation like a network module and a sound module (or all in one go like it is now). But, warts and all, Java is at least moving in the right direction. C, on the other hand, isn't moving at all.
Nothing is static. That was my complaint about the standard C library. It is static... stagnant... showing its age.
.NET fixes many of those warts.
This does not diminish the fact that AWT was the first Java GUI API. It had limitations. It was redesigned to be truly cross-platform and dubbed Swing. As far as the API is concerned, I happen to like the Swing library. Is it "THE ONE TRUE GUI API?" Of course not. Nothing is or ever will be. It was the best they could come up with at the time. Now, when someone learns the standard Java GUI API (or just about any other Java API for that matter), they can transfer those skills to other Java projects much more easily than C coders can in C projects.
SWT? A nice start. It is not as complete, does not run on as many platforms, nor is as widely used as Swing. But it shows promise. In five more years, who knows? That's the point. Right now, there is a standard API that everyone knows and other APIs (that aren't drastically different from the AWT/Swing API by the way) being tried out to find better ways of doing things.
Mono's choice of GTK# is in my opinion a bad move. It's also unfortunate that Microsoft hasn't opened up the APIs for the Windows GUI libraries. I understand their reasons for doing it (Microsoft patent threats), but the culture of C is too strong. Instead of writing a new, GUI toolkit agnostic interface API, they intimately tied it GTK.
C and the programming culture it fosters is building on sand; New APIs are constantly (and in my opinion, unnecessarily) being written all of the time, but there's no common base for others to work on nor to use as a base API design reference. Imagine how much more software would be written if folks didn't have to battle over GTK/Qt, MySQL/PostgreSQL/ODBC client libraries, ALSA/OSS, etc.? Would it be so terrible to tell people, "OpenGL is the standard API interface for 2D graphics in C. How you implement the OpenGL layer is up to you, but use the standard header files so that people can just recompile/relink to use a different implementation.
Don't think it's necessary? Let's look at the history of UNIX, the original C program. The API wasn't standardized and set in stone. Different vendors went their own way in an attempt to lock the others out of their turf. UNIX programs commonly became a mess of #ifdef statements. The Windows came in touting a common API for Windows with COM. Any language (well, the common ones... VB, C, C++, etc.) could use these objects. They had a well-defined API. New implementations (eg. Perl for Windows) could be modified to access these objects as well. It didn't matter what language the COM object was written in. It didn't matter what language you were using. Write to the interface and be done with it. COM had warts. Everything does.
The C community on the other hand just sticks its head in the sand and collectively says, "Look! They didn't do it perfectly. They suck! We rule!"
The C community should be saying, "Look! None of us did it perfectly. Let's make our baby better by taking some of their good ideas and incorporating a bunch of our own."
Mono and Java have warts, but at least they're trying. What's C got show for thirty years? Variable length arrays in function declarations? That is the best thing anyone could come up with for C99? Hey folks! There's an elephant in the corner! It's name is "incomplete standard library." I know no one wants to talk about it, but it's there and taking up too much space at the party!
Or we can look at it like this: "Wouldn't it be better to have many different toolkits that allow string concatenation and tokenization than one standard library of string functions?"
Or maybe this: "Isn't it great that we have several different native APIs for threads, processes, and IPC depending on underlying platform, five different and incompatible implementations for cross-platform usage, and no way to easily switch between implementations after the project is underway?"
And next shall we talk about databases? Or maybe sound processing? Or regular expressions? Hmmm...
The thing that C zealots fail to recognize is the need for clean, standardized APIs (NOT implementations). If you write code that uses strncmp(...), aren't you glad that you don't have to worry if the C implementation is the BSD libc or glibc or MS Windows' C library? Don't you wish the same could be said for the user interface libraries -- for example being able to swap out the Qt or GTK+ implementations at compile or link time? Or the database libraries? (ODBC? Don't make me laugh.) But you can't because each implementation has its own interface even though a button is a button, a checkbox is a checkbox, a database connect is a database connect, a regexp is a regexp, etc.
This is what .NET gives; Not the mandated implementation, but much better it gives the recommended interface. If the C folks get it together and standardize more than just things like printf(...) and linked lists, you will get no end of gratitude from me and the gratitude of folks who are tired of reinventing the wheel and solving problems that were adequately solved twenty years ago. Unless that happens, you're gonna see more and more people moving to things like .NET and Java, warts and all.
POSIX was a good start, but it has stagnated and is showing its age.
If you choose to make your own XML document schema, you lose out on the preprepared stylesheets and converters. On the other hand, a schema made for the task at hand is usually easier to use and understand.
As a compromise, you might to check out the progress on XHTML 2.0. It has a syntax not too far removed from the HTML we've all seen before, but 2.0 is closer to the DocBook model of semantics rather than presentation. It is also more likely to be supported by 3rd party clients in the future. (There is already an XHTML 2.0 renderer available for Mozilla.)
Whatever you do, make sure the markup relates to meaning and NOT how it looks. Looks change, but if you don't take care to the meaning/semantics from the beginning, it is prohibitively difficult to put in in later. For example, it's easy to make all annotations and citations red. It's not so cut and dried to change all red text to annotations (when citations or emphasized text may be formatted in red).
Maggots clean wounds. When you work on a shoestring budget, you tend to go for homespun remedies. Antibiotics are expensive -- especially in the volume necessary for the number of people she helped. It may offend your delicate sensibilities, but it works, and the money saved can be used for expensive treatments that maggots can't solve.
Twisted and manipulative? She twisted and manipulated her way into helping more people than most. Sucking up to dictators? If they gave her money, good. Shouldn't the relevant question be "why didn't supposedly civilized democracies give her all the support she needed?" She played politics. Big whup.
You want duplicitous? How about the Beastie Boys? They organized huge events in the name of "Free Tibet." Know where the proceeds went? Not to Tibetan resistance groups. Not a check to the Dalai Lama. Not money to Amnesty International. Not to relief organizations.
To the musicians who played and most specifically to the Beastie Boys.
So which is worse? Sucking up to dictators in the name of the sick poor to help the sick poor -- or -- sucking up to rich democracies in the name of social resistance in order to help your bank account.
Cop smokes Pot, heads on over to the local convenience store to grab some munchies, sees a robbery in progress, arrests the guy, continually says, "Hey dude, just chill out man. It's no biggie," buys some twinkies and cheetos, and leaves *without the perp*. (Dude! I totally spaced.)
...
Cop drops Acid, sees someone with a devil's head. But was it really a devil's head? How would I recognize a devil's head if I saw it? What is so evil about a devil's head? I mean, I don't even go to church often. It's bullshit. This whole Judeo-Christian thing is just out of control. It brainwashes people. Wait... Am I brainwashed too? No way. To question is to be sane, right? But is sanity mutually exclusive to brainwashing? Brainwashing. Like with soap and water? What would that do? I mean. It might hurt. But would it clean your thoughts...y'know...if you could do it right? How would you do it right? Just be very careful. Very very careful. Very very very careful. Okay, gonna clean those thoughts when I get home from work. Okay, back to the grind. Back to work. Hey! That guy has a devil's head. But how would I recognize a devil's head?
And where's the alcohol? Cop drinks a bunch of shots, and suddenly "everyone" wants to start something. You want some? You want some of this!?! Get over here ya fucking punk! I don't give a shit what you said. You calling me a liar you little...? What's up! Get in the fucking car!
(1 hour later)
What Chief? No! They guy was getting in my face. Hell no I didn't do that to his face. Witnesses my ass. I would remember doing that. No! All I'm saying is...
-----
In other news, "the shakes"? From Pot and LSD? LSD and Pot are physically addictive? Since when? I don't know about anyone else, but after 10-12 hours of an LSD, I am more than done for the duration.
Support for Java is at version 1.1.4? That is your "works great" for Kaffe? AWT and Swing are a relatively minor issue. What about Collections, JAXP, scrollable database cursors, non-blocking I/O, references, etc.?
gcj, on the other hand, has much better support for these but only rudimentary support for AWT/Swing.
I'll take the latter thank you. If Kaffe's your metric for sufficient quality, I've got a C compiler compiler for you. It's missing stdlib.h and support for function pointers, but other than that, it works great.
So they're supposed to use Debian unstable for their production server?
Hmmm...
I stand corrected
I "wasn't there?" What "there" would that be? You mean when the Apple II came out? I daresay that I was "there." I was "there" when the C-64 came out. I remember loading up blackjack and backgammon on a cassette player hooked up to an Exidy Sorceror that had been upgraded from 16K to a whopping 32K of memory. Woohoo!
CLOAD BJACK
*press play*
This was before the days of Commodore branded cassette players. This tape player was like any other you buy in stores at the time, and it would take about 15-20 minutes to load before playing. It was on this computer that I wrote my first programs. Rocket ships flying across the screen and the like.
The folks who started out doing assembly in the 70s had it easy. The folks before them called their programming language "a soldering iron" and their disk drives "punch cards." The point is, it's all relative. What you would call wizards, some would call Johnny-come-latelys.
I am not at all saying that knowledge of (various dialects of) assembly is bad. Far, far from it. I found it quite enlightening; But taking pride in one's tasks and looking deeper into the "why"s and "wherefore"s makes you a better programmer, not a fixation on assembly. I've known "old-timers" who wrote absolutely horrendous code. They didn't care. I've also met sixteen-year-olds who didn't know C let alone assembly that made JavaScript and Perl routines that are as good as they could have been. They usually did care a great deal.
Could the "wizards" do amazing things with assembly? Yup. Can I do the same? Probably not. Since I learned assembly, I haven't used it at all. I get the job done in C (or a higher-level language) and I get it done faster than the assembly guys. Why? Because assembly is slow and tedious. It can be fascinating when you are in the mood for that kind of minutiae, but most of the time, I prefer other kinds of minutiae.
I know how to make a NOT and a NAND gate. This doesn't help me in my daily life. I was not a crap coder, learned assembly, and voila! I was a great coder. I started learning. I sucked. I kept at it. I had fun. I got better. I kept at it. And now I can hold my own in multiple languages on multiple platforms. Time on task and interest got me going, not assembly.
The reason why there are so many more perceived crap coders is because there are so many more coders. In the 70s, computers were a rarified field and hobbyists were few, far between, and passionate about it. There are just as many (and possibly more) passionate individuals today, but computers are mainstream. With becoming mainstream, the computer field has quite a few new recruits who either just want to make a quick buck or have it as a passing fancy where no real time is spent. And that's fine. It's not like it makes someone a bad or stupid person.
CS graduates take memory for granted for good reason. Memory is cheap and plentiful. 256MB costs $30. I remember saving up $600 after a summer job and purchasing 16MB of RAM. Learning the difference between an O(n) and an O(n^2) algorithm is not something that can only come from the use of assembly. Learning that a CPU has a 128KB L2 cache versus another with 512MB and that certain routines are more prone to cache misses is not dependent upon knowing assembly. Assembly can help you see the mechanics up close and personal, but anyone who knows to look at specs and can multiply can figure it out.
And finally, management is something that happens over time to most folks. It is not because they couldn't do their job. In fact, many knew their job so well that it was getting boring. Rather than problem solving an errant resource leak, many go on to problem solve why some director of operations is harrassing my team over a lower priority item. Skill in one does not mean skill in the other. They both take practice. I take from your attitude that you have never been a manager for any real length of time. That's fine. For what it's worth, I am a better programmer than I am a manager.
INSERT INTO test
(id, num1, num2, num3, price, code)
VALUES (
0,
99999999999999,
NULL,
'A quick brown dolphin...',
21474.83,
'ABCDEFGHIJK'
);
Now the syntax should be kosher.
And I applaud you for that. It's good to know that you never make mistakes, are always fully rested, are never up against a hard deadline, etc. I'm not questioning your coding skills or your intelligence. On the contrary, I think that extra checks are always worth it. What I am saying is that the database, the final repository for your data, should be making at least the same amount of effort.
When the string 'A quick brown dolphin...' is passed to an integer field because I'm overly tired, a collegue hasn't been as rigorous as I usually am, some crack-smoking intern had a brain fart, or whatever, the fact remains that MySQL detected that it wasn't an integer. It didn't try to throw it in as the first 32-bits of the binary string. The table needed a number, MySQL had no idea what number you meant, and it decided to put in the default value for the column according to its datatype. In other words, it placed a value that I didn't explicitly specify through the client or schema and did not warn the client that it had done so.
Imagine if all of those POSIX networking functions didn't return an error code. Why not? I'm sure there are folks out there who will say, "But my network is always up, the cables are of highest quality, and in all the time I've worked there, I have never had a socket connection fail; so why do I need the error code back?" No matter the preparation, no matter the training, no matter how good the conditions are, when the rubber hits the road, I would like to be able to see out of the windshield to see if I've spun out.
This is the salient point that people (including the pager-adorned gentleman in the parent post) appear to blithely ignore. It's the giant pink elephant in the corner that everyone notices but no one wants to talk about.
By all means, perform the extra checks. Perform a check at compile time, at deploy time, and at runtime. Why are MySQL folks so averse to having a check at insert/update time as well? Why is it such an affront to want your database to do its own data integrity checks? Why is it so horrible to expect a relational database to do its job!? I honestly want to know. I would very much like some insight into this rather than picking on my choice of salad fork.
...where you got that I thought "professional == statically typed." It was the comment about Fortune 100 companies wasn't it? Hmmm...
No, that was not my intent. Truth be told, I doubt they are using Perl or PHP to any large extent. Or even C++ for that matter. Chances are that the workhorses for those companies predate the creation of Perl and PHP...probably even C++ in its CFront days. Those companies have tons of COBOL that, while it works, they will never ever mess with. If their infrastructure were written in Eiffel, it wouldn't be going anywhere. If it were written in BASIC, as long as it has worked for twenty years and continues to work, no one is touching it.
Once again, I brought up those languages because of the legions of 31337 coders whose claim to greatness is a 500 character long, single line Perl script. They're not dumb or inferior. They just don't know any better yet.
I'm looking at my previous post, but I can't seem to find that statement. Where did you see me write that? Nice misquote. You missed not only the spirit, but the letter of what I said. I only brought up Perl and PHP because those are examples of languages where many people are just starting out -- Perl was one of my first as well. I also brought those up because, unlike statically typed languages, errors can go through easily because there's no catch to say "this is supposed to be a number between 0 and 255" for example. Everything else you inferred was from your own defensiveness I think.
As for the PostgreSQL gotchas page, as a user of PostgreSQL, I can safely say that I have not come across anything like what was found on the MySQL gotchas page; There was nothing even close with regard to scope. And in the event that some weird behavior comes up, I'm pretty sure that PostgreSQL will at least warn me about it.
If the MySQL page were written with the rigor of the PostgreSQL page, there would be far more "gotchas" for MySQL. For example, the two PostgreSQL issues were differences with the official SQL spec -- not data consistency issues. If you were to include all of the aspects of MySQL that did not conform to the ANSI SQL standards (any of the ones over the years not to mention the most recent ones), the gotchas page would be about as long as the main MySQL documentation. Yes, it's that bad.
Now then, as for the failure to quote the third sentence, I'd be very surprised to find that "a few more gotchas to follow" would come to equal the twenty seven gotchas that MySQL has. There are twice as many categories of gotchas in MySQL than there are total gotchas for PostgreSQL.
But fair's fair. I'll add a few for PostgreSQL.
"MySQL with MyISAM tables is faster for selects and mostly read-only databases." Then again, I haven't accurately benched it myself. When I make a database schema in PostgreSQL, it cannot be mapped to MySQL easily. The only way to make a comparison is to strip my PostgreSQL database of many of its advantages both in performance and maintainability like triggers, views, rules, stored procedures, foreign keys that actually prevent you from dropping related tables, domains, schemas, real SQL sequences, etc.
Oh wait! MVCC (Multiversion Concurrency Control) doesn't apply when trying to check for duplicates with a SELECT followed by an INSERT. In other words, short of locking the table, you can't guarantee that if a SELECT comes up empty, that another client doesn't INSERT something before you get there. This of course is followed by an error as opposed to silent do-whatevers of MySQL coupled with the fact that MySQL can't do any better with this problem and frequently does worse.
Here's one: PostgreSQL cannot restrict access to just a column. The only workaround is to make a view without that column and set the rights appropriately. Finally, a real issue. I should submit that one to the PostgreSQL gotcha page maintainer.
Is PostgreSQL the end-all be-all? No, of course not. I never said it was. I only assert that MySQL is only fitting to a project with a very loose set of requirements -- requirements that don't include safety of your information, the raison d'etre of a RDBMS.
So if you want to store data, be able to retrieve it quickly, don't do too many inserts or updates, only access from a limited amount of simultaneous clients, don't care too much about crap accumulating in the tables, and have a good reason to eshew a custom data storage structure tailored to your specific needs, then by all means, MySQL is the database for you!
Use what you like, but choosing a toy (Yes! I'm calling it a toy!) to a real RDBMS seems a little bit unfair.
More likely, they're "wizards" because they've been programming since the release of the Apple II. If you had been coding for twenty five years, I sincerely hope that kids just coming up see you as a wizard. Otherwise, you have just wasted the last twenty five years of your life with no visible improvement.
All of the veterens know assembly because that's all they had. In twenty five years, all of the veterens will have started with Java or Perl or Python. They will probably have picked up some assembly along the way, but they will be able to whip out an efficient, global-scale, distributed program far faster than those old assembly coders.
...who modded me flamebait. Since I don't feel like reposting all of it, here's another one of my comments that covers this:
An example of MySQL suckage
Production quality doesn't just mean "doesn't crash." Production quality for a DB means "keeps my data safe."
Once again, there still isn't a production-quality MySQL server.
At least not ones that conform to the ANSI SQL definition of sequences.
Sending a NULL to an AUTO_INCREMENT field is not the same as an SQL sequence.
Can you skip numbers easily in MySQL (eg. tell the DB to continue from some arbitrary number next)? Can you put explicit values into the column without the AUTO_INCREMENT overriding you silently? (My favorite part: MySQL changing the values you enter without even telling you.) Can you tell a MySQL sequence to have a maximum value lower than the maximum value of the underlying datatype or a starting value of higher than 1? (No, multiple inserts and then deleting them after doesn't count.)
The syntax may be different between all three, but when you pull back the curtain, the one in MySQL are a very different and limited beast.
For varying definitions of "quite a while." Other than that I would agree with you except for the fact that every table involved in the transaction must be an InnoDB table. Have a half-and-half setup? When that transaction rolls back, the InnoDB tables will remove the changes, but the MyISAM tables will still be changed. ...not that MySQL will tell you this. No. Once again, it will do it all silently without even a warning to let you know that you need to convert one more of your MyISAM tables to InnoDB.
...
Which doesn't even cover the fact that if you are being hosted by an ISP, using their copy of MySQL, and you type in:
CREATE TABLE foo (
) type=innodb;
and they are either (a) running an older version of MySQL or (b) disabling support for InnoDB tables because of their noticeably higher overhead than MyISAM (yes, both cases happen quite regularly), you will be none the wiser.
MySQL will not issue a warning, error, or valentine's day card for your troubles. So here you are, happily SQLing away without a care because you have InnoDB tables until you notice some strange data...because...you aren't running InnoDB tables after all.
Be honest, how often do you run the following?
SHOW CREATE TABLE foo;
Everytime you create a table? No?
How about the next statement? Here we attempt to give some users on Slashdot 10% more of a clue.
UPDATE slashdot_users SET (clue = (clue * 1.1)) WHERE preferred_db = 'MySQL';
and (oops!) something went wrong halfway through for some reason. Maybe someone killed the process. Maybe someone kicked a cord. Maybe you ran out of memory on the box and the process crashed. The world is an imperfect place. Back to work though: how many Slashdot users had their clues upped? If they were updating a MyISAM table that "didn't need transactions," we have no idea.
Transactions aren't just BEGIN and END statements. They aren't just commit() and rollback() functions. They are intrinsic to a valid datastore. They are the Atomicity in ACID. That UPDATE statement was a transaction in all contexts used to describe databases.
MySQL and transactions are like assembly language and for-loops. They can be made to go together, but they were not originally designed for such a task. In assembly, it's a set of well-placed jump (goto) statements. In MySQL, it's a set of table=innodb flags. Some people do it the hard way for no good reason even when easier, less error prone methods exist. For the rest of us, we use a higher-level language or -- in this case -- a higher-level database. If and only if we see a need to optimize do we drop down to assembly (MySQL). You don't start with assembly and then try to find rationales for a higher-level language.
Even with an O(n) scheduler, an idle daemon is nothing. While some others may be impressed with your use of Big-O notation, many of us are not. Even an O(n^2) algorithm isn't that bad if your dataset is sufficiently small. The O(1) scheduler is a glorious thing only because the number of processes (forks, threads, etc.) reaches very high amounts on a large, loaded system. At hundreds of thousands of processes/threads, the choice of scheduler makes a big difference in overhead. And for that matter, if the number of processes without an idle RDBMS running is 100,000, and the RDBMS pushes it to 100,005, the scheduler isn't going to care. It'll be highly unlikely that you could reliably measure a difference.
;-)
...and just as clear cut. "Premature optimization is the root of all evil." Works for system administration as well as software engineering. The real question isn't "which is more efficient?" The real question is "which gets the job done faster?" If I can start a RDBMS and walk away, that constitutes "faster" to me.
At smaller numbers (one or two hundred), who cares? Your server isn't using 100% of your resources (CPU or otherwise). They are just going to waste if there's no RDBMS loaded.
This argument is old. It's like the assembly vs. C debates in the seventies.
In most modern operating systems, inactive processes can be swapped out in favor of disk buffers and the like as well. Besides that, the memory used by an inactive MySQL process is closer to "rounding error" than "waste of memory."
But if you're still worried about it, an extra 256MB is hovering around $30 on Pricewatch.com. Hmmm... $30 and never having to worry about it or any other inactive daemons on my system again or...
I don't know about you, but my time is worth more than that.