Another sounds-good-on-paper statement that I have been unable to translate into real benefits. How about a realistic example. I find it hard to draw a single wall around things in a system without creating a nasty little bureaucracy for the team. The "walls" depend on the aspect that you want to view things by at the moment.
No, you appear not to understand OO encapsulation at all. The aspects you speak of are nothing more than views of the object, and it has nothing to do with encapsulation.
OO encapsulation actually works very well in the real world. Consider, for example, the use of a Date object instead of a char array or even a long. With the Date object, you have one place to fix your Y2K problem if you made the mistake of storing the date internally in the Date object as a char array with the year in 2 digits. If you make the same mistake in the procedural world, you end up with a big ass bug that costs a hell of a lot of money to fix.
Look at something like the OO Visitor Pattern. That is the mess created by increasing the aspects by *one* dimension. Add another, and kapoof!
If you think it is a mess, then you do not understand the pattern. The Visitor Pattern helps eliminate the mess the same code would otherwise have in either OO or procedural realms. And, the Visitor Pattern is also overused in places where it is not appropriate.
Close enough. Languages should only support fairly common things, not blue-moon things. Otherwise, it ends up being and electronic packrat or offer arbitrary features for bored programmers to futz around with (and they *do*).
Ugh, it is not "close enough". It is nowhere near close enough. Most classes in an OO system will inherit from something else. Sparingly means that your inheritance trees are simple and shallow.
Yeah, everybody bashes everybody else's modeling techniques, even WITHIN the OO community. This is what happens when there are no metrics. Metrics are the cops of ideas.
First, this paragraph changes the argument. Your original point was that a lot of OO "fans" seem ignorant that OO is about design, not coding. Now you say that the problem is everyone is bashing everyone else's modeling techniques and there are no metrics. A different argument.
On the new argument, however, you are still wrong. There are formal processes, with the Unified Process being the most widely accepted process. And as with anything, there are expert OO modelers and there are wannabes. Expert OO modelers are getting the job done.
I hope you are not one of those who try to generitize everything.
Nothing I said suggested I do. So the rest of the paragraph that follows is meaningless since it is based on that assumption. However, your claim that you can never have true genericity is absurd as trying to make everything generic. What do you call the Date class in Java?
On use cases, This is not really OO, per se.
Uh, yes it is. It is the starting point of OO software engineering. Non-OO processes do not model things in this manner. They start with workflows and decision trees, which are very, very, very different from use cases and object interactions.
The rest of your post is on how you think your tables and procedures are the best models for a reporting system. First of all, your dismissal of OO for this problem shows a poor understanding of how the modeling should be done. ER data models are nothing more than collections of DATA and ways of relating the DATA. While the data is data about things in the real world, the table structure is only indirectly and poorly a representation of the thing being modeled. The result is that systems relying on the relational database as a model of the business processes end up being difficult to impossible to maintain over the long haul.
You just got through saying that most of the time inheritance is used sparingly in good OOP?
Sparingly is not the same as not at all.
What is left? Encapsulation? That is a loaded issue because what aspect to "encapsulate" by is not cut and dry.
Encapsulation, polymorphism, and abstraction. And encapsulation is the big piece. In OO parlance, it means to capture the data behind a concept along with its behaviors--and not expose that behavior and data willy-nilly to the public.
So OO is all about component design?
Not entirely, but it is the most critical element. An OO language is simply a language that maps well to OO component designs.
But there is also OO analysis.
That does not sound like a majority OO fan stance to me.
It is probably not what you hear from the inexperienced Java and C++ programmers who think they know OO because they are using an OO language. However, most OO experts will tell you the language and the technology only have a secondary importance to the OO-ness of a system. It is the design.
Besides, the making of components themselves are not what most custom application programmers do. Does that mean that OO is nearly useless for them?
What are you talking about? Custom does not imply not componentized. A custom application can be built from existing components. Similarly, just because you are writing something for the first time does not mean it is not a component.
Procedural tends to emphasize grouping (encapsulation) by actions, while OO tends to emphasize grouping by nouns. This is perhaps an over-generalization, but seems to hold true time after time.
This is a crude description that serves only to help someone who has no understanding at all of the difference between OO and procedural so they can get an initial grasp of the concept. OO is about modeling a system, not programming. It looks at the processes to be modeled, aka use cases. Note, OO starts with actions! The system then looks at the things involved in these actions and the ways in which they interact. Then classes are built to model the things and their interactions. OO is things and their actions, procedural is nothing more than actions. And that is why procedural applications are poor models of the processes they are supposed to be modeling.
Well, I will pit well-designed procedural/relational apps against well-designed OO apps any day.
I would claim that any well-designed procedural app looks a hell of a lot like an OO app. Relational and object are technologies that can go together, they are not mutually exclusive concepts.
I see nothing inherant in OO that really improves maintenance in the business domain. Inheritance does not model business things well, and OO's version of HAS-A is messier than procedural IMO because you have to have an object reference attached to lots of stuff and find a class to stick every method into, even if it should be self-standing.
Inheritance != OO. Inheritance is a necessary property of an OO language, but that does not mean one should use inheritance every chance you get. Properly used inheritance is like a good spice--use it sparingly. A sign of a bad OO system is one with deep and/or complex inheritance hierarchies.
The advantage OO has is that it is a discipline that describes how you write well-designed components. Procedural is not analagous to OO, as it does not prescribe in any way how you properly design your code.
Critics of OOP fail to truly understand what it is that OOP offers. OOP does not offer quicker time to market. It offers easier maintainability, and maintenance is where most corporate money is spent. But it only offers that maintainability if the programmers in question actually follow good OO practices--in other words, they have to be disciplined.
Most OO horror stories come from a lack of discipline. No matter what programming language you use, if you do not have a solid OO design, you have failed to do proper OO programming. It does not matter what programming language you are using.
The result of proper OO development--and unlike the author of the article, I have seen successful OO projects--is a system that is easier for people who had nothing to do with the original to come in a evolve the system. And that is worth a lot to companies.
It depends on the nature of the company. A CIO is the officer in charge of information services. A CTO is in charge of technology services. Information services is the management of the company's corporate information and digital assets. It includes database administration and data warehousing. Technology management includes network administration and software development.
In non-tech Fortune 500 company, they may have a CIO who handles information management within the company as well as the technical services. Some that have very complex technical infrastructures may have both. Under this scenario, the CTO would report to the CIO. Absent a CTO, you would normally have a Director of Technology.
In a small software company, chances are you have a CTO and no CIO. The CTO in this environment is more in charge of setting the strategic technical direction of the company and will come from a software architecture background. In a larger software company, the CTO may have a CIO who reports to them or a Director of Information Services. This CIO is just managing the company's internal systems and data, which are generally much smaller than a large non-tech company.
The rampant conspiracy-oriented paranoia here never ceases to amaze me. Corporations seek only to encourage you to buy their products. They do this most often by creating something you, as a consumer, want. They succeed in doing this by doing this you don't want only when they have monopoly power.
There is now and there will always be a tension between the interests of one party and the interests of others. People don't complain about this much when the tension is person vs. person, since one person is never a conspiracy. The minute government or a corporation is involved, however, the conspiracy theorists come out of the woodworks with the belief that there is a concerted effort to undermine their personal freedoms. There is no such effort. There is simply an ongoing ebb and flow based on the conflicts that arise in a normal society.
With respect to the progress of personal liberties, they have change--some for the better, some for the worse--but are on the whole the same as they were 10 years ago. More important, those liberties are now better shared by previously disenfranchised Americans than they were 10 years ago.
It is true that you need to be vigilant about personal liberties. But being vigilant does no mean:
assuming an intentional effort to deprive you of your personal liberties every time there is a conflict
being paranoid about every conflict arises as if it is the final straw that will lead us to 1984
As another poster noted, it is not lazy to worry about performance later: it is the right way to build a complex application. If you do not have time to worry about it later, then you are building software wrong. A proper software development methodology is iterative and allows for multiple passes at the same functionality. Bad software development gives you one change to get it right. If the problem is complex and you have one shot, you will always get it wrong.
On the other hand, much of the bad rap Java gets on the client is partially, as you state, due to bad Java programming. Java GUI programming is entirely unlike GUI programming in any other language. It is in fact much, much more powerful. When you program Java like would program VisualBasic or PowerBuilder, however, you end up with a very slow GUI that does not behave as any normal user would expect. The reason is that a Java GUI demands to be multi-threaded. Any heavy processing or I/O should never occur as part of the handling of a GUI event. Then you need to remember to show the effects of your background processing only in the Java GUI thread. Any time you see a GUI failing to repaint itself, it is because the programmer has stupidly refused to spin something off in another thread. Any time you see it redrawing itself wrong, it is because the programmer updates the UI directly from a separate thread. Any any time you see a GUI freeze for moments at a time, it is because the programmer is trying to update the UI too many times rather than bundling up UI updates in one call.
Finally, the other bit is due to the Java IDE's. They are all horrible for GUI development and encourage bad UI programming. All of them.
The state of the art in P2P networking is still nascent, and no one has truly solved many of the issues around it. One of the mistakes in the architectures of many solutions these days is to pin their success to a particular network protocol.
In the Open Source P2P project I am working on, xS (http://xs.dasein.org), I have built in a pluggable network layer that literally enables the ability to add new protocols to the application on the fly. Thus, if the rest of xS rocks but the network protocol sucks, it is easy to write support for a new protocol!
Neither VeriSign nor the Chinese seem to understand the way Internet standards work. They do not work to serve the money-making needs of a single company (VeriSign) and they are not subject to xenophobic sovereignty issues (China).
VeriSign is way off-based supporting the registration of non-latin second-level domains under a latin TLD. It is definitely necessary that the Internet move to a Unicode-based DNS and registration system. But VeriSign is approaching the problem in the worst way possible.
China, on the other hand, is playing its tired control game.
It seems a popular/. opinion that marketing is a bad thing, as evidenced by the quote in this posting:
A very thorough look at behind-the-scenes marketing forces.
The example here, and in most cases referenced on/., is a case of bad marketers, not of marketing. As with any discipline, including programming (all programmers are involved with DDoS attacks, right?), marketing can be used and it can be abused. Part of good marketing is making sure that the customer has a positive image of a brand and has a good experience at all levels of interaction with a company. The marketers behind this policy at Motorola simply do not understand this. The problem is not marketing, it is bad marketing.
You really don't have the first clue about namespace issues. You hide your ignorance as an attack on my multi-cultural sensitivities. TLDs exist to break up the namespace specifically in terms of the user base of computers exactly because it is beyond absurdity to think that all computers can fit into a single namespace. If a given namespace is geared at Americans, the namespace should be usable by Americans. If it is aimed at Russians, it should be usable by Russians, if it is aimed at a global audience, then it should strive for a commonality in the global audience.
Why not for.com,.org and.edu? What makes you think non-US netizens are not entitled to use such TLD's?
Because those TLDs are American TLD's. A historical quirk of the fact that the USA started the Internet. Now, if you want to co-opt them for world use, then they should use the lowest-common denominator character set usable by all users and input methods: ISO-8859-1. If they are to retain their US origins, then it should be ASCII. There is absolutely no use for forcing domains aimed at an American audience to deal with the inefficienies of two, three, and multi-byte character sets or of conversions among character sets.
The problem is not that we have language-specific characters, is that you don't. We don't consider them special, except for the fact that we can't use them normally (without kludges like i18n features) on a computer.
You are making an ass out of yourself. My machine supports entering characters in several alphabets, including many accented European languages, Russian, Arabic, and Thai. The issue is nothing about considering certain characters "special". It is about understanding your audience. I spend a lot of time on I18N issues and am a huge advocate of I18N concerns, but opening every domain to every character set on earth is not I18N: it is wreckless multiculturalism.
I said:
"If.com is aimed at a global audience, then domains registered under that TLD should support a global audience: i.e. ASCII or ISO-8859-1. NOTHING ELSE."
To which you replied: Yeah, cause we all know everyone in the whole fuckin' world can read English! (Well, those who can't aren't worth shit anyway.)
ISO-8859-1 is not an English-specific character set. There is nothing english-centric about it. And again, my comments are directed towards.com,.org, and.net which are American TLDs in spite of the trend of foreign companies using them.
I never said they were stupid americans. I said that they were americans and that they obviously could not understand that this is an important issue in other countries.
Again, your assumption is that people who do not agree with you do not understand those issues and therefore must be American.
Furthermore, the issue is not whether you should be able to have a domain name with a Jönsson component, but whether you should be able to stick that in.com,.org, or.net. I do not see the problem with it for ISO 8859-1 characters, but I do understand the argument against it. Furthermore, I don't think.com,.org, or.net should be extended beyond the extended latin characters for reasons I have already enumerated.
And I really do not like your dismissal of any American point of view on the matter.
People don't agree with you, so you just dismiss them as stupid Americans? How enlightened!
There are many Americans who understand internationalization issues very thoroughly, and some of them disagree with this proposal. It is a bad proposal because, first off, it really does not seem to understand internationalization issues. You do not accomplish I18N by using national character sets. Using an NCS is not making your content supported for an international environment. It is doing exactly the opposite. In many cases, there are half a dozen NCS that support the same damn alphabet. If you really want I18N, you need to use Unicode (preferably UTF8) or UCS.
If you are going to support multilingual domain names, resolution must occur in either Unicode or UCS. Let DNS lookup libraries handle the conversion from KOI-8 to UTF8. The user enters the domain in their NCS and the DNS server only has to handle one character set.
Beyond the issue of I18N, however, is the issue of who a TLD is targetted at. If.com is aimed at a global audience, then domains registered under that TLD should support a global audience: i.e. ASCII or ISO-8859-1. NOTHING ELSE. Let.ru use more of the unicode spectrum. Or even allow for a.ðî (that was the cyrillic letters for the first to characters in the Russian word Rossiya, in case your browser cannot resolve those) for domains aimed specifically at Russian speakers.
Nevertheless, I think all domain names should be unicode or UCS with registry restricted some subset of the unicode spectrum appropriate to the TLD in question:.com as 8859-1,.ru as 8859-1 + cyrillic ISO, etc. That way all DNS servers can easily resolve names, but the target audience for a given domain can always have the input method to support accessing hosts in that domain.
Two wrongs do not make a right. PETA should not have ringlingbros.com registered. I think petasucks.org is really there for the first one to get it, peta or otherwise.
It's actually a really crappy legal precedent. Using other people's trade names for parodies is not an illegitimate use of the name, and their site was not confusingly similar to PETA - there's no way you could mistake one for the other.
It is actually an excellent legal precedent. PETA is a trademark. While I do not agree with the corporate "if my trademark is in the name, you cannot use it", this is an example of someone squatting in PETA's legitimate namespace,.org, and depriving them of the use of their trademark.
If it had been PETA.com, I would be on the other side of the fence. No one would expect a non-profit organization to be in the.com space. In short parody is cool so long as you do not deprive someone of the legitimate use of their name. In this case, the parody site is depriving PETA of its trademark.
RSA has a patent over a particular algorithm. Patents are not copyrights are not trademarks.
Trademarks last as long as you enforce them. You are not required to register a trademark.
Copyrights last 75 years (with some odd exception clauses) irrespective of enforcement. You are not required to register a copyright.
Patents last 17 years irrespective of enforcement. You must apply for and be granted a patent.
As a result, no copyright has passed into the public domain in a long, long, long, long time. And the original post did not imply all fall into the public domain in 2008, just some of the earliest works currently protected by copyright.
If IT businesses shift to providing services, will the suits, which historically make software releases buggy, bloated, and premature, be taken out of the decision process?
Software developers have just as much responsibility for buggy, bloated software releases.
Disclaimer: I am one of the authors of O'Reilly's MySQL and mSQL
The article in question is quite bad. It appears as if it is trying to make a point just by throwing about the term "atomicity" and quoting someone else. The implications made by the author are that MySQL is likely to lose data or be inconsistent. That is completely false.
Using MySQL is like using any other database engine in AUTO COMMIT mode. For heavy read requirements or simplistic data models, the fact that you cannot package multiple database accesses in a single transaction is irrelevant--you simply do not need to.
The one assertion that is true is that MySQL is not an enterprise database engine. It neither claims to be one nor strives to be one. But that hardly renders it, as he calls it, a file system with a SQL front end.
You did not really read my post at all did you? You just figure you'd pull out the flame gun for the fun of it? MySQL excels in heavy read environments like Web content management. No other database is capable of coming close to matching its performance. I did not suggest or imply that performance was the only metric for chosing a database engine. Of course, if you have a datawarehouse where the scalability and data analysis tools are an issue, then you are talking about a different beast. Get a fucking clue and put your flamethrower away.
You can get by without transaction control if your database is essentially static. However, if all you are doing is doing lookups against a static list, you could just as easily work from flat files and avoid the overhead of using any database. If there is any structure to your data at all, this is patently false. Relational databases exist because complex data relationships cannot be represented well in flat files or hierarchical databases. MySQL excels in heavy read environments. Web content management for example. No other database can compare to it. That does not imply no writes. It implies only that your writes are well isolated with little complexity.
Slashdot Mirror
*rofl*
This has always been an argument Linux users love to ridicule in Windows users... now the shoe is on the other foot!
No, you appear not to understand OO encapsulation at all. The aspects you speak of are nothing more than views of the object, and it has nothing to do with encapsulation.
OO encapsulation actually works very well in the real world. Consider, for example, the use of a Date object instead of a char array or even a long. With the Date object, you have one place to fix your Y2K problem if you made the mistake of storing the date internally in the Date object as a char array with the year in 2 digits. If you make the same mistake in the procedural world, you end up with a big ass bug that costs a hell of a lot of money to fix.
Look at something like the OO Visitor Pattern. That is the mess created by increasing the aspects by *one* dimension. Add another, and kapoof!
If you think it is a mess, then you do not understand the pattern. The Visitor Pattern helps eliminate the mess the same code would otherwise have in either OO or procedural realms. And, the Visitor Pattern is also overused in places where it is not appropriate.
Close enough. Languages should only support fairly common things, not blue-moon things. Otherwise, it ends up being and electronic packrat or offer arbitrary features for bored programmers to futz around with (and they *do*).
Ugh, it is not "close enough". It is nowhere near close enough. Most classes in an OO system will inherit from something else. Sparingly means that your inheritance trees are simple and shallow.
Yeah, everybody bashes everybody else's modeling techniques, even WITHIN the OO community. This is what happens when there are no metrics. Metrics are the cops of ideas.
First, this paragraph changes the argument. Your original point was that a lot of OO "fans" seem ignorant that OO is about design, not coding. Now you say that the problem is everyone is bashing everyone else's modeling techniques and there are no metrics. A different argument.
On the new argument, however, you are still wrong. There are formal processes, with the Unified Process being the most widely accepted process. And as with anything, there are expert OO modelers and there are wannabes. Expert OO modelers are getting the job done.
I hope you are not one of those who try to generitize everything.
Nothing I said suggested I do. So the rest of the paragraph that follows is meaningless since it is based on that assumption. However, your claim that you can never have true genericity is absurd as trying to make everything generic. What do you call the Date class in Java?
On use cases, This is not really OO, per se.
Uh, yes it is. It is the starting point of OO software engineering. Non-OO processes do not model things in this manner. They start with workflows and decision trees, which are very, very, very different from use cases and object interactions.
The rest of your post is on how you think your tables and procedures are the best models for a reporting system. First of all, your dismissal of OO for this problem shows a poor understanding of how the modeling should be done. ER data models are nothing more than collections of DATA and ways of relating the DATA. While the data is data about things in the real world, the table structure is only indirectly and poorly a representation of the thing being modeled. The result is that systems relying on the relational database as a model of the business processes end up being difficult to impossible to maintain over the long haul.
Sparingly is not the same as not at all.
What is left? Encapsulation? That is a loaded issue because what aspect to "encapsulate" by is not cut and dry.
Encapsulation, polymorphism, and abstraction. And encapsulation is the big piece. In OO parlance, it means to capture the data behind a concept along with its behaviors--and not expose that behavior and data willy-nilly to the public.
So OO is all about component design?
Not entirely, but it is the most critical element. An OO language is simply a language that maps well to OO component designs.
But there is also OO analysis.
That does not sound like a majority OO fan stance to me.It is probably not what you hear from the inexperienced Java and C++ programmers who think they know OO because they are using an OO language. However, most OO experts will tell you the language and the technology only have a secondary importance to the OO-ness of a system. It is the design.
Besides, the making of components themselves are not what most custom application programmers do. Does that mean that OO is nearly useless for them?
What are you talking about? Custom does not imply not componentized. A custom application can be built from existing components. Similarly, just because you are writing something for the first time does not mean it is not a component.
Procedural tends to emphasize grouping (encapsulation) by actions, while OO tends to emphasize grouping by nouns. This is perhaps an over-generalization, but seems to hold true time after time.
This is a crude description that serves only to help someone who has no understanding at all of the difference between OO and procedural so they can get an initial grasp of the concept. OO is about modeling a system, not programming. It looks at the processes to be modeled, aka use cases. Note, OO starts with actions! The system then looks at the things involved in these actions and the ways in which they interact. Then classes are built to model the things and their interactions. OO is things and their actions, procedural is nothing more than actions. And that is why procedural applications are poor models of the processes they are supposed to be modeling.
I would claim that any well-designed procedural app looks a hell of a lot like an OO app. Relational and object are technologies that can go together, they are not mutually exclusive concepts.
I see nothing inherant in OO that really improves maintenance in the business domain. Inheritance does not model business things well, and OO's version of HAS-A is messier than procedural IMO because you have to have an object reference attached to lots of stuff and find a class to stick every method into, even if it should be self-standing.
Inheritance != OO. Inheritance is a necessary property of an OO language, but that does not mean one should use inheritance every chance you get. Properly used inheritance is like a good spice--use it sparingly. A sign of a bad OO system is one with deep and/or complex inheritance hierarchies.
The advantage OO has is that it is a discipline that describes how you write well-designed components. Procedural is not analagous to OO, as it does not prescribe in any way how you properly design your code.
Most OO horror stories come from a lack of discipline. No matter what programming language you use, if you do not have a solid OO design, you have failed to do proper OO programming. It does not matter what programming language you are using.
The result of proper OO development--and unlike the author of the article, I have seen successful OO projects--is a system that is easier for people who had nothing to do with the original to come in a evolve the system. And that is worth a lot to companies.
In non-tech Fortune 500 company, they may have a CIO who handles information management within the company as well as the technical services. Some that have very complex technical infrastructures may have both. Under this scenario, the CTO would report to the CIO. Absent a CTO, you would normally have a Director of Technology.
In a small software company, chances are you have a CTO and no CIO. The CTO in this environment is more in charge of setting the strategic technical direction of the company and will come from a software architecture background. In a larger software company, the CTO may have a CIO who reports to them or a Director of Information Services. This CIO is just managing the company's internal systems and data, which are generally much smaller than a large non-tech company.
There is now and there will always be a tension between the interests of one party and the interests of others. People don't complain about this much when the tension is person vs. person, since one person is never a conspiracy. The minute government or a corporation is involved, however, the conspiracy theorists come out of the woodworks with the belief that there is a concerted effort to undermine their personal freedoms. There is no such effort. There is simply an ongoing ebb and flow based on the conflicts that arise in a normal society.
With respect to the progress of personal liberties, they have change--some for the better, some for the worse--but are on the whole the same as they were 10 years ago. More important, those liberties are now better shared by previously disenfranchised Americans than they were 10 years ago.
It is true that you need to be vigilant about personal liberties. But being vigilant does no mean:
On the other hand, much of the bad rap Java gets on the client is partially, as you state, due to bad Java programming. Java GUI programming is entirely unlike GUI programming in any other language. It is in fact much, much more powerful. When you program Java like would program VisualBasic or PowerBuilder, however, you end up with a very slow GUI that does not behave as any normal user would expect. The reason is that a Java GUI demands to be multi-threaded. Any heavy processing or I/O should never occur as part of the handling of a GUI event. Then you need to remember to show the effects of your background processing only in the Java GUI thread. Any time you see a GUI failing to repaint itself, it is because the programmer has stupidly refused to spin something off in another thread. Any time you see it redrawing itself wrong, it is because the programmer updates the UI directly from a separate thread. Any any time you see a GUI freeze for moments at a time, it is because the programmer is trying to update the UI too many times rather than bundling up UI updates in one call.
Finally, the other bit is due to the Java IDE's. They are all horrible for GUI development and encourage bad UI programming. All of them.
In the Open Source P2P project I am working on, xS (http://xs.dasein.org), I have built in a pluggable network layer that literally enables the ability to add new protocols to the application on the fly. Thus, if the rest of xS rocks but the network protocol sucks, it is easy to write support for a new protocol!
VeriSign is way off-based supporting the registration of non-latin second-level domains under a latin TLD. It is definitely necessary that the Internet move to a Unicode-based DNS and registration system. But VeriSign is approaching the problem in the worst way possible.
China, on the other hand, is playing its tired control game.
A very thorough look at behind-the-scenes marketing forces.
The example here, and in most cases referenced on /., is a case of bad marketers, not of marketing. As with any discipline, including programming (all programmers are involved with DDoS attacks, right?), marketing can be used and it can be abused. Part of good marketing is making sure that the customer has a positive image of a brand and has a good experience at all levels of interaction with a company. The marketers behind this policy at Motorola simply do not understand this. The problem is not marketing, it is bad marketing.
Why not for .com, .org and .edu? What makes you think non-US netizens are not entitled to use such TLD's?
Because those TLDs are American TLD's. A historical quirk of the fact that the USA started the Internet. Now, if you want to co-opt them for world use, then they should use the lowest-common denominator character set usable by all users and input methods: ISO-8859-1. If they are to retain their US origins, then it should be ASCII. There is absolutely no use for forcing domains aimed at an American audience to deal with the inefficienies of two, three, and multi-byte character sets or of conversions among character sets.
The problem is not that we have language-specific characters, is that you don't. We don't consider them special, except for the fact that we can't use them normally (without kludges like i18n features) on a computer.
You are making an ass out of yourself. My machine supports entering characters in several alphabets, including many accented European languages, Russian, Arabic, and Thai. The issue is nothing about considering certain characters "special". It is about understanding your audience. I spend a lot of time on I18N issues and am a huge advocate of I18N concerns, but opening every domain to every character set on earth is not I18N: it is wreckless multiculturalism.
"If
Yeah, cause we all know everyone in the whole fuckin' world can read English! (Well, those who can't aren't worth shit anyway.)
ISO-8859-1 is not an English-specific character set. There is nothing english-centric about it. And again, my comments are directed towards .com, .org, and .net which are American TLDs in spite of the trend of foreign companies using them.
I suggest you get a fucking clue.
Again, your assumption is that people who do not agree with you do not understand those issues and therefore must be American. Furthermore, the issue is not whether you should be able to have a domain name with a Jönsson component, but whether you should be able to stick that in .com, .org, or .net. I do not see the problem with it for ISO 8859-1 characters, but I do understand the argument against it. Furthermore, I don't think .com, .org, or .net should be extended beyond the extended latin characters for reasons I have already enumerated.
And I really do not like your dismissal of any American point of view on the matter.
There are many Americans who understand internationalization issues very thoroughly, and some of them disagree with this proposal. It is a bad proposal because, first off, it really does not seem to understand internationalization issues. You do not accomplish I18N by using national character sets. Using an NCS is not making your content supported for an international environment. It is doing exactly the opposite. In many cases, there are half a dozen NCS that support the same damn alphabet. If you really want I18N, you need to use Unicode (preferably UTF8) or UCS.
If you are going to support multilingual domain names, resolution must occur in either Unicode or UCS. Let DNS lookup libraries handle the conversion from KOI-8 to UTF8. The user enters the domain in their NCS and the DNS server only has to handle one character set.
Beyond the issue of I18N, however, is the issue of who a TLD is targetted at. If .com is aimed at a global audience, then domains registered under that TLD should support a global audience: i.e. ASCII or ISO-8859-1. NOTHING ELSE. Let .ru use more of the unicode spectrum. Or even allow for a .ðî (that was the cyrillic letters for the first to characters in the Russian word Rossiya, in case your browser cannot resolve those) for domains aimed specifically at Russian speakers.
The fact is EVERYONE builds their systems for their needs. The fact also is that Americans lead the world in driving issues of I18N and L10N.
Nevertheless, I think all domain names should be unicode or UCS with registry restricted some subset of the unicode spectrum appropriate to the TLD in question: .com as 8859-1, .ru as 8859-1 + cyrillic ISO, etc. That way all DNS servers can easily resolve names, but the target audience for a given domain can always have the input method to support accessing hosts in that domain.
Two wrongs do not make a right. PETA should not have ringlingbros.com registered. I think petasucks.org is really there for the first one to get it, peta or otherwise.
It is actually an excellent legal precedent. PETA is a trademark. While I do not agree with the corporate "if my trademark is in the name, you cannot use it", this is an example of someone squatting in PETA's legitimate namespace, .org, and depriving them of the use of their trademark.
If it had been PETA.com, I would be on the other side of the fence. No one would expect a non-profit organization to be in the .com space. In short parody is cool so long as you do not deprive someone of the legitimate use of their name. In this case, the parody site is depriving PETA of its trademark.
- Trademarks last as long as you enforce them. You are not required to register a trademark.
- Copyrights last 75 years (with some odd exception clauses) irrespective of enforcement. You are not required to register a copyright.
- Patents last 17 years irrespective of enforcement. You must apply for and be granted a patent.
As a result, no copyright has passed into the public domain in a long, long, long, long time. And the original post did not imply all fall into the public domain in 2008, just some of the earliest works currently protected by copyright.Software developers have just as much responsibility for buggy, bloated software releases.
The article in question is quite bad. It appears as if it is trying to make a point just by throwing about the term "atomicity" and quoting someone else. The implications made by the author are that MySQL is likely to lose data or be inconsistent. That is completely false.
Using MySQL is like using any other database engine in AUTO COMMIT mode. For heavy read requirements or simplistic data models, the fact that you cannot package multiple database accesses in a single transaction is irrelevant--you simply do not need to.
The one assertion that is true is that MySQL is not an enterprise database engine. It neither claims to be one nor strives to be one. But that hardly renders it, as he calls it, a file system with a SQL front end.
You did not really read my post at all did you? You just figure you'd pull out the flame gun for the fun of it? MySQL excels in heavy read environments like Web content management. No other database is capable of coming close to matching its performance. I did not suggest or imply that performance was the only metric for chosing a database engine. Of course, if you have a datawarehouse where the scalability and data analysis tools are an issue, then you are talking about a different beast. Get a fucking clue and put your flamethrower away.
You can get by without transaction control if your database is essentially static. However, if all you are doing is doing lookups against a static list, you could just as easily work from flat files and avoid the overhead of using any database. If there is any structure to your data at all, this is patently false. Relational databases exist because complex data relationships cannot be represented well in flat files or hierarchical databases. MySQL excels in heavy read environments. Web content management for example. No other database can compare to it. That does not imply no writes. It implies only that your writes are well isolated with little complexity.
Actually, Monty was a technical reviewer for both books.