No. A MERGE is more a like a view on a UNION. It's MySQL's poor-mans version of partioned tables like they have it in Oracle.
I've just learned something new. Thanks.
Well, for version 2.0 the Apache folks have re-created their architecture. Apache has now a number of memory/process models (called MPMs). For Unix there exists now a threaded version besides the traditional forking server.
The hybrid threading/forking MPM is used by UNIX (mostly Solaris and Irix), but the pure threading MPM is basically just for Windows. It makes Apache much faster on Windows at the expense of robustness -- if the one process goes down, down goes the whole shebang.
Simpler to install? It comes packaged by default in RedHat. For Debian, it's apt-get install postgresql. For a source install, it's./configure;make;make install. Please explain to me how MySQL is easier.
Simpler? When you need to get a job done, you either have a simple database or a simple app. The amount of logic is the same.
If Joe Newbie doesn't need views, Joe Newbie doesn't have to use views....or rules, triggers, explicit transactions, or any of the other things that PostgreSQL can do that MySQL can't. It's not like PostgreSQL mandates the use of every feature.
On the other hand, Joe Newbie shouldn't need to learn about explicit locks, database integrity issues, workarounds because a feature isn't there, etc.
pg_dump is indeed required whenever a minor or major version change happens. That happens once a year or so. It's not like it happens once a week. And of course, that assumes that you upgrade according to PostgreSQL's release schedule. Why you would do that, I have no idea. More likely, you are upgrading/replacing the database box so you would have to dump the data no matter what software you were using.
If the version and hardware configuration are working well, why would you change anything (other than apply patches) by default?
As far as cheap hosting, that's fine. If the hosting company I have to work with has IIS, I'll be using asp won't I? An abundant option isn't necessarily better. It's just more abundant. Going from computer to computer, you're more likely to find Windows 98 than any other operating system. Does that mean it's better? Indeed, sometimes you have to use suboptimal tools to get the job done. This doesn't mean that you have to seek those suboptimal tools out.
If your data doesn't matter as much to you, it doesn't much matter what solution you choose or from whom you get your hosting. If you value your data, why not show it?
If you're hosting your own database machine -- not exactly a rare occurance -- and PostgreSQL and MySQL (and SAP DB and Firebird) cost the same, why on Earth would you choose MySQL?
MySQL is NOT easier to install in my experience. So why choose MySQL?
MySQL is less feature-rich. So why choose MySQL?
MySQL is not significantly faster. Is this why you choose MySQL?
MySQL cannot enforce data integrity.
Need I go on? If crappy hosting is MySQL's only ace in the hole, it's in more dire straights than I had originally thought. As far as I see, the biggest reason to stick with MySQL is that if you've spent too much development time with it (written app logic that the database sould've already handled), it would be too much trouble to switch.
on the concurrancy issue. But once again, what if the update fails halfway through? How do you know which records have been updated and which still need updating?
Going to add and drop a temporary column?
With PostgreSQL (and any other ACID database), that same SQL you wrote is atomic. It either works completely or not at all. No special keywords. No extra steps. It just works.
When it's that easy in PostgreSQL, why would you use MySQL? Note that this is a write operation; Don't assume that MySQL is faster.
Non-native speakers and dyslexics aren't excluded from the responsibility of communicating clearly and effectively. It may be more difficult for them, and that fact should be respected. But the skill's overall importance is not dependent upon the writer.
Mistakes happen, and flaming someone for making an honest mistake is inappropriate. Pointing out the mistake hurts no one. It presents the opportunity to avoid the mistake in the future and allow someone to become a more effective writer. If you choose to ignore the correction, that's your prerogative.
As a point of fact, bad spelling and grammar hurt non-native and dyslexic readers much more than native readers. Also, I find that non-native speakers tend to demonstrate much better skills in grammar than most Americans.
(Making sure I stay at least slightly on topic...)
MySQL doesn't care about spelling and grammar as much (No foreign keys, etc.). The lazy like that about it. PostgreSQL can be made a bit more anal retentive about your data.
At the end of the day, if the same person who wrote it into MySQL has to read it back, it works fine. PostgreSQL enforces the rules so that anyone -- not just the original author -- can read it back with perfect comprehension.:)
We used to play this game as a drinking game in college. During melee play, the loser would drink. It became so much more interesting when drunk players would have a Pkunk yell "idiot," "moron," "dork," "worm," etc. at them. Things sometimes got heated and hilarious at the same time.
Now if it were network aware so that two people wouldn't have to huddle onto the same keyboard (or one person with a joystick), I would be a happy man indeed.
Incidentally, the full game had some of the best humor I have ever seen in a game. Truly timeless.
MySQL supporters are like people who believe that the moon landings were a hoax. No matter what contrary information they're confronted with, they still consider MySQL to be the best. It's all just an anti-MySQL conspiracy apparently...
Rational and complete arguments like yours be damned.:(
This is your data. If it's important enough to store, it's important enough to protect. ACID is not optional.
What the MySQL developers conveniently fail to mention is that if you use transaction-aware table types, performance drops dramatically. Under load with multiple concurrent connections, PostgreSQL is pretty close to the speed of MySQL or faster by default and blows MySQL's doors off when MySQL is transaction safe.
Regarding foreign key constraints, see note regarding transactions. And if you are really concerned about fk speed, you don't have to use them in PostgreSQL either.
Record locks hunh? It may surprise you to know that as a user, you don't need to explicitly tell PostgreSQL to lock tables with your queries. Ever. This a relational design issue. This should be handled by your database architect when they layout the table structure, rules, foreign keys, views, and triggers. You do have someone that designs the table structure ahead of time right? Sure you do. But why don't you have to explicitly lock the tables is PostgreSQL? Maybe it's because PostgreSQL is smart enough to know when you need them without your help.
Transactions? Aren't those only for banks and e-commerce? Nope. Let's say you want to update all the users in Slashdot to give all of those loyal geeks one extra karma point. So you select on all users, grab their current karma, add one, and update the record. This has two problems: concurrency and completion. What happens if the user is moderated up or down in between the moment that the record is selected and the moment it's updated? Looks like the user has accidentally been given either (a) an extra point or (b) had a point taken away. Also look at what happens if the database goes down while doing the work (someone kicked a cord), who got the extra point and who didn't? Darn. Wish I had transactions...
So you use the transaction-aware MySQL tables. Wow! Performance has sure dropped out and we have to think about implementation details like locks. I sure wish there was a way to avoid stupid programming mistakes like forgetting a lock. Well...you could use just about any other database out there (including PostgreSQL).
As for stored procedures and triggers, you need not talk about features that aren't here *yet*. Version 4 isn't out of beta yet and you're hanging on a possible v5 feature? While we're at it, let's talk about how multi-master replication will appear in PostgreSQL by then. And didn't you hear? Microsoft's IIS will have its security holes patched up in two years too. Vaporware is vaporware. Believe it when you can download it.
------
Now then, on to personal gripes about MySQL above and beyond the ones I have listed above.
Benchmarks: On MySQL's benchmark page comparing PostgreSQL, they complain that no utilities are available for benchmarking but their own. This is not strictly true. No benchmark can be made because the syntax to the different RDBMSs are so dissimilar that none can be made currently without a strong bias. Stored procedure support, for example, would definitely skew results away from MySQL. But that wouldn't be fair for a benchmarking tool since MySQL doesn't support stored procedures. The same is true of triggers, rules, views, and other such "unimportant" features.
Of course MySQL's benchmark shows MySQL in a good light. They use only the feature set of MySQL to perform the benchmark.
They also mention on the page that they've contacted the PostgreSQL developers for tuning information and methods of improving the benchmark tool. I cannot express loudly enough that THIS IS A LIE! The PostgreSQL mailing list has many instances of developers reporting that they (a) never heard about this "contact" until someone pointed out the MySQL page, and (b) they have been ignored when they've tried to submit tuning techniques and other optimizations. Sounds like some people don't want their benchmarks to give the "wrong" results. Heaven forbid!
As it stands now, the benchmark is a year and a half old. MySQL is on its 53rd patch revision and PostgreSQL is two minor version releases later since this benchmark was released. Weren't you saying something about posting stale information? They still have a page complaining about vacuum bugs and the desire for a newer version of PostgreSQL that fixes the problem....and a year after the bug was fixed, do we see a benchmark update? Nope.
Feature comparisons: another source of info, it talks about the query speed on mostly read only data. Did someone forget to mention that flat files are even faster for mostly read only data?
It states that since MySQL has more users, it must be better than PostgreSQL. Funny how that logic doesn't seem to work for Windows. They use the same logic with the number of books. It wouldn't surprise me if there were more books on DOS than Linux. Does that make DOS better? Does that say anything about the relative quality of those books? No.
MySQL supports more APIs and languages. This is correct unless you want to count stored procedure languages. Oh wait, MySQL doesn't support stored procedures. (Yet! They'll be there in two or three years or so....whatever.)
It then touts MySQL's fine replication facilities. Hello people! How often has slashdot gone down due to database issues? Hardly a poster child for stability or reliability.
According to mysql.com, PostgreSQL doesn't have a unit test/regression test. It makes one wonder if they've even used PostgreSQL.
PostgreSQL is said to be deficient with ODBC. Too bad they couldn't provide any specifics.
I'll relax about the statement that MySQL had more functionality with ALTER TABLE. FYI for readers, that has just changed with PostgreSQL 7.3.
They are correct that PostgreSQL doesn't have MERGE. Instead, they use the SQL92 standard UNION. Does the same thing. And let's not forget about views. What was that!? MySQL has extensive use of non-standard syntax? Any queries you write in MySQL will only have a prayer of working on MySQL? Say it ain't so!
PostgreSQL has had full text search for a while as part of contrib.
I don't even want to start with "MySQL Server is coded from the start to be multi-threaded, while PostgreSQL uses processes." Aside from databases on Windows, this helps whom significantly? A clue folks: Apache HTTPd also uses processes extensively. Pure thread support was only really added for the sake of Windows. This is one of those times where stability and consistency are more important than raw speed. This is your data!
And on and on...
As a final note, I would like everyone to take a trip down memory lane with me and recall that the MySQL dev team didn't see a need for MySQL to have transactions or any other of those "fancy" things at all until a couple of years ago -- when everyone started to realize that MySQL wasn't really twice as fast as PostgreSQL even though MySQL was crippled feature-wise.
The MySQL has so much misleading information (apart from the items that are outright false) on the web site, I wouldn't recommend it to anyone who wants correct information, "current" or otherwise.
The reason is that there is no infrastructure to support such luxuries.
Exactly! They spend their time on the frontier.
So, let us assume, for the moment, that there is "no plausible way to get around" these problems on that part of our planet. (Ignore, for the moment, that the reasons for such great disparities between the "haves" and the "have-nots" of this world is largely due to politics, and not any great technical barriers.) It is currently not possible to have all of the manufacturing of all of the parts for a car, the refinery, etc., etc., in one area. Currently, parts of the world must trade with each other to maintain an industrial standard of living.
I did not mean in perpetuity. I meant as of today. And incidentally, I'm not ignoring the haves versus the have-nots. That's precisely the situation you have in the Firefly universe. If trade is limited due to very large distances and an inability for one party to trade in equity with another, you end up with haves and have-nots.
Now, let us assume that a replicating machine, or "fabricator", is invented. This fabricator can take raw materials and energy, and produce a large selection of items, including all parts necessary to build another fabricator. Someone will take one of these machines to Zimbabwe. The fabricator will produce the parts for another fabricator, which will then be assembled. More and more fabricators will be produced, until eventually, everybody has one, assuming the raw materials are available.
Fabricators to my knowledge don't exist in the Firefly universe so it's a moot point. But I'll stick with you for a while. Let's say fabricators exist. You can't transform one piece of matter to another piece of equal mass. Otherwise it would be the equivalent of a perpetual motion machine. So we accept that there will be loss. This loss would probably be exhibited as radiation or simply lots of heat along with waste mass.
Now let's say that heat/radiation is contained and waste is dumped somewhere (buried in everyone's equivalent of Nevada...I don't know). Someone can drop a boulder in it and get a turkey dinner out of it. A random boulder would probably not have the same constituent elements as a turkey dinner. So we must assume that it reassembles atoms. This sounds conspicuously like it involves fission/fusion. Sounds like a perfect target for terrorists. Normal people wouldn't have one for food as people who hated the Alliance would most definitely steal them so that they could use them as a weapon. Note that I didn't say to make weapons. I mean *as* a weapon. Something that can take in any given mass and manipulate it on the subatomic level would be ridiculously destructive. It would be the galactic version of atomic weaponry and most certainly would be feared and controlled as much as possible. This would entail an absolute minimum number in existance and a ruthless hunting down of anyone who steals one.
If the Alliance had replicators, it would have that much power or presence. If they didn't, they'd sure as shit make sure no one else did.
There are technological as well as political reasons why it won't happen. Because of this, there will be haves and have-nots, some people's lives will be luxurious and other people's lives will be at or below the minimum accepted levels for survival. The ones in the center will have access to most goods and services and will live well. Those on the edges will not have access to most goods and services and won't live well. Hmmm... Sounds like the Firefly universe.
That a "replicator" would solve all problems sounds conspicuously like the misplaced optimism that declared that the Internet would solve all problems. This is humanity we're talking about. Technology doesn't solve problems. People solve problems.
Funny, people for thousands of years found the time to make their own clothing. It's not that crazy a concept. Just because people are "backward" doesn't mean they have forgotten the principles of division of labor.
By all means, take a trip to Iran. Go ahead. Pick up a couple of pairs of the newest Nikes. And there are Gaps everywhere. It's by far the most accessible type of clothing no matter where you go....whatever.
Oh! So you have your own fab lab, machine shop, and produce your own x86 compatible computers? Impressive! And if you moved to Papua New Guinea, because you have learned to use a computer, you could reproduce a modern one quickly and easily? After all, this isn't the 19th century! The knowledge is readily available. At least you could make a 68000 or 8086 right? You could build an Eniac from scratch at least right? The point isn't whether or not it can be build simply and easily. The point is whether or not *you* can build it simply and easily. Never underestimate infrastructure.
With regard to fossil fuels, perhaps not all planets have abundant supplies of fossil fuels. Perhaps oil simply isn't valuable enough anymore to justify transport. You think the FTL drives run on petrol or a hydrogen fuel cell? Why would anyone build a refinery if there was a lack of natural resources, a lack of qualified people, and/or lack a people that could pay for the output and maintenance of that factory.
Small settlements don't need refineries or tractors. Maybe when they get bigger, they'll look into it.
The only reason for humanity to go to other worlds is to exploit resources. Period. There's simply no other reason.
Political reasons? Religious persecution? Evasion of a government agency? Expulsion from your home forcibly? Post-war treaties? Seeking solitude and isolation?
What part of "outside the galactic core" didn't you understand? I'm quite certain the technology you describe exists in the Firefly universe. That doesn't mean that everyone has access to it. Just because advanced technology brought them to the planet doesn't mean they have equal access to that technology.
That would be like all of those Irish and Italian immigrants from the 1800s and early 1900s. Just because they were able to scrap together sufficient funds to book passage to America on a steamliner doesn't necessarily mean that they suddenly gain the ability to build a steamliner.
If an American travels to Zimbabwe, will they automatically have a car, grocery stores, and gas stations like they had in the U.S. made available when they get there? Why not? Can you think of a plausible way to get around that? If so, many people in the world would love to hear about it.
I challenge you to demonstrate a moment on the show...
I can't do that. I got bored instantly. What I say is my personal opinion, however incomplete it is.
Ever heard the saying, "You can't judge a book by its cover?" Name one show where *every* episode in its first season was absolutely the best you have ever seen?
If the people on the planet are poor and basically just surviving, how can the costs of transport for that fuel on a recurring basis be handled?
Light, wind, water, steam, geothermal, nuclear, orbital mirrors/microwave... they are supposed to be well aware of technology. Is it too much to assume that in 500 years from now a pocket battery can be more powerful than 1000 horses? Can't they buy a powerplant from an old spaceship, at very least? They aren't even *trying*. I don't like when people are not trying. Then they deserve what they get.
The "best and brightest" are at the galactic core. This documents everyone who was forgotten and discarded. Also it shows the people who didn't want to be under the thumb of a galactic empire. When you attempt to live out of the range of a dominating power, you tend to be remote enough so as to limit the resources you have available. You can't easily get some of the most recent processors when you live in the middle of the Sahara. Does this make everyone who lives in the Sahara lazy and backward because they don't build a fab lab? You need to travel more my friend.
Now I know why all farmers in USA switched to horses, away from their tractors and harvesters:-) The *real* fact of the matter is that horses get sick, injured, want to eat, and they can drag only one plow blade; a tractor can manage tens of blades, can be repaired (or replaced), and can be refueled in a moment. That's how humans ended up with enough food for everyone. Industrialized nations - that's the name:-)
And tractors break down. When you are far enough from supply lines, replacement parts just can't get there in time for the harvest. With a small enough population, a few horses and plows are more than enough.
Those people are more than aliens to me, they are totally incomprehensible.
Yes! Exactly! They didn't include aliens because people can be sufficiently alien. If the aliens are completely comprehensible (and yes, I'm taking pot shots at B5 and Star Trek here), they aren't really aliens. Do you honestly believe that life out there is going to be like the Centauri? That, like in the case of G'Kar, they'll be just like humans in form and reactions but with slightly different pain thresholds and emotions? Do you believe that everyone in an alien race will have basically uniform beliefs and political goals? Kosh shmosh... He stopped short of saying things, tightened up his helmet sphincter, and everyone lauds him as complex and wonderfully mysterious.
Why hasn't everyone noticed the Babylon 5 was populated with humans who have the customs and beliefs of the U.S. and Western Europe (less so the latter)? Oh yeah, I forgot; The U.S. is the best there is and all people in the future will be emulating folks from the Society for Creative Anachronism.
Thank goodness for a show like Firefly. This IS hard sci-fi. It's an honest look at life in the future instead of a future we'd like to see. Examining people that we don't fully understand is the whole point. If all you are doing is watching people that you understand, you're just treading water and never moving forward.
The tech should never be the focus in a realistic story. Even "Snowcrash" spent more time on the characters and how they reacted to one another than on the tech around them. The tech around them only served to explain the people. Take "Ringworld": If you were born there, would you constantly marvel at it? No. It would be all that you ever knew. It would be like everyone on the planet constantly talking about the moon. Sure people talk about it, write about it, and sing about it, but not on a daily basis and not in detail each time. What would be the point? After we discuss its composition, its size, its distance from us, how people act wonky when it's full, etc., why would we need to keep talking about it on an hourly basis unless we learned something new about the moon?
After hearing the line, "...that's why I never kiss them on the mouth," I was hooked. If you don't remember the line, go back and watch the episodes again.
Totally deadpan. Perfect comedic timing by the entire cast. You're right, not one actor should quit his or her day job; This IS their day job.
In how many episodes did they tend cows? I only remember one and it was only in the tail end of the episode (the last minute or two). You're overreacting.
You want to know all of the details? Do you care about the details of a street light? How about the details of your car's air conditioner? How about the portable space heater? How about the fabric blend of your sweater? These are all things that four hundred years ago would have been absolutely shocking and exciting. Light without fire!?! Wow! But in reality, most people (even geeks) just take the light on the streets for granted, think air-conditioner == freon + compressor that keeps you cool, a heater is just an electrical resistor that keeps you warm, and the sweater is 30% cotton and also helps keep you warm. Would you watch a show where they examined the tech behind a streetlight for the whole episode, would you find that terribly stimulating? I wouldn't.
Now remember that Serenity is a simple, not very flashy, old, stand-by workhorse freighter. Are there some details? Sure. The mechanic is always elbow-deep in the details. She's constantly talking about tweaking this and that and the other. But there's a minimum of blinking lights and what widget X or Y gets them faster than light doesn't matter. Let's say they tell you the blow by blow schematics for the faster-than-light drive. Then what? It can't drive a show. It's pointless. FTL doesn't exist and any "explanation" of how it works is useless technobabble that appeals to folks who can't grasp personal interaction.
You speak of Picard's ability to reason his way out of a situation. I challenge you to demonstrate a moment on the show where the captain of Serenity was given a simple problem or solved a problem in an unreasonable fashion.
Tractors require fuel. Constantly replenished sources of fuel. Fuel on any non-trivial scale is dependant upon refineries. You don't just hook up a gas tank to a natural oil reserve. So, assuming that there is a ready supply of fossil fuels, they must also build and maintain a refinery. Otherwise they must get their fuel supplies from off-world. They constantly talk about trips from planet to planet taking from days to weeks. If the people on the planet are poor and basically just surviving, how can the costs of transport for that fuel on a recurring basis be handled?
The fact of the matter is that horses are cheaper to raise and maintain than a tractor is. And a horse generates fertilizer. A tractor just spits out fumes.
Right now, you can go just anywhere on the planet within one day. But imagine it took three weeks to get to Japan from Brazil. Supply lines would be much more expensive, communication would be much more limited, casual trips would be rare, and the one without as many natural resources would be reduced to poverty and meager subsistence.
This is why I like Firefly. No rubber ears. No green people. No transporter accidents. Just people trying to make a life for themselves -- and they happen to be in a very plausible future.
Human interaction is and always will be more important than psuedo-tech minutia just as family, friends, my girlfriend, and my community are all more important to me than my computer. If your tech is more important to you than these things, I pity you. I really do.
microkernels were the rage. HURD answered the call and started work. Now, almost 20 years later, MIT pulls the rug out with exokernels. So will we wait until 2020 to get a working model of that too?
God bless HURD for trying to advance the state of the art and improve upon the dated UNIX model, but sheesh! I wish HURD were ready for prime time. I really do. But a working model with caveats (Linux, OSX, *BSD) will always be better than a better model that's mostly theoretical in the real world.
That said, no one's paying the HURD developers. If it gos their nads, have at it. RMS needs to relax and realize that it is little more than a research experiment and not the second coming.
(never mind that anyone who knows what + actually does there will tell you not to use it anyhow because it's slow...)
String foo = "This " + "is " + "a " + "segmented " + "string."; and String foo = "This is a segmented string.";
are equivalent in recent (the last few years) Java compilers. Like any good compiler technology, better choices are made over time. It's not a blanket performance dog.
It's also useful for simple cases like:
for (int i=0; i<5; ++i){
String foo = "String" + i; // Do something with it }
The only real case where you should avoid it is where you are concatenating multiple variables whose contents can only been found at runtime:
Date d = new Date(); int x = 10; String foo = "String" + x + ": " + d;
In cases like this, you should be using StringBuffers explicitly. Then again, this is common knowledge for Java programmers. Might I suggest the book Java Performance Tuning to help with your speed issues in Java. I consider it in the same league as Meyer's "Effective C++" series for avoiding common language pitfalls. It talks about common usage of containers, string manipulation, threads, and other nice tidbits.
As for numerics, use the right tool for the job. In many cases, it isn't Java. But then, neither is C.
I have often wondered why Java programmers can't seem to indent their code properly. I've even had trouble finding a good program to (re-)indent Java code. The main reason why I'd like to see programmers stick to 80 columns (or 120 even? please??) is because sometimes I might want to PRINT SOMETHING OUT.
Define "properly." C and C++ programmers are hardly a breed to talk. As for code beautifiers, try this one. I've never used it as I'm fine with my and my team's formatting habits, but it was the first link in a Google search for me.:-/
Try searching for 'Java "code beatifier"'. Worked for me.
As for printing, every printer I've used in the last ten years handled more than 80 characters per column. Mmmmm... Progress...
However I realize that when you have code that looks like
it might be difficult to indent without introducing awkward spaces or unnecessary temporary variables, and you wouldn't want to disrupt the straightforward purity of the Java code itself!
Is this what you were talking about? Or were you talking about the "getInstance()" static method commonly found in the Java API. It is of course for instantiation with singletons and the like just as it is in C++. I'm surprised this is new for you. In addition, what you see is what you get. It is actually harder to have object instantiations happen without noticing in Java than it is in C++. Incidentally, Java compilers make the same bytecode for this as for your example, and mine is (a) easier to read and (b) prints just fine in 80 columns. And no, I don't advocate 10,000 character lines. I also don't think the 80 column hard limit is necessary anymore either.
And I said nothing about enforcing specific editors or IDEs. Please point out where I did. All I said was that specifically console-based vi and emacs were at issue. Actually, now that I think of it, you can usually stretch console windows out. Or is 80 columns the one true width? Quick quiz: Why is 80 columns such a magic number? Answer: Because that's how many characters fix on the terminal screens and early line printer pattens. Move on.
And while we're on the topic of printing stuff out, you know all of those automatic documentation generators for C and C++? They weren't quite so popular until javadoc came out were they? Show me one for C and C++ that predates Java. Go on. I dare you.
For what it's worth, I have used gvim, vim, emacs, xemacs, moleskine, textpad, BBEdit, Visual Studio, JBuilder, and many others for development. I have even written Java in notepad although I don't recommend the experience to others.
The private protected access was removed from the language because it violated a nesting relationship that was valuable. You can list the existing accesses in an ordered relationship from least to most accessible as follows:
private
package (i.e., when no access modifier is specified)
protected
public
The "private protected" access does not fit cleanly into that ordered list. This ordering capability keeps certain parts of the language simple, and is therefore valuable.
The assumption is that packages contain "related" code, and so encapsulation within a package is less critical. If you throw code randomly into a package you will end up with unusual exposures (although with inner classes this can be controlled better), but if it hurts, don't do that.
Take that as you will. I personally don't have a problem with it and it hasn't been a real impediment to my code. Why you have objects in the same package that have no usage guidelines, I don't know. There are a lot of people who agree with you, so I'll leave that as a matter of opinion.
So directories are an issue eh? You are aware that it's possible to make classes without subdirectories right? If you don't specify a package, they get put into the default package which is at the root level (of your source tree). As opposed to C and C++, if I have a group of source files in a directory, I know for a fact that they are related to one another (in the same package). In C/C++, I am at the whim of the coder as to what namespace the classes are in (C++ only) and also into which directory s/he saw fit to drop them.
If you have twenty directories for a small project in Java, you've got bigger issues than the directory structure; You're project organization is completely screwed. If you've only got one, and the path is com/mycompany/, I hardly think that is cause for panic and excessive teeth gnashing.
When using a class, because of the package designation, I know exactly where it exists on the source tree if I need to fix something. Makes things simpler for the classloader too and the expectations the developer has of that classloader.
Even iostreams in C++ are better here--you can just use cin and cout for I/O; convenient, isn't it?
Approaching the length of your typical print statement in C. No shortcuts possible in Java indeed.
It has a lot of implementations of different, handy algorithms, that can all do the same tasks. And this has a high learning curve associated with it, I'd say even higher than learning the STL in C++. Since you didn't actually write this code yourself, you have to know (i.e., read the documentation or benchmark the implementation or both) how fast each operation is for a given task in each implementation to pick the right one. Also, it helps if you know what it does to your data along the way. For instance, the fact that Strings are UNICODE in Java might explain why a simple change can double your memory requirements.
Harder than the STL? Ha ha! You're kidding right? I love the STL dearly but to say that it's easier to use and more intrinsically intitive than the Collections package is silly. While I wish Java had generics so the Collections would have fewer casts in order to use, it's still easier to use.
As far as relative efficiency of algorithms, are you complaining about the fact that you're not diving into the source? You are aware that there are STL implementations out there that only give you headers and library against which to link?
That said, are you talking about the constant factor to each of the containers or the relative cost of using a LinkedList as opposed to a HashMap? Go read a CS algorithms book. These aren't that tough. Also, there is nothing that says that one JVM will be implemented exactly the same as another (same as the STL). The only thing guaranteed is the API. Whether you are using the STL or Java Collections, you still need to test and benchmark. If you need help deciding which situations call for a List instead of a Set, C and C++ aren't gonna bail you out either. I'm assuming that this is not the case as your comments to this point have been well informed.
As for strings being unicode, I fail to see why that's a mark against Java. I18n and l10n aren't afterthoughts as they are in C and C++; They are designed in. Codepages, character encodings, etc. are things I don't much care about. But thanks to Java, I don't have to. It's a solved problem. Programs today need to be made for more than just English speakers and Java makes that easy. Hell yes it has built it unicode support! Thank god they did the right thing!
Well, you can draw lines, and boxes and circles in Java... but not pixels. There's no drawing primitive for a pixel. I think you could convert from one type of graphics object to another (that has pixels and nothing else) but only at a hefty penalty in speed and memory usage, and obviously if you wanted both, converting between the two would be highly silly.
I like Perl quite a bit; it has a lot of higher-level language features, but it doesn't impose any bizarre semantics on me, or hide any features from me.
Perl? No bizarre semantics? Please tell you are joking. Next you're going to tell me that OO programming in Perl is clear and intuitive.
And I never said anything about a networked GUI. I personally love the Swing API but it is far too big and slow to use for any UI of significant size -- something Sun really needs to work on. Networking and database work however is my bread and butter. C has nothing as clean, elegant, mature, and easy to use as Java's networking and database layers. Period.
As for things to "make it stop," give me another example. Maybe there's something in the API you aren't familiar with that could make your life easier.
Of course no is stopping you from using a preprocessor but this is not true operator overloading when using a preprocessor macro. One of the primary features of operator overloading in C++ (which is the language from which I assume you get your love of the practice) is type safety. There's more to it in practice than syntax magic.
You lose type safety when you invoke a preprocessor as you are no longer under the auspices of the syntax validator.
And as a point of history, operator overloading was ommited because when Gosling et al actually did the research, more bugs were introduced as a result of operator overloading than were reduced by concision. It wasn't a personal grudge or offhand bias. There were many arguments, comparisons, and trials made before the final decision to leave them out.
If you feel that you can handle it and -- more important -- that everyone that will ever touch your code and APIs will make better code because of it, by all means have at it.
As far as the 80 columns difficulties, quit blaming the language and get a better editor -- you know, the kind that can fit more than 80 columns per row or intelligently wrap the lines. Why anyone codes with console-based vi or emacs these days, I will never understand.
i.e., your average C compiler will behave much more predictably than your average Java compiler, and if you screw something up in Assembler, rest assured, it's probably your fault.
This is FUD. There is far more consistency in Java compilers than C compilers in the real world. The difference in output of C compilers is far greater than the difference in output of Java bytecodes. As far as debugging system libraries and the language, while in my years of Java programming I have come across bugs in the JVM implementation and even once(!!!) I came across a compiler bug. I was able to work around the problem in all cases. This is impressive considering that I have done Java development on OS/2, Windows, Linux, and Solaris. I have had far more headaches from C compilers (yes, I code in C as well -- learned it years before Java came along) when bouncing from platform to platform than I have ever had from Java bugs. Come to think of it, I've even come up against a C library bug or two. To suggest that higher level languages are somehow tainted in this respect and C or Assembly is the cleaner answer is laughable.
How are iostreams more portable than stdio.h? Do you mean portable in that it hides more implementation details, or portable in that it runs on more platforms? I'll agree with you on the former, although that isn't always a good thing, but never on the latter.:)
I misspoke. My intention was to say that iostreams are more portable than an Assembly solution and is more flexible than either. You are correct.
As for C's #ifdef facility, I like it a lot. In fact, I sincerely wish Java had some form of macro preprocessing, because occasionally, I need it. I'm sick of Java programmers whining about how "macros are confusing"--if they lack the intelligence to run the source through the preprocessor in the first place, then... it might explain a lot about their Java coding.
Why? Why does Java need a hack that -- irrespective of the language syntax -- makes drop in text segments like a preprocessor? Do you need it for plugging in a native implementation when available and a Java one when not? Or conditional compilation of some functionality? Java doesn't need a preprocessor for that. You can do it in Java and still take advantage of the Java syntax validators -- which is crippled by the use of a prepreprocessor. It isn't about macros being confusing (which would be a #define and not an #ifdef); It's about them being unnecessary and in this case harmful. Since we're talking about macros and Java, what good would they do? If I write a sufficiently small or simple method/function, the Java compiler will inline it for me. For that matter, so will the optimizing C compiler. #define is of limited use today.
if I needed to implement some sort of portable, network-aware program in C, I'd probably look for some sort of portable, network-aware LIBRARY that's already ported to the intended platforms.
And C is one of the only languages left that DOESN'T have a standard, portable networking API. Java, Python and Perl have all had one for years. Java recently gained a secondary API for non-blocking I/O that takes care of a lot of the speed issues plaguing network apps in the past. And it's supported by all current JVMs. And any Java programmer can look up how to use it in any recent Java tutorial or quick reference.
You want a library? So do I. Those libraries are called java.net, java.nio, and IO::Socket. How are they implemented? Probably in C and/or some Assembly. Do I care? Not if the API is stable and the speed fits my minimum requirements for a job (and they almost always do).
Nothing wrong with "testing out an implementation in a higher-level language" eh? What happens when that implementation is plenty fast and/or memory efficient enough to do the job. Why recode in C?
Java is crippled how? By its standard GUI libraries? How can you compare that to C's lack of any standard GUI library? As for the rest of Java, given the non-blocking I/O libraries, how is Java substantially slower? By all means, give me an example larger and more complex than "Hello World."
Study after study that I have read has demonstrated that algorithm makes far more difference than language in speed contests. The worst problems I have seen in Java code were when arrogant C programmers tried to code it like C and then whine about how it won't work right for them. I have seen Java code where people have made classes called Get_Channels and made instances of those objects in order to call an instance method instead of just making a static method and calling it off of the class definition. This is why Java gets a reputation of slow in the last few years, not because of some inherent limitation of the platform. As far as naming conventions, thank god there's a standard. Any Java programmer who follows the naming standard is pretty well covered that some other programmer will recognize and understand his constructs with a minumum of time and effort. It isn't until C programmers come in with their need to call classes get_channels that things go haywire.
Scope problems? What scope problems? Can you be more specific because I'm not even sure what you have a problem with here.
you'll be banging your head against that higher-level language a lot anyhow, and likely for different reasons, sometimes completely unrelated to your program. After doing that for a while, I'd much rather know I'm shooting my own foot in C or Assembler instead of having my shot foot anonymously instantiated by some cryptic and unnecessary higher-level language 'feature'.
Yes, and people never bang their head against C or Assembly. I have had many more problems with the limitations of C in the past seven years than I have ever had with Java or Perl. Sometimes C fits the bill. When speed is truly an issue and every little cycle counts, sometimes C (or more often C++) comes to my rescue. For almost every other problem imaginable, C is my problem, not my solution.
Java and C++ have very well defined behavior for object instantiation. For someone who complains that Java programmers just aren't smart enough to handle preprocessor macros, you seem awfully dismissive of your own ability to see what happens in a higher level language when I and others barely even blink.
Only small and simple processing platforms are good candidates for an all-Assembly solution nowadays.
Show me someone who can effectively handle all of the ins and outs of modern Athlons, P4s, Xeons, and G4s, and I'll show you someone who's smart enough to spend their talents on writing compilers instead of individual applications.
I'm sorry, but normal humans cannot beat optimizing compilers on modern processors. Coding to the metal on the high end isn't a viable option anymore.
...and of course there's the often overlooked facet of this which is that often times, for a given load and/or userbase, the higher level abstraction is more than fast enough to do the job.
If your current implementation can potentially handle ten times your current requirements, there's no need to rush into the lower levels.
On the contrary, I believe it is you who is being clever or naive. Embedded programming, device drivers, etc. account for maybe one tenth of one percent of all source code written today. I fear that I may even be overestimating that number.
For smaller projects, using low-level facilites can get you big gains. Even for larger projects, optimizing the hotspots in code with low-level constructs from within a high-level framework can show great results. In fact, this is how many high-level languages are implemented.
However, while the human mind is the best code optimizer out there, it is also the most frail and inconsistent. While you can make very tight routines in Assembly on a good day, what happens when you are sleep deprived, up against a hard deadline, and stuck trying to figure out why the program keeps crashing? You know, in the real world. Compilers, while maybe not producing the absolute best code for a particular instance are very consistent about producing pretty damned good binary output billions of times 24 hours a day/7 days a week.
Code production time is also a factor. If you are working on a project that's a few tens of thousand lines of code, Assembly language -- with a competant code author behind it -- can show amazing results over the Python version (for example). But the Python version was finished and debugged days or weeks before the Assembly language version was code complete.
Your C++ example is a bit misleading though. Chances are that you were looking at the assembler's output of iostreams. iostreams implementations, while getting better, are not anywhere near the small size of stdio.h or raw assembly output to the console. Then again, iostreams is far more portable and flexible than either of the previous two. It's a tradeoff, just like everything else in the world: convenience/specificity. Take out iostreams and replace it with a home-grown implementation or stdio.h and you'll notice some "tighter" code.
In addition, compilers keep getting better. A good optimizing compiler is nothing to sneeze at nowadays. As a whole, compilers are measurably better than five years ago, and worlds better than they were fifteen years ago. Some of the best human minds are writing general code optimizers out there today.
Add in the final tidbit that assembly isn't portable. If you are targeting a particular embedded platform with strict space requirements -- a small minority of all development projects out there -- C with Assembly fits the bill. As soon as your platform changes because a vendor went under or requirements demand a faster processor or whatever, all of that Assembly is basically useless. You might be able to use some of the same general algorithms, but you're basically talking about a rewrite. Then again, if you wrote some Assembly code that is more generic, it's not heavily optimized is it? It also doesn't work too well if your target includes multiple platforms from the start.
Want to write a portable, network-aware program? If you use C, be sure to eat your Wheaties in the morning, because you're gonna have to spend a while typing in all of the #ifdefs. But you'll just make it clean and compile for Linux, FreeBSD, Solaris right? What if Windows or BeOS are requirements for your project? #ifdef #ifdef #ifdef
OR!
You could write it in Perl, Python, Java, or any of the other "dirty" high level languages and worry about those clock cycles after you've profiled it and seen the need. This of course doesn't remove the need for proper design before you start, but we were talking about implementation.
Remember: Premature optimization is the root of all evil.
Slashdot Mirror
I've just learned something new. Thanks.
The hybrid threading/forking MPM is used by UNIX (mostly Solaris and Irix), but the pure threading MPM is basically just for Windows. It makes Apache much faster on Windows at the expense of robustness -- if the one process goes down, down goes the whole shebang.
But MySQL isn't libre software on Windows is it? It wasn't the last time I checked.
So on Windows you have the choice of an installer (MySQL) or open source (PostgreSQL).
Did I miss something?
Simpler to install? It comes packaged by default in RedHat. For Debian, it's apt-get install postgresql. For a source install, it's ./configure;make;make install. Please explain to me how MySQL is easier.
...or rules, triggers, explicit transactions, or any of the other things that PostgreSQL can do that MySQL can't. It's not like PostgreSQL mandates the use of every feature.
Simpler? When you need to get a job done, you either have a simple database or a simple app. The amount of logic is the same.
If Joe Newbie doesn't need views, Joe Newbie doesn't have to use views.
On the other hand, Joe Newbie shouldn't need to learn about explicit locks, database integrity issues, workarounds because a feature isn't there, etc.
pg_dump is indeed required whenever a minor or major version change happens. That happens once a year or so. It's not like it happens once a week. And of course, that assumes that you upgrade according to PostgreSQL's release schedule. Why you would do that, I have no idea. More likely, you are upgrading/replacing the database box so you would have to dump the data no matter what software you were using.
If the version and hardware configuration are working well, why would you change anything (other than apply patches) by default?
As far as cheap hosting, that's fine. If the hosting company I have to work with has IIS, I'll be using asp won't I? An abundant option isn't necessarily better. It's just more abundant. Going from computer to computer, you're more likely to find Windows 98 than any other operating system. Does that mean it's better? Indeed, sometimes you have to use suboptimal tools to get the job done. This doesn't mean that you have to seek those suboptimal tools out.
If your data doesn't matter as much to you, it doesn't much matter what solution you choose or from whom you get your hosting. If you value your data, why not show it?
If you're hosting your own database machine -- not exactly a rare occurance -- and PostgreSQL and MySQL (and SAP DB and Firebird) cost the same, why on Earth would you choose MySQL?
MySQL is NOT easier to install in my experience. So why choose MySQL?
MySQL is less feature-rich. So why choose MySQL?
MySQL is not significantly faster. Is this why you choose MySQL?
MySQL cannot enforce data integrity.
Need I go on? If crappy hosting is MySQL's only ace in the hole, it's in more dire straights than I had originally thought. As far as I see, the biggest reason to stick with MySQL is that if you've spent too much development time with it (written app logic that the database sould've already handled), it would be too much trouble to switch.
on the concurrancy issue. But once again, what if the update fails halfway through? How do you know which records have been updated and which still need updating?
Going to add and drop a temporary column?
With PostgreSQL (and any other ACID database), that same SQL you wrote is atomic. It either works completely or not at all. No special keywords. No extra steps. It just works.
When it's that easy in PostgreSQL, why would you use MySQL? Note that this is a write operation; Don't assume that MySQL is faster.
...and it shows. It was a steaming pile. All of the bad graphics, none of the charm.
Non-native speakers and dyslexics aren't excluded from the responsibility of communicating clearly and effectively. It may be more difficult for them, and that fact should be respected. But the skill's overall importance is not dependent upon the writer.
:)
Mistakes happen, and flaming someone for making an honest mistake is inappropriate. Pointing out the mistake hurts no one. It presents the opportunity to avoid the mistake in the future and allow someone to become a more effective writer. If you choose to ignore the correction, that's your prerogative.
As a point of fact, bad spelling and grammar hurt non-native and dyslexic readers much more than native readers. Also, I find that non-native speakers tend to demonstrate much better skills in grammar than most Americans.
(Making sure I stay at least slightly on topic...)
MySQL doesn't care about spelling and grammar as much (No foreign keys, etc.). The lazy like that about it. PostgreSQL can be made a bit more anal retentive about your data.
At the end of the day, if the same person who wrote it into MySQL has to read it back, it works fine. PostgreSQL enforces the rules so that anyone -- not just the original author -- can read it back with perfect comprehension.
Schweeeeeeeeeeeeeeeeeeeeeet!!!
We used to play this game as a drinking game in college. During melee play, the loser would drink. It became so much more interesting when drunk players would have a Pkunk yell "idiot," "moron," "dork," "worm," etc. at them. Things sometimes got heated and hilarious at the same time.
Now if it were network aware so that two people wouldn't have to huddle onto the same keyboard (or one person with a joystick), I would be a happy man indeed.
Incidentally, the full game had some of the best humor I have ever seen in a game. Truly timeless.
It's too bad SC3 sucked so much.
MySQL supporters are like people who believe that the moon landings were a hoax. No matter what contrary information they're confronted with, they still consider MySQL to be the best. It's all just an anti-MySQL conspiracy apparently...
:(
Rational and complete arguments like yours be damned.
This is your data. If it's important enough to store, it's important enough to protect. ACID is not optional.
Let's go down the list:
...and a year after the bug was fixed, do we see a benchmark update? Nope.
...whatever.)
What the MySQL developers conveniently fail to mention is that if you use transaction-aware table types, performance drops dramatically. Under load with multiple concurrent connections, PostgreSQL is pretty close to the speed of MySQL or faster by default and blows MySQL's doors off when MySQL is transaction safe.
Regarding foreign key constraints, see note regarding transactions. And if you are really concerned about fk speed, you don't have to use them in PostgreSQL either.
Record locks hunh? It may surprise you to know that as a user, you don't need to explicitly tell PostgreSQL to lock tables with your queries. Ever. This a relational design issue. This should be handled by your database architect when they layout the table structure, rules, foreign keys, views, and triggers. You do have someone that designs the table structure ahead of time right? Sure you do. But why don't you have to explicitly lock the tables is PostgreSQL?
Maybe it's because PostgreSQL is smart enough to know when you need them without your help.
Transactions? Aren't those only for banks and e-commerce? Nope. Let's say you want to update all the users in Slashdot to give all of those loyal geeks one extra karma point. So you select on all users, grab their current karma, add one, and update the record. This has two problems: concurrency and completion. What happens if the user is moderated up or down in between the moment that the record is selected and the moment it's updated? Looks like the user has accidentally been given either (a) an extra point or (b) had a point taken away. Also look at what happens if the database goes down while doing the work (someone kicked a cord), who got the extra point and who didn't? Darn. Wish I had transactions...
So you use the transaction-aware MySQL tables. Wow! Performance has sure dropped out and we have to think about implementation details like locks. I sure wish there was a way to avoid stupid programming mistakes like forgetting a lock. Well...you could use just about any other database out there (including PostgreSQL).
As for stored procedures and triggers, you need not talk about features that aren't here *yet*. Version 4 isn't out of beta yet and you're hanging on a possible v5 feature? While we're at it, let's talk about how multi-master replication will appear in PostgreSQL by then. And didn't you hear? Microsoft's IIS will have its security holes patched up in two years too. Vaporware is vaporware. Believe it when you can download it.
------
Now then, on to personal gripes about MySQL above and beyond the ones I have listed above.
Benchmarks: On MySQL's benchmark page comparing PostgreSQL, they complain that no utilities are available for benchmarking but their own. This is not strictly true. No benchmark can be made because the syntax to the different RDBMSs are so dissimilar that none can be made currently without a strong bias. Stored procedure support, for example, would definitely skew results away from MySQL. But that wouldn't be fair for a benchmarking tool since MySQL doesn't support stored procedures. The same is true of triggers, rules, views, and other such "unimportant" features.
Of course MySQL's benchmark shows MySQL in a good light. They use only the feature set of MySQL to perform the benchmark.
They also mention on the page that they've contacted the PostgreSQL developers for tuning information and methods of improving the benchmark tool. I cannot express loudly enough that THIS IS A LIE! The PostgreSQL mailing list has many instances of developers reporting that they (a) never heard about this "contact" until someone pointed out the MySQL page, and (b) they have been ignored when they've tried to submit tuning techniques and other optimizations. Sounds like some people don't want their benchmarks to give the "wrong" results. Heaven forbid!
As it stands now, the benchmark is a year and a half old. MySQL is on its 53rd patch revision and PostgreSQL is two minor version releases later since this benchmark was released. Weren't you saying something about posting stale information? They still have a page complaining about vacuum bugs and the desire for a newer version of PostgreSQL that fixes the problem.
Feature comparisons: another source of info, it talks about the query speed on mostly read only data. Did someone forget to mention that flat files are even faster for mostly read only data?
It states that since MySQL has more users, it must be better than PostgreSQL. Funny how that logic doesn't seem to work for Windows. They use the same logic with the number of books. It wouldn't surprise me if there were more books on DOS than Linux. Does that make DOS better? Does that say anything about the relative quality of those books? No.
MySQL supports more APIs and languages. This is correct unless you want to count stored procedure languages. Oh wait, MySQL doesn't support stored procedures. (Yet! They'll be there in two or three years or so.
It then touts MySQL's fine replication facilities. Hello people! How often has slashdot gone down due to database issues? Hardly a poster child for stability or reliability.
According to mysql.com, PostgreSQL doesn't have a unit test/regression test. It makes one wonder if they've even used PostgreSQL.
PostgreSQL is said to be deficient with ODBC. Too bad they couldn't provide any specifics.
I'll relax about the statement that MySQL had more functionality with ALTER TABLE. FYI for readers, that has just changed with PostgreSQL 7.3.
They are correct that PostgreSQL doesn't have MERGE. Instead, they use the SQL92 standard UNION. Does the same thing. And let's not forget about views. What was that!? MySQL has extensive use of non-standard syntax? Any queries you write in MySQL will only have a prayer of working on MySQL? Say it ain't so!
PostgreSQL has had full text search for a while as part of contrib.
I don't even want to start with "MySQL Server is coded from the start to be multi-threaded, while PostgreSQL uses processes." Aside from databases on Windows, this helps whom significantly? A clue folks: Apache HTTPd also uses processes extensively. Pure thread support was only really added for the sake of Windows. This is one of those times where stability and consistency are more important than raw speed. This is your data!
And on and on...
As a final note, I would like everyone to take a trip down memory lane with me and recall that the MySQL dev team didn't see a need for MySQL to have transactions or any other of those "fancy" things at all until a couple of years ago -- when everyone started to realize that MySQL wasn't really twice as fast as PostgreSQL even though MySQL was crippled feature-wise.
The MySQL has so much misleading information (apart from the items that are outright false) on the web site, I wouldn't recommend it to anyone who wants correct information, "current" or otherwise.
Exactly! They spend their time on the frontier.
I did not mean in perpetuity. I meant as of today. And incidentally, I'm not ignoring the haves versus the have-nots. That's precisely the situation you have in the Firefly universe. If trade is limited due to very large distances and an inability for one party to trade in equity with another, you end up with haves and have-nots.
Fabricators to my knowledge don't exist in the Firefly universe so it's a moot point. But I'll stick with you for a while. Let's say fabricators exist. You can't transform one piece of matter to another piece of equal mass. Otherwise it would be the equivalent of a perpetual motion machine. So we accept that there will be loss. This loss would probably be exhibited as radiation or simply lots of heat along with waste mass.
Now let's say that heat/radiation is contained and waste is dumped somewhere (buried in everyone's equivalent of Nevada...I don't know). Someone can drop a boulder in it and get a turkey dinner out of it. A random boulder would probably not have the same constituent elements as a turkey dinner. So we must assume that it reassembles atoms. This sounds conspicuously like it involves fission/fusion. Sounds like a perfect target for terrorists. Normal people wouldn't have one for food as people who hated the Alliance would most definitely steal them so that they could use them as a weapon. Note that I didn't say to make weapons. I mean *as* a weapon. Something that can take in any given mass and manipulate it on the subatomic level would be ridiculously destructive. It would be the galactic version of atomic weaponry and most certainly would be feared and controlled as much as possible. This would entail an absolute minimum number in existance and a ruthless hunting down of anyone who steals one.
If the Alliance had replicators, it would have that much power or presence. If they didn't, they'd sure as shit make sure no one else did.
There are technological as well as political reasons why it won't happen. Because of this, there will be haves and have-nots, some people's lives will be luxurious and other people's lives will be at or below the minimum accepted levels for survival. The ones in the center will have access to most goods and services and will live well. Those on the edges will not have access to most goods and services and won't live well. Hmmm... Sounds like the Firefly universe.
That a "replicator" would solve all problems sounds conspicuously like the misplaced optimism that declared that the Internet would solve all problems. This is humanity we're talking about. Technology doesn't solve problems. People solve problems.
By all means, take a trip to Iran. Go ahead. Pick up a couple of pairs of the newest Nikes. And there are Gaps everywhere. It's by far the most accessible type of clothing no matter where you go.
Oh! So you have your own fab lab, machine shop, and produce your own x86 compatible computers? Impressive! And if you moved to Papua New Guinea, because you have learned to use a computer, you could reproduce a modern one quickly and easily? After all, this isn't the 19th century! The knowledge is readily available. At least you could make a 68000 or 8086 right? You could build an Eniac from scratch at least right? The point isn't whether or not it can be build simply and easily. The point is whether or not *you* can build it simply and easily. Never underestimate infrastructure.
With regard to fossil fuels, perhaps not all planets have abundant supplies of fossil fuels. Perhaps oil simply isn't valuable enough anymore to justify transport. You think the FTL drives run on petrol or a hydrogen fuel cell? Why would anyone build a refinery if there was a lack of natural resources, a lack of qualified people, and/or lack a people that could pay for the output and maintenance of that factory.
Small settlements don't need refineries or tractors. Maybe when they get bigger, they'll look into it.
Political reasons? Religious persecution? Evasion of a government agency? Expulsion from your home forcibly? Post-war treaties? Seeking solitude and isolation?
There are other reasons.
What part of "outside the galactic core" didn't you understand? I'm quite certain the technology you describe exists in the Firefly universe. That doesn't mean that everyone has access to it. Just because advanced technology brought them to the planet doesn't mean they have equal access to that technology.
That would be like all of those Irish and Italian immigrants from the 1800s and early 1900s. Just because they were able to scrap together sufficient funds to book passage to America on a steamliner doesn't necessarily mean that they suddenly gain the ability to build a steamliner.
If an American travels to Zimbabwe, will they automatically have a car, grocery stores, and gas stations like they had in the U.S. made available when they get there? Why not? Can you think of a plausible way to get around that? If so, many people in the world would love to hear about it.
Ever heard the saying, "You can't judge a book by its cover?" Name one show where *every* episode in its first season was absolutely the best you have ever seen?
The "best and brightest" are at the galactic core. This documents everyone who was forgotten and discarded. Also it shows the people who didn't want to be under the thumb of a galactic empire. When you attempt to live out of the range of a dominating power, you tend to be remote enough so as to limit the resources you have available. You can't easily get some of the most recent processors when you live in the middle of the Sahara. Does this make everyone who lives in the Sahara lazy and backward because they don't build a fab lab? You need to travel more my friend.
And tractors break down. When you are far enough from supply lines, replacement parts just can't get there in time for the harvest. With a small enough population, a few horses and plows are more than enough.
Yes! Exactly! They didn't include aliens because people can be sufficiently alien. If the aliens are completely comprehensible (and yes, I'm taking pot shots at B5 and Star Trek here), they aren't really aliens. Do you honestly believe that life out there is going to be like the Centauri? That, like in the case of G'Kar, they'll be just like humans in form and reactions but with slightly different pain thresholds and emotions? Do you believe that everyone in an alien race will have basically uniform beliefs and political goals? Kosh shmosh... He stopped short of saying things, tightened up his helmet sphincter, and everyone lauds him as complex and wonderfully mysterious.
Why hasn't everyone noticed the Babylon 5 was populated with humans who have the customs and beliefs of the U.S. and Western Europe (less so the latter)? Oh yeah, I forgot; The U.S. is the best there is and all people in the future will be emulating folks from the Society for Creative Anachronism.
Thank goodness for a show like Firefly. This IS hard sci-fi. It's an honest look at life in the future instead of a future we'd like to see. Examining people that we don't fully understand is the whole point. If all you are doing is watching people that you understand, you're just treading water and never moving forward.
The tech should never be the focus in a realistic story. Even "Snowcrash" spent more time on the characters and how they reacted to one another than on the tech around them. The tech around them only served to explain the people. Take "Ringworld": If you were born there, would you constantly marvel at it? No. It would be all that you ever knew. It would be like everyone on the planet constantly talking about the moon. Sure people talk about it, write about it, and sing about it, but not on a daily basis and not in detail each time. What would be the point? After we discuss its composition, its size, its distance from us, how people act wonky when it's full, etc., why would we need to keep talking about it on an hourly basis unless we learned something new about the moon?
After hearing the line, "...that's why I never kiss them on the mouth," I was hooked. If you don't remember the line, go back and watch the episodes again.
Totally deadpan. Perfect comedic timing by the entire cast. You're right, not one actor should quit his or her day job; This IS their day job.
In how many episodes did they tend cows? I only remember one and it was only in the tail end of the episode (the last minute or two). You're overreacting.
You want to know all of the details? Do you care about the details of a street light? How about the details of your car's air conditioner? How about the portable space heater? How about the fabric blend of your sweater? These are all things that four hundred years ago would have been absolutely shocking and exciting. Light without fire!?! Wow! But in reality, most people (even geeks) just take the light on the streets for granted, think air-conditioner == freon + compressor that keeps you cool, a heater is just an electrical resistor that keeps you warm, and the sweater is 30% cotton and also helps keep you warm. Would you watch a show where they examined the tech behind a streetlight for the whole episode, would you find that terribly stimulating? I wouldn't.
Now remember that Serenity is a simple, not very flashy, old, stand-by workhorse freighter. Are there some details? Sure. The mechanic is always elbow-deep in the details. She's constantly talking about tweaking this and that and the other. But there's a minimum of blinking lights and what widget X or Y gets them faster than light doesn't matter. Let's say they tell you the blow by blow schematics for the faster-than-light drive. Then what? It can't drive a show. It's pointless. FTL doesn't exist and any "explanation" of how it works is useless technobabble that appeals to folks who can't grasp personal interaction.
You speak of Picard's ability to reason his way out of a situation. I challenge you to demonstrate a moment on the show where the captain of Serenity was given a simple problem or solved a problem in an unreasonable fashion.
Tractors require fuel. Constantly replenished sources of fuel. Fuel on any non-trivial scale is dependant upon refineries. You don't just hook up a gas tank to a natural oil reserve. So, assuming that there is a ready supply of fossil fuels, they must also build and maintain a refinery. Otherwise they must get their fuel supplies from off-world. They constantly talk about trips from planet to planet taking from days to weeks. If the people on the planet are poor and basically just surviving, how can the costs of transport for that fuel on a recurring basis be handled?
The fact of the matter is that horses are cheaper to raise and maintain than a tractor is. And a horse generates fertilizer. A tractor just spits out fumes.
Right now, you can go just anywhere on the planet within one day. But imagine it took three weeks to get to Japan from Brazil. Supply lines would be much more expensive, communication would be much more limited, casual trips would be rare, and the one without as many natural resources would be reduced to poverty and meager subsistence.
This is why I like Firefly. No rubber ears. No green people. No transporter accidents. Just people trying to make a life for themselves -- and they happen to be in a very plausible future.
Human interaction is and always will be more important than psuedo-tech minutia just as family, friends, my girlfriend, and my community are all more important to me than my computer. If your tech is more important to you than these things, I pity you. I really do.
microkernels were the rage. HURD answered the call and started work. Now, almost 20 years later, MIT pulls the rug out with exokernels. So will we wait until 2020 to get a working model of that too?
God bless HURD for trying to advance the state of the art and improve upon the dated UNIX model, but sheesh! I wish HURD were ready for prime time. I really do. But a working model with caveats (Linux, OSX, *BSD) will always be better than a better model that's mostly theoretical in the real world.
That said, no one's paying the HURD developers. If it gos their nads, have at it. RMS needs to relax and realize that it is little more than a research experiment and not the second coming.
String foo = "This " + "is " + "a " + "segmented " + "string.";
and
String foo = "This is a segmented string.";
are equivalent in recent (the last few years) Java compilers. Like any good compiler technology, better choices are made over time. It's not a blanket performance dog.
It's also useful for simple cases like:
for (int i=0; i<5; ++i){
String foo = "String" + i;
}
The only real case where you should avoid it is where you are concatenating multiple variables whose contents can only been found at runtime:
Date d = new Date();
int x = 10;
String foo = "String" + x + ": " + d;
In cases like this, you should be using StringBuffers explicitly. Then again, this is common knowledge for Java programmers. Might I suggest the book Java Performance Tuning to help with your speed issues in Java. I consider it in the same league as Meyer's "Effective C++" series for avoiding common language pitfalls. It talks about common usage of containers, string manipulation, threads, and other nice tidbits.
As for numerics, use the right tool for the job. In many cases, it isn't Java. But then, neither is C.
Define "properly." C and C++ programmers are hardly a breed to talk. As for code beautifiers, try this one. I've never used it as I'm fine with my and my team's formatting habits, but it was the first link in a Google search for me.
Try searching for 'Java "code beatifier"'. Worked for me.
As for printing, every printer I've used in the last ten years handled more than 80 characters per column. Mmmmm... Progress...
Or it could be written as:
BlahSomethingElse bse = BlahSomethingElse.getInstance(aVariable, bObject);
BazMember bm = fooObject.barSomething(bse.toString());
bm.bazMe
Is this what you were talking about? Or were you talking about the "getInstance()" static method commonly found in the Java API. It is of course for instantiation with singletons and the like just as it is in C++. I'm surprised this is new for you. In addition, what you see is what you get. It is actually harder to have object instantiations happen without noticing in Java than it is in C++. Incidentally, Java compilers make the same bytecode for this as for your example, and mine is (a) easier to read and (b) prints just fine in 80 columns. And no, I don't advocate 10,000 character lines. I also don't think the 80 column hard limit is necessary anymore either.
And I said nothing about enforcing specific editors or IDEs. Please point out where I did. All I said was that specifically console-based vi and emacs were at issue. Actually, now that I think of it, you can usually stretch console windows out. Or is 80 columns the one true width? Quick quiz: Why is 80 columns such a magic number? Answer: Because that's how many characters fix on the terminal screens and early line printer pattens. Move on.
And while we're on the topic of printing stuff out, you know all of those automatic documentation generators for C and C++? They weren't quite so popular until javadoc came out were they? Show me one for C and C++ that predates Java. Go on. I dare you.
For what it's worth, I have used gvim, vim, emacs, xemacs, moleskine, textpad, BBEdit, Visual Studio, JBuilder, and many others for development. I have even written Java in notepad although I don't recommend the experience to others.
Take that as you will. I personally don't have a problem with it and it hasn't been a real impediment to my code. Why you have objects in the same package that have no usage guidelines, I don't know. There are a lot of people who agree with you, so I'll leave that as a matter of opinion.
So directories are an issue eh? You are aware that it's possible to make classes without subdirectories right? If you don't specify a package, they get put into the default package which is at the root level (of your source tree). As opposed to C and C++, if I have a group of source files in a directory, I know for a fact that they are related to one another (in the same package). In C/C++, I am at the whim of the coder as to what namespace the classes are in (C++ only) and also into which directory s/he saw fit to drop them.
If you have twenty directories for a small project in Java, you've got bigger issues than the directory structure; You're project organization is completely screwed. If you've only got one, and the path is com/mycompany/, I hardly think that is cause for panic and excessive teeth gnashing.
When using a class, because of the package designation, I know exactly where it exists on the source tree if I need to fix something. Makes things simpler for the classloader too and the expectations the developer has of that classloader.
PrintStream o = System.out;
o.print("Is");
o.print(" this");
o.print(" short");
o.print(" enough");
o.print(" for");
o.println(" you?");
Approaching the length of your typical print statement in C. No shortcuts possible in Java indeed.
Harder than the STL? Ha ha! You're kidding right? I love the STL dearly but to say that it's easier to use and more intrinsically intitive than the Collections package is silly. While I wish Java had generics so the Collections would have fewer casts in order to use, it's still easier to use.
As far as relative efficiency of algorithms, are you complaining about the fact that you're not diving into the source? You are aware that there are STL implementations out there that only give you headers and library against which to link?
That said, are you talking about the constant factor to each of the containers or the relative cost of using a LinkedList as opposed to a HashMap? Go read a CS algorithms book. These aren't that tough. Also, there is nothing that says that one JVM will be implemented exactly the same as another (same as the STL). The only thing guaranteed is the API. Whether you are using the STL or Java Collections, you still need to test and benchmark. If you need help deciding which situations call for a List instead of a Set, C and C++ aren't gonna bail you out either. I'm assuming that this is not the case as your comments to this point have been well informed.
As for strings being unicode, I fail to see why that's a mark against Java. I18n and l10n aren't afterthoughts as they are in C and C++; They are designed in. Codepages, character encodings, etc. are things I don't much care about. But thanks to Java, I don't have to. It's a solved problem. Programs today need to be made for more than just English speakers and Java makes that easy. Hell yes it has built it unicode support! Thank god they did the right thing!
Absolutely, positively, blantantly, patently, obviously false. Part of the Java2D API which has been around since Java 1.2 (four years ago?).
Perl? No bizarre semantics? Please tell you are joking. Next you're going to tell me that OO programming in Perl is clear and intuitive.
And I never said anything about a networked GUI. I personally love the Swing API but it is far too big and slow to use for any UI of significant size -- something Sun really needs to work on. Networking and database work however is my bread and butter. C has nothing as clean, elegant, mature, and easy to use as Java's networking and database layers. Period.
As for things to "make it stop," give me another example. Maybe there's something in the API you aren't familiar with that could make your life easier.
Of course no is stopping you from using a preprocessor but this is not true operator overloading when using a preprocessor macro. One of the primary features of operator overloading in C++ (which is the language from which I assume you get your love of the practice) is type safety. There's more to it in practice than syntax magic.
You lose type safety when you invoke a preprocessor as you are no longer under the auspices of the syntax validator.
And as a point of history, operator overloading was ommited because when Gosling et al actually did the research, more bugs were introduced as a result of operator overloading than were reduced by concision. It wasn't a personal grudge or offhand bias. There were many arguments, comparisons, and trials made before the final decision to leave them out.
If you feel that you can handle it and -- more important -- that everyone that will ever touch your code and APIs will make better code because of it, by all means have at it.
As far as the 80 columns difficulties, quit blaming the language and get a better editor -- you know, the kind that can fit more than 80 columns per row or intelligently wrap the lines. Why anyone codes with console-based vi or emacs these days, I will never understand.
This is FUD. There is far more consistency in Java compilers than C compilers in the real world. The difference in output of C compilers is far greater than the difference in output of Java bytecodes. As far as debugging system libraries and the language, while in my years of Java programming I have come across bugs in the JVM implementation and even once(!!!) I came across a compiler bug. I was able to work around the problem in all cases. This is impressive considering that I have done Java development on OS/2, Windows, Linux, and Solaris. I have had far more headaches from C compilers (yes, I code in C as well -- learned it years before Java came along) when bouncing from platform to platform than I have ever had from Java bugs. Come to think of it, I've even come up against a C library bug or two. To suggest that higher level languages are somehow tainted in this respect and C or Assembly is the cleaner answer is laughable.
I misspoke. My intention was to say that iostreams are more portable than an Assembly solution and is more flexible than either. You are correct.
Why? Why does Java need a hack that -- irrespective of the language syntax -- makes drop in text segments like a preprocessor? Do you need it for plugging in a native implementation when available and a Java one when not? Or conditional compilation of some functionality? Java doesn't need a preprocessor for that. You can do it in Java and still take advantage of the Java syntax validators -- which is crippled by the use of a prepreprocessor. It isn't about macros being confusing (which would be a #define and not an #ifdef); It's about them being unnecessary and in this case harmful. Since we're talking about macros and Java, what good would they do? If I write a sufficiently small or simple method/function, the Java compiler will inline it for me. For that matter, so will the optimizing C compiler. #define is of limited use today.
And C is one of the only languages left that DOESN'T have a standard, portable networking API. Java, Python and Perl have all had one for years. Java recently gained a secondary API for non-blocking I/O that takes care of a lot of the speed issues plaguing network apps in the past. And it's supported by all current JVMs. And any Java programmer can look up how to use it in any recent Java tutorial or quick reference.
You want a library? So do I. Those libraries are called java.net, java.nio, and IO::Socket. How are they implemented? Probably in C and/or some Assembly. Do I care? Not if the API is stable and the speed fits my minimum requirements for a job (and they almost always do).
Nothing wrong with "testing out an implementation in a higher-level language" eh? What happens when that implementation is plenty fast and/or memory efficient enough to do the job. Why recode in C?
Java is crippled how? By its standard GUI libraries? How can you compare that to C's lack of any standard GUI library? As for the rest of Java, given the non-blocking I/O libraries, how is Java substantially slower? By all means, give me an example larger and more complex than "Hello World."
Study after study that I have read has demonstrated that algorithm makes far more difference than language in speed contests. The worst problems I have seen in Java code were when arrogant C programmers tried to code it like C and then whine about how it won't work right for them. I have seen Java code where people have made classes called Get_Channels and made instances of those objects in order to call an instance method instead of just making a static method and calling it off of the class definition. This is why Java gets a reputation of slow in the last few years, not because of some inherent limitation of the platform. As far as naming conventions, thank god there's a standard. Any Java programmer who follows the naming standard is pretty well covered that some other programmer will recognize and understand his constructs with a minumum of time and effort. It isn't until C programmers come in with their need to call classes get_channels that things go haywire.
Scope problems? What scope problems? Can you be more specific because I'm not even sure what you have a problem with here.
Yes, and people never bang their head against C or Assembly. I have had many more problems with the limitations of C in the past seven years than I have ever had with Java or Perl. Sometimes C fits the bill. When speed is truly an issue and every little cycle counts, sometimes C (or more often C++) comes to my rescue. For almost every other problem imaginable, C is my problem, not my solution.
Java and C++ have very well defined behavior for object instantiation. For someone who complains that Java programmers just aren't smart enough to handle preprocessor macros, you seem awfully dismissive of your own ability to see what happens in a higher level language when I and others barely even blink.
Only small and simple processing platforms are good candidates for an all-Assembly solution nowadays.
Show me someone who can effectively handle all of the ins and outs of modern Athlons, P4s, Xeons, and G4s, and I'll show you someone who's smart enough to spend their talents on writing compilers instead of individual applications.
I'm sorry, but normal humans cannot beat optimizing compilers on modern processors. Coding to the metal on the high end isn't a viable option anymore.
And as long as your IT guys aren't coding too many O(n^2) algorithms...
Using more efficient algorithms will always be a better usage of coding time than choice of language.
...and of course there's the often overlooked facet of this which is that often times, for a given load and/or userbase, the higher level abstraction is more than fast enough to do the job.
If your current implementation can potentially handle ten times your current requirements, there's no need to rush into the lower levels.
On the contrary, I believe it is you who is being clever or naive. Embedded programming, device drivers, etc. account for maybe one tenth of one percent of all source code written today. I fear that I may even be overestimating that number.
For smaller projects, using low-level facilites can get you big gains. Even for larger projects, optimizing the hotspots in code with low-level constructs from within a high-level framework can show great results. In fact, this is how many high-level languages are implemented.
However, while the human mind is the best code optimizer out there, it is also the most frail and inconsistent. While you can make very tight routines in Assembly on a good day, what happens when you are sleep deprived, up against a hard deadline, and stuck trying to figure out why the program keeps crashing? You know, in the real world. Compilers, while maybe not producing the absolute best code for a particular instance are very consistent about producing pretty damned good binary output billions of times 24 hours a day/7 days a week.
Code production time is also a factor. If you are working on a project that's a few tens of thousand lines of code, Assembly language -- with a competant code author behind it -- can show amazing results over the Python version (for example). But the Python version was finished and debugged days or weeks before the Assembly language version was code complete.
Your C++ example is a bit misleading though. Chances are that you were looking at the assembler's output of iostreams. iostreams implementations, while getting better, are not anywhere near the small size of stdio.h or raw assembly output to the console. Then again, iostreams is far more portable and flexible than either of the previous two. It's a tradeoff, just like everything else in the world: convenience/specificity. Take out iostreams and replace it with a home-grown implementation or stdio.h and you'll notice some "tighter" code.
In addition, compilers keep getting better. A good optimizing compiler is nothing to sneeze at nowadays. As a whole, compilers are measurably better than five years ago, and worlds better than they were fifteen years ago. Some of the best human minds are writing general code optimizers out there today.
Add in the final tidbit that assembly isn't portable. If you are targeting a particular embedded platform with strict space requirements -- a small minority of all development projects out there -- C with Assembly fits the bill. As soon as your platform changes because a vendor went under or requirements demand a faster processor or whatever, all of that Assembly is basically useless. You might be able to use some of the same general algorithms, but you're basically talking about a rewrite. Then again, if you wrote some Assembly code that is more generic, it's not heavily optimized is it? It also doesn't work too well if your target includes multiple platforms from the start.
Want to write a portable, network-aware program? If you use C, be sure to eat your Wheaties in the morning, because you're gonna have to spend a while typing in all of the #ifdefs. But you'll just make it clean and compile for Linux, FreeBSD, Solaris right? What if Windows or BeOS are requirements for your project? #ifdef #ifdef #ifdef
OR!
You could write it in Perl, Python, Java, or any of the other "dirty" high level languages and worry about those clock cycles after you've profiled it and seen the need. This of course doesn't remove the need for proper design before you start, but we were talking about implementation.
Remember: Premature optimization is the root of all evil.