I am a parent. I don't want the government raising my children or telling me what is or is not appropriate for my children to see and hear.
Last time I checked, raising children and being the protector of the public's morals were not among the enumerated powers granted to Congress by the Constitution.
If you are offended by porn in your kid's email, do something about it. Either don't let them online unsupervisied or pre-screen all their mail. Personally, I run my own mail server. Once my kids are old enough to read their own email, I'll set up a set of procmail rules so that only receive email from senders I've pre-approved.
chick sexer (keep the females that will grow up to be egg-laying hens, kill the males... sexing them involves pushing your little finger up their anus and feeling for a bump... try doing that one all day).
Thanks for that mental image. I laughed so hard I almost passed out. I pity the person who has to spend the day ass-fucking baby chickens with his pinkey finger. (and I pity the baby chickens who have to get ass-fucked)
. What I meant was that on a typical project, the ratio of application programmers to DBAs is circa 10:1. Thus, it makes sense that core business logic (which includes the kinds of data consistency stuff that often ends up in stored procedures) should be in the language the application programmers know, leaving the DBA to focus on the database, not the business logic.
I would agree with this, if the database was going to be accessed by one and only one set of objects. However, it's far more common for the database to support multiple applications and interfaces, which are not necessarily written in the same language (or even by the same group). Having the logic needed to maintain database consistency contained within the database means that you don't have to duplicate the same logic (and introduce potential bugs) in each piece of software that touches the database.
It's not feasible to start building it right away because we can't mass-produce carbon nanotubes of the requisite strength yet. Buckytubes are theoretically more than strong enough, but the best current lab samples only deliver about 1/4 of this. To build the space elevator, we need buckytubes that are twice as strong as the best we can make right now, and we need to be able to mass produce them cheaply. This seems like an attainable short-term goal.
Try this exercise in backyard physics: Tie a rock to the end of a piece of rope. Hold the other end. Spin around and watch the rock fly and observe the tension on the rope.
You don't need rockets to keep the rope tight - the energy comes from the rotational energy you are providing. In the case of a space elevator, the Earth's own rotation provides the tension.
Designing an object model AFTER a database model is a recipe for disaster..
Go ahead and disagree. My CIO would disagree with your stance; and when payday rolls around, it's his opinion that matters. He hired me largly because of my design philosopy -- this exact debate came up in my interview. Thus far, disaster has been averted (quite the opposite, in fact). I've evaluated several of the O/R mapping software packages mentioned earlier in this thread and in my professional opinion, they all suck; largely because they all attack the problem from the wrong direction.
How you partition the application logic is up to you. The way I design systems, business logic goes in the object layer, data integrity logic goes in the database. The database doesn't care if the data is meaningful -- it only cares that it's consistent with the referential integrity rules.
Basically what I'm saying is that instead of allowing the programmer to imbed the statment insert Foo ( bar, baz ) values ( @x, @y ) in his code, you instead require that he calls sp_FooAdd @x, @y instead. The details of how the sp validates the inputs and handles errors are hidden from the programmer. It's not rocket science. That way you don't have your C++/Java/Perl/whatever programmers trying to write SQL code -- you delegate that to your DBA who should know SQL *far* better than any of your applications programmers. I don't expect a good C++ coder to understand all the intracacies of a particular RDBMS, just as I don't expect a DBA to know how to write good multithreaded C++ code. It's my experience that when you let applications programmers write SQL, you get crappy databases.
There's no one language that all programmers know. No one language is suited to all tasks. For each component in the system you use the tool that is best suited to that task. A non-trivial system is going to include components written in multiple different languages. Even a fairly trivial database-backed CGI web app is going to use 3 or 4 different languages: HTML for the browser (possibly with Javascript as well), Perl for the CGI script, and SQL for the database.
You (or at least *I*) don't let apps rummage around in raw data -- all database access (reads and modifications) goes through stored procedures. The user should never have permission to touch the tables directly - all he needs to have is execute permission on a specific set of SPs.
I think.kids is a better idea than.xxx -- in order to get a.kids domain name, you have to enter into a legally binding contract that you will follow a clearly-defined set of rules. If you violate the terms of the contract, you lose your domain and get the pants sued off of you.
You can't get an.edu unless you are a legitimate accredited institution (althought that might be changing) A.kids TLD should work the same way. If parents wanted to limit their children to viewing.kids sites only, that would be their perogative.
Is a piece of software really complete if noone but the author can use it? Documentation is just as important a deliverable as is the executable code. Absence of documentation is a bug. Incorrect documentation is a bug. Kudos for Debian for having the guts to keep us programmers honest. Writing docs is less fun than writing code, but if you don't do it, you're only doing half the job.
Does this new toy support record locking, transactional isolation and integrity, or any of the other key features that an enterprise RDBMS provides? If the answer is no, then it's not a replacement for an RDBMS.
Wrong.
Re-read what I wrote, paying attention to the highlighted words. You seem like a good enough programmer to be able to grok an if..then construct:-)
The question isn't the checklist of features, it's whether you can build equivalently reliable systems with Prevayler. The answer: You can.
Since you seem to know what you're talking about, I'll take your word for it for now. I'd need A LOT more proof of it's reliability before I'd use it in a mission critical application.
I'll agree with you that the ultimate test is functional equivilence - if I can achieve the same results, even if it's via a different mechanism, then it's an adequate replacement. However, I don't see that as the case here because even if it passes the ACID test (Atomicity, Consistency, Isolation, and Durability) it is still (from what I've seen) tightly coupled with a single object model, whereas an RDBMS schema can be wrappered by multiple independent object models (or even non-OO front-ends) that are tailored to specific tasks.
I'm sure Prevayler is a useful tool for some niche applications -- it sounds like it would be particuarly well suited for embedded systems or simulations. However I don't see it replacing the DRBMS for the meat-and-potatoes work of storing, retrieving, and crunching large quantaties of data.
There are cases in which you really want a base class extended by multiple subclasses, and now you can't write your foriegn key constraints properly. Alternatively, you could duplicate your common code for each table, but that's even worse
You can model a base class derived child classes by having a parent table corresponding to the base class, and multiple child tables (fk'ed to the parent 1:1) corresponding to the extended classes. It helps to add an extra identifier to the parent table to give you a hint where to look for the rest of the data. If you feel like it you can then wrap the joins in a view to hide the fact that the common properties are a common table.
Naturally, the solution you adopt depends on the application. Sometimes a pure 1:1 mapping is the Right Thing, sometimes it is not. I've found that using a 1:1 mapping is often a good starting point for a prototype while you refine your understanding of the problem domain. Automated tools are nice, but they're no substitute for experience and a solid understanding of the problem you are trying to solve. Often you don't gain that understanding until you've done a prototype or proof-of-concept and discovered it's flaws.
Allowing users to edit posts would be (IMHO) a Bad Thing. Consider this: I post "M$ Sux, Linux R00lz!" and promptly get moderated to +5, Insightful and get 100 Me too comments. Now, I go back and edit it to say "Linux Sux, M$ R00lz". The content of the post is completely opposite of what people responded to and what earned the moderation. [I could see allowing editing (maybe) if there are no responses and no moderation on the comment].
I guess you just need to learn to use the preview button:-)
Re:Ceaser flunks the Orwell test.
on
Ask Larry Niven
·
· Score: 1
Were swords expensive or was the Roman Empire democratic?
One man with a sword(*) was not expensive. A legion of armed and armored men, TRAINED TO FIGHT AS A UNIT, was expensive. The dominance of the Roman legions over their contemporary rivals was not due to any technical superiority of thier equipment - it was due to superior tactics, training, and most importantly logistics (there's a reason the Roman army spent more time building roads than fighting!)
(*) The sword was never the primary weapon of the legionairre; thier primary weapons were the spear and javelin. Contrary to what Hollywood depicts, the sword was almost never a soldier's primary weapon - it was usually considered to be a backup weapon by those who could afford one. Even if you were wealthy enough to afford a sword, your primary weapon was far more likely to be a spear, lance, or other polearm; with an axe, mace, or warhammer being preferred for close combat. Certianly swords were used in combat, but it was by far the exception rather than the rule - an axe, spear, or mace was cheaper, less likely to break, and more effective against armor.
It's a good idea because relational databases, XML files, and flat files are not really all that similar to objects. [...]
Sorry, you're wrong. With a little forethought it's pretty simple to map an object model to an RDBMS schema. The trick is to design the database schema first, then build your objects on top of it. Doing it in reverse is a bitch. The reason many OO programmers have problems using databases is that they treat the database as an afterthought instead of as the foundation of the application. Here's the basic method I use:
Tables map to objects; fields map to the properties of that object on a 1:1 basis
Object methods map to stored procedures where appropriate
A row in a table is an instance of an object
Foreign-keyed child tables map to collections within the parent object.
using Oracle for storing objects means that you've already got a badly-designed system
You illustrate my point perfectly about putting the cart before the horse. You don't build a database to store your objects -- you build objects to manipulate your database. A badly-designed system is one where the database was tacked on after the object model was complete. Your database schema should be the first thing you write, before you even start thinking about the classes.
Unfortunately, Comp Sci cirriculums are heavy on OOP concepts but pathetically light on database theory, which is why you wind up with otherwise talented programmers who don't understand the basic fundamentals of designing solid client-server applications.
You don't use an RDBMS because it's fast. You use it because it's reliable. Does this new toy support record locking, transactional isolation and integrity, or any of the other key features that an enterprise RDBMS provides? If the answer is no, then it's not a replacement for an RDBMS.
If you don't care about the integrity of your data, something like this is fine. When you absoloutely can't have data errors, you take the time to make sure you do it right, which means using an enterprise-grade database server.
The capabilities of the current and imminent crop of mobile gaming platforms (i.e. Java-enabled cellphones, etc), means that these 10-15 year old PC games are going to be about state of the art on them. There's potentially a lot of money to be made by selling download rights on implementations of these games.
Not exactly. An executable binary for an obsolete piece of hardware is utterly useless for this kind of thing. Console games, particuarly old ones, are highly platform-specific. In order to get decent performance out of limited hardware, you had to program on the bare metal. This results in code that is an utter bitch to port to a different platform, assuming that the source code even exists anymore. There's a good reason that old-school console games were only available on one or two platforms.
While a Java-enabled cell phone may have comperable computing power to an early 80's console game, that does not mean that it's going to be easy to port an old game to it; and a cell phone or PDA isn't going to have the horsepower to run an emulator. Since Java didn't exist when these games were written (and they wouldn't have been written in it even if it had existed), you're going to have to re-write the entire game from scratch in Java. (Alternatively, you could write a compiler and support library which would allow you to compile the original source into Java bytecodes; this would be a monumental effort of dubious value)
Unfortunately, in the court of public opinion the polygraph is treated with devine reverence. A great many people (read: prospective jurors) would consider refusal to take a polygraph test to be tantamount to an admission of guilt. The basic problem is that people are gullable and stupid.
Advocates like to say "guns don't kill people", and they are right to that extent. However, body armor piercing bullets have no other objective, because bears don't wear body armor.
Non sequitir. Bears don't commit armed robbery. Bears don't kick down your door in the middle of the night and drag you away to a secret location. Bears don't try to create a police state. Bears don't attempt to subvert the US Constitution.
The Right To Keep and Bear Arms is about more than target shooting or hunting, or even about personal self-defense. The Second Amendment was put in place by our founding fathers to ensure that the People will always have the means to defend their Freedoms against would-be tyrants.
A moped will do everything the Segway will do for approximately 1/5 the price. A zero-emissions moped is still much less than 1/2 the price. It's a toss-up as to which one makes you look like a bigger doofus:-)
Face it, segway is an overpriced tech toy, not a practical commuter device. As a consumer product in the current economy, it's doomed. I can see it being successful as a niche product for some industrial applications but that's about it.
Slashdot Mirror
Last time I checked, raising children and being the protector of the public's morals were not among the enumerated powers granted to Congress by the Constitution.
If you are offended by porn in your kid's email, do something about it. Either don't let them online unsupervisied or pre-screen all their mail. Personally, I run my own mail server. Once my kids are old enough to read their own email, I'll set up a set of procmail rules so that only receive email from senders I've pre-approved.
That being said, the materials used would need an extensive amount of testing to prove their durability over time.
It's not feasible to start building it right away because we can't mass-produce carbon nanotubes of the requisite strength yet. Buckytubes are theoretically more than strong enough, but the best current lab samples only deliver about 1/4 of this. To build the space elevator, we need buckytubes that are twice as strong as the best we can make right now, and we need to be able to mass produce them cheaply. This seems like an attainable short-term goal.
Try this exercise in backyard physics: Tie a rock to the end of a piece of rope. Hold the other end. Spin around and watch the rock fly and observe the tension on the rope.
You don't need rockets to keep the rope tight - the energy comes from the rotational energy you are providing. In the case of a space elevator, the Earth's own rotation provides the tension.
Basically what I'm saying is that instead of allowing the programmer to imbed the statment insert Foo ( bar, baz ) values ( @x, @y ) in his code, you instead require that he calls sp_FooAdd @x, @y instead. The details of how the sp validates the inputs and handles errors are hidden from the programmer. It's not rocket science. That way you don't have your C++/Java/Perl/whatever programmers trying to write SQL code -- you delegate that to your DBA who should know SQL *far* better than any of your applications programmers. I don't expect a good C++ coder to understand all the intracacies of a particular RDBMS, just as I don't expect a DBA to know how to write good multithreaded C++ code. It's my experience that when you let applications programmers write SQL, you get crappy databases.
There's no one language that all programmers know. No one language is suited to all tasks. For each component in the system you use the tool that is best suited to that task. A non-trivial system is going to include components written in multiple different languages. Even a fairly trivial database-backed CGI web app is going to use 3 or 4 different languages: HTML for the browser (possibly with Javascript as well), Perl for the CGI script, and SQL for the database.
You (or at least *I*) don't let apps rummage around in raw data -- all database access (reads and modifications) goes through stored procedures. The user should never have permission to touch the tables directly - all he needs to have is execute permission on a specific set of SPs.
You can't get an .edu unless you are a legitimate accredited institution (althought that might be changing) A .kids TLD should work the same way. If parents wanted to limit their children to viewing .kids sites only, that would be their perogative.
Is a piece of software really complete if noone but the author can use it? Documentation is just as important a deliverable as is the executable code. Absence of documentation is a bug. Incorrect documentation is a bug. Kudos for Debian for having the guts to keep us programmers honest. Writing docs is less fun than writing code, but if you don't do it, you're only doing half the job.
Of course there's always: ln -s /usr/local/bin/bash /bin/bash
I'll agree with you that the ultimate test is functional equivilence - if I can achieve the same results, even if it's via a different mechanism, then it's an adequate replacement. However, I don't see that as the case here because even if it passes the ACID test (Atomicity, Consistency, Isolation, and Durability) it is still (from what I've seen) tightly coupled with a single object model, whereas an RDBMS schema can be wrappered by multiple independent object models (or even non-OO front-ends) that are tailored to specific tasks.
I'm sure Prevayler is a useful tool for some niche applications -- it sounds like it would be particuarly well suited for embedded systems or simulations. However I don't see it replacing the DRBMS for the meat-and-potatoes work of storing, retrieving, and crunching large quantaties of data.
I guess you just need to learn to use the preview button :-)
(*) The sword was never the primary weapon of the legionairre; thier primary weapons were the spear and javelin. Contrary to what Hollywood depicts, the sword was almost never a soldier's primary weapon - it was usually considered to be a backup weapon by those who could afford one. Even if you were wealthy enough to afford a sword, your primary weapon was far more likely to be a spear, lance, or other polearm; with an axe, mace, or warhammer being preferred for close combat. Certianly swords were used in combat, but it was by far the exception rather than the rule - an axe, spear, or mace was cheaper, less likely to break, and more effective against armor.
My point was that admissibility or non-admissability of polygraph data is irrelevant when your name is plastered all over the evening news.
A row in a table is an instance of an object
Foreign-keyed child tables map to collections within the parent object.
You illustrate my point perfectly about putting the cart before the horse. You don't build a database to store your objects -- you build objects to manipulate your database. A badly-designed system is one where the database was tacked on after the object model was complete. Your database schema should be the first thing you write, before you even start thinking about the classes.Unfortunately, Comp Sci cirriculums are heavy on OOP concepts but pathetically light on database theory, which is why you wind up with otherwise talented programmers who don't understand the basic fundamentals of designing solid client-server applications.
You don't use an RDBMS because it's fast. You use it because it's reliable. Does this new toy support record locking, transactional isolation and integrity, or any of the other key features that an enterprise RDBMS provides? If the answer is no, then it's not a replacement for an RDBMS. If you don't care about the integrity of your data, something like this is fine. When you absoloutely can't have data errors, you take the time to make sure you do it right, which means using an enterprise-grade database server.
While a Java-enabled cell phone may have comperable computing power to an early 80's console game, that does not mean that it's going to be easy to port an old game to it; and a cell phone or PDA isn't going to have the horsepower to run an emulator. Since Java didn't exist when these games were written (and they wouldn't have been written in it even if it had existed), you're going to have to re-write the entire game from scratch in Java. (Alternatively, you could write a compiler and support library which would allow you to compile the original source into Java bytecodes; this would be a monumental effort of dubious value)
Unfortunately, in the court of public opinion the polygraph is treated with devine reverence. A great many people (read: prospective jurors) would consider refusal to take a polygraph test to be tantamount to an admission of guilt. The basic problem is that people are gullable and stupid.
You think it's going off now, just wait until you are relocated to Camp X-Ray for "reeducation".
The Right To Keep and Bear Arms is about more than target shooting or hunting, or even about personal self-defense. The Second Amendment was put in place by our founding fathers to ensure that the People will always have the means to defend their Freedoms against would-be tyrants.
Face it, segway is an overpriced tech toy, not a practical commuter device. As a consumer product in the current economy, it's doomed. I can see it being successful as a niche product for some industrial applications but that's about it.