Our bodies are designed to operate in a virus/bacteria rich environment, and has the ability to fight of most of them.
Almost, but no design was involved. Our bodies evolved in a microbe-rich environment, as did every other living thing on Earth. The microbes were here first. We swim in a sea of microbes. Any organism incapable of surviving almost all microbe attacks would not last a day.
On changing column types, although most RDMS systems let you do it, and in many cases do so without requiring you to delete and recreate the table, a conflicting type can be a problem.
Any time the domain (type, range of allowable values) changes significantly, the database and the applications that use it may face complex changes. In a lot of cases -- changing a column from BYTE to INT, or INT to FLOAT, or even DATE to VARCHAR -- the RDBMS will convert the underlying data. In other cases the DBA has to create a new column, convert the data from the old column somehow, then delete the old column and change the name of the new one.
Changes that are type-compatible or type-convertible are easy; changes that are not easily convertible are of course hard, but that's not a unique problem with relational databases. And simply making everything a string, as XML does, is not a great solution; it just pushes the problem of type enforcement into the application, and loses valuable metadata (the domain of the column) in the process. Of course there's nothing preventing someone making every column in their relational schema a big VARCHAR, though that prevents the RDBMS from doing any type validations.
The people working on XML Query are not ignoring the history of relational databases. Heck, the language is edited by the co-inventor of SQL itself, the the Working Group chairs have been involved with (and edited) the ISO SQL spec, SQL/MM, SQLX, the JDBC and others.
I assume you are referring to Don Chamberlin. If you haven't seen it you may want to read this article from DBAzine.com: If You Liked SQL,You'll Love XQUERY.
There are several more good articles on XML databases and relational databases in general at the Database Debunkings site.
That explanation makes more sense, though you didn't defend your earlier comment about the alleged difficulty of changing a column type in an RDBMs.
It's easy to demonstrate that any hierarchical or nested data (such as a document marked up with XML) can be stored in a relational schema: the relational model is a superset of the hierarchical and network models (with much better integrity). So the question isn't can an XML database do something an RDBMs can't do, but rather does it make sense to manipulate and query XML marked-up data directly in some circumstances.
Clearly documents marked up with XML have useful applications independent of relational databases; the two technologies don't really overlap except in arguments like this one.
I think RDBMs and XML markup can be complementary. In the example you gave, for example, I would think that storing the documents in XML has many benefits, but structuring some of the elements in an RDBMs for query purposes would add a lot of performance, and perhaps allow a level of integrity enforcement that XML does not. If part numbers and applications, for example, were stored in a relational schema with the document names they applied to, one could query the RDBMs (fast) to identify the specific XML marked-up documents one was interested in, for further querying or formatting.
Whenever this XML database topic comes up it's framed as either RDBMs or XML. But relational databases solve different problems than XML markup, and the fact that some people have ignored relational technology and tried to re-invent it in terms of XML does not mean that XML is a data storage and retrieval technology. Likewise relational databases are not mark-up or full-text tools.
It's easy to create counterexamples, situations in which it is very difficult to extract data in certain ways with non-normalized data. Also, data intregrity can be guaranteed in non-normalized databases, just not by the database engine. Not without add-ons -- triggers and stored procedures, to be exact.
Of course non-normalized data can be hard to query, but that doesn't say anything about data integrity, or whether a normalized database is easier to query.
Data integrity can be implemented with triggers and stored procedures, but that isn't the same thing as a schema that guarantees integrity. A normalized schema cannot contain duplicate information (that's different from not allowing duplicates through the use of procedural code). If there's no possibility of duplication there is no need to write application code to implement integrity -- that's the whole point of normalization.
Normalization serves both purposes but when you contrast relational technology with the hierarchical databases that came before, it quickly becomes clear that the goal driving relational technology is data transparency, and normalization has a lot to do with that.
Maybe you mean that relational databases don't have invisible pointers, that everything in the database is visible. But that is not the goal driving relational technology. Read Codd's papers, or the many articles and books by Chris Date. The history of relational technology is well-documented.
If you mostly deal with the sort of data for which relational databases are generally optimised, you'll probably not be very interested in XML solutions, as they are solving problems you don't have.
That sounds like it means something, but I don't think it does. The examples that follow, "how often is part 1976 mentioned in the same repair procedure as part 2001?" or "which of our 150,000 documents have chapters containing five or more subsections any of which does not yet have a summary?" seem more like full text search problems (something Google would be good at) more than problems XML would be good at. If the data is structured it can be stored in and queried from a relational database. If it's not structured simply searching the text will work better than marking it up as XML.
With a relational database you have a lot of flexibility to change your queries but the data representation has to be static. Even changing the type of a column can be difficult in an RDBMS.
Huh? What do you mean by data representation? The database schema? Or how the data is physically stored? In a relational database the schema can be changed at any time, and a correctly-designed schema can almost always be changed without affecting queries or existing application code. Changing the type isn't difficult at all, assuming the data in the column is compatible with the new type. Or do you mean that changing a column's type will affect application code? How does XML make that easier? By making everything a string? Please explain what you mean by RDBMSs requiring static data representation, or how changing the type of a column can be difficult. All of the relational DBMSs I've used (Oracle, SQL Server, Sybase, MySQL) support changing column types and schemas very easily.
Consider the goals behind relational database normalization. It's obvious that the primary goal is one of flexibility, ensuring that the data can be sliced and diced in any way imaginable, easily (which is not always the same as efficiently).
No. Normalization eliminates duplicate information, and insures that non-key attributes are dependent on (correctly grouped with and referenced by) key fields. Normalization is not primarily about flexibility, it's primarily about data integrity.
Data can be "sliced and diced in any way imaginable" in both normalized and unnormalized databases, but data integrity can only be guaranteed in normalized databases.
For many people, earlier versions of PHP have been their first programming language.
I don't know which crowd of young programmers I'm more worried about -- those who learned PHP as their first language, or those who learned Java. I've mopped up enough amateur PHP (and ASP/VBScript) projects in the last few years. It's a flashback to the days when people learned some simple home computer BASIC and then got a job in corporate IT. Not necessarily bad, but you sure can learn a lot of bad habits, and fail to learn some good ones, if you start with the wrong language.
I think Python is a much better first language, but I have to admit it doesn't have the traction PHP has -- I use PHP for almost all of the web projects I do. But I also know enough about programming to know what parts of PHP to avoid, when OOP is overkill and when it helps, etc.
Adding more and more Java-like features to PHP is going down the wrong path. Web programmers took to PHP enthusiastically because the language is simple, the libraries are extensive (if not always robust), and you can get something working fairly fast.
If PHP continues to bloat with OOP and exceptions and perhaps static typing, it will lose its advantage and appeal. If PHP morphs into a kind of patchwork Java -- with all of the requirements and hassles but none of the grace -- programmers will just use Java.
I don't think Java is a particularly graceful or friendly language, but PHP is even less graceful (though more friendly).
I'm seeing the same thing happen in the Microsoft world, as ASP programmers get pushed into.NET. ASP/VBScript is less powerful (and less graceful) than PHP, but it is much easier to get easy things to work in old-style ASP than in.NET. Fortunately for Microsoft.NET is well-designed enough to keep most of their platform developers from looking too fondly at Java.
But PHP 5 is a base for more than mere web applications. The version 5 update readies PHP to leave the web application scope and makes it a fully blown scripting language. PHP is already being used in this context, albeit not yet fully recognized - most people still associate PHP with the web, like you did.
I know that PHP 5 is being positioned as more than a web language. I doubt it will succeed there. That space is well-served by more mature and better thought-out dynamic languages such as Perl and Python, and compiled languages such as Java and C++.
I have nothing against PHP as a general-purpose language, but I'll be a little surprised if it makes serious inroads outside of the web application domain. Maybe PHP 5 will tip the balance.
I worked on several large web projects that had non-web scripts to do various maintenance tasks (like indexing, workflow, publishing). We started to use PHP 4 for those things, thinking it would be easier to have everything in a single language. But PHP 4 proved frustrating as a general-purpose scripting language, and hard to debug. We eventually used Python and Perl for the non-web code.
The second example drags in a the whole Pear::DB class and all of its baggage, to do the exact same thing as the first example. I know that Pear::DB supports multiple database back-ends and has other conveniences, but if I don't use them, and my database back-end is unlikely to change (as is usually the case), is Pear::DB worth the extra code?
Taking the idea a step further, what about programmers who wrap Pear::DB inside more layers of abstraction:
class people { var $db;// database connection var $name; var $age;
function people() {... }
function get_person($id) {... } function save_person($id) {... } }
I've seen fairly elaborate class structures that essentially do what could be accomplished in a few lines of PHP. As for reuse, putting the common bits of code in an include file accomplishes the same thing as the classes. As I mentioned in my first post, the main benefit of classes in this situation is to get namespaces, so re-using included code is less likely to cause conflicts.
I understand that in some applications OOP techniques simplify code and encourage re-use. But in other applications OOP techniques add a lot of extra code and overhead with no actual benefit. Just doing everything with classes and objects without getting a real benefit (not just ideological satisfaction) doesn't make any sense.
If the class hierarchy (whether Pear or something else) includes hundreds or thousands of lines of interdependent code, it's hard to argue that OOP is simpliying or adding to maintainability, even if we ignore the performance issues.
I have written PHP applications that benefited from OOP techniques, but the majority of the PHP work I've done was (or would have been) simpler and faster without trying to force an OOP style on it.
I did not question OOP in PHP only for performance reasons. And I know that the web applications can maintain state on the server, including PHP applications.
If it is, then I would say that performance is the foremost non-issue of modern software development, and following Moore's law, it becomes 50% less relevant to your development approach every 18 months.
Moore's Law (a conjecture that has more or less held so far) refers to hardware; in fact it refers to the density of transistors on integrated circuits, not to performance. It does not necessarily follow that software automatically gets faster as transistor density increases. Anyone who used computers ten or twenty years ago knows that modern applications are not thousands of times faster than they were back then, even though the hardware is.
Application performance is not a non-issue. Concern for code size and performance, as it relates to programming techniques, is not the same thing as premature or micro-optimization, which is generally a bad way to write code.
Your command of buzzwords is impressive, but you didn't address my original question.
Thanks for the thoughtful reply. My question was "Does OOP make sense for web scripting." You answered a different question, something like "Explain what OOP is for."
I don't have any problem understanding OOP, thank you -- I've been programming for a long time and learned OOP in Smalltalk and C++ back when they were new.
I'm not asking whether OOP is a worthwhile technique or not. I'm asking if it makes sense, in general, for web applications, where class definitions and object instantiations and initializations are done to handle a single HTTP request.
I don't have benchmarks, but it stands to reason that defining a class, initializing objects from a persistent store, then using those objects will frequently involve more code than a non-OOP approach. Not always, but I could give some examples if the principle isn't apparent. In an interpreted language like PHP, performance is usually directly correlated to code size (again, not always). The ZEND compiler and caching mechanisms may make this a non-problem, as would using the commercial ZEND products or one of the add-on PHP caches, but in my PHP experience (4 years now) I've never known any client site to use those, and none of the ISPs I've worked with have those features installed.
Simplifying code, improving module cohesion and reducing coupling, making code easier to understand -- all of the selling points of OOP -- may offset the (possible) performance penalties. I've coded PHP both ways, I'm not persuaded that OOP makes a lot of sense given the straightforward and transient nature of many (not all) web applications. So with PHP 5 emphasizing OOP much more than PHP 4, I ask, does OOP make sense for web scripting?
If you have insightful comments or experience, great, but I don't need programming lessons or irrelevant defenses of OOP.
Does it make sense to define classes, create objects, restore objects from some serialized storage or database, etc. etc. in the context of a web application? That's a lot of scaffolding to build and tear down for every HTTP request.
OOP clearly makes sense in many applications where the class definitions and objects have a lifetime longer than a single call. And it's possible to write server-side applications that "live" longer than a single HTTP request. But that isn't the PHP execution model.
The ZEND Accelerator has clever caching and compilation mechanisms, but how many people have the Accelerator installed? How many ISPs? Without those optimizations the PHP interpreter is scanning/compiling the entire script (including all of class definitions) for each request. In that environment it makes sense to keep the scripts as short and simple as possible, not add code and complexity with OOP.
I'm not saying that OOP is a bad idea, even in PHP code. But does it make sense to implement full-blown OOP instead of using included files for common code? In my PHP 4 projects I mainly used classes to get a namespace, not for any other OOP purposes.
If you bother to make slides for a presentation, and then publish them on the web, you should take the extra minute or two and run a spell check over them. Reading something that includes misspellings and grammatical errors every other sentence is not just distracting -- it makes me wonder if the content and examples are correct.
That's my commuting vehicle of choice, but there are lots of decent motorcycles to choose from. Get a good helmet, Gore-Tex boots and gloves, an Aerostich suit, and you're all set for almost any weather. Take the MSF and/or Pridmore classes to learn defensive riding skills.
A K75S in good shape will cost $3,000 - $5,000, and you can find them for less on eBay.
> while 10 do... > How can I ensure that this cannot be exploited?
First ensure that it does what you expect. You wrote an endless loop. Who needs hackers to exploit code when programmers can't even write code that works?
You can use the online tax programs for free up to the point you either print or file. Once you get there, just use a pen to copy the final numbers from the online forms to a printed tax return form (free, as in speech/beer from the IRS, your local post office or library, etc.).
If you want to e-file to get your refund faster, your already did your taxes wrong: you over-withheld. Fix your withholding and try again this year.
If you're getting a big enough refund to be anxious about it, your are already doing your taxes wrong by having too much withheld. You should adjust your withholding (allowances) so you get the money in your paycheck rather than in the form of a tax refund.
You're better off owing $100 or less on April 15th than overwithholding all year and then figuring out how to get that refund a few days faster.
As for the simple math required on the tax forms, what a lame excuse! Get an $18 printing calculator. Go over the numbers twice. The IRS will check your calculations and correct them anyway, and in that case you have a fifty-fifty chance of getting a reduction or increase in taxes. For small discrepancies resulting from arithmetic errors you won't get into any trouble, they'll just send a refund or a bill -- don't you think they get LOTS of those already?
If you're going to defend the big refund by saying that it's a great way to save, it's not. Set up an auto-withdraw savings plan with your bank, credit union, or U.S. Treasury in the form of savings bonds. Overwithholding is just an interest-free loan to the government, and then when the "windfall" check comes you're probably going to blow it rather than save it anyway.
I also prefer the eager over the prima-donna. But not every skilled, experienced programmer acts like a prima-donna. An experienced, talented programmer who doesn't have a big ego will produce more quality work faster than an unskilled eager programmer. And I've worked with plenty of eager unskilled prima-donnas, too, and they poison the pool just as fast as the skilled ones.
Learning to program well takes a lot of time. A college degree or self-study can make for a good start, but programming well takes five to ten years to learn well, and you only learn it from experience and working with people who know more than you do.
More important than programming skill or knowledge of the latest cool languages is business experience. You might dream in XML but if you don't know accounts payable from payroll you won't be much use to a company working on accounting software. Without a degree I routinely get hired over people with more technical credentials because I know more about the business domain.
I've worked overseas, too. You'll have all of the same problems as here, with culture shock on top of that. The shock can range from mild (Canada, Australia) to extreme (India). If you can't get a job here, no foreign company will take the risk of sponsoring you. The people who get hired overseas are hired because they have unique skills and experience. Do you really think a four-year degree will make you exceptional in Bangalore?
Take it or leave it, but I've been employed without a break as a programmer/analyst for 26 years, without a degree, and I've worked at big companies like Nike and Apple that always put degree requirements in their job postings. In decreasing order of importance here's what you need to get a job:
1. Good network of friends/contacts, preferably people who have jobs. Don't pass up opportunities to socialize and meet people. To get a job you have to get an interview, and you get interviews a lot faster through contacts than you do replying to ads. A good recruiter can help, too, but you will have to work with a lot of them to find a few who have contacts and aren't sleazy.
2. Social/presentation/communication skills. Learn to write and type accurately. Join Toastmasters or a speech/debate club until you can comfortably talk to an audience. Look people in the eye when they talk to you. I can't even count how many interviewees I've seen sabotage themselves with social awkwardness and an apparent inability to communicate with other members of their species. How you present yourself is the single most important factor in most hiring decisions, and I'm not talking about which tie to wear.
3. Business domain expertise. This mostly comes from experience. Don't be too cocky, learn from the people you work with about their jobs. Learn the lingo. I've been hired over a room full of other programmers just because I know what LTL means in the trucking business.
4. Technical skills. A talented programmer can get at least conversant with a new language or technology in a few days. Some things (relational databases, web architecture, compiler design) take considerably longer and are best learned from a mentor. But employers are often happy to supply technical training or let you learn on the job if you are otherwise a good fit in the organization -- a good fit with the people.
5. Don't whine. No one cares about your unmet expectations or how your cubicle is too small. Make yourself useful to the employer before you demand to use a Mac. And when you're job hunting you aren't in a strong position to make demands, like "I only work with open source software" or "I only want to work on new projects in Java." You'll probably have to shovel shit for a while before you get to pick and choose. The boom is over and all t
...this source is not the providence of geology, but biology.
You must mean "...this source is not in the province of geology, but rather biology." If you can't choose the right words or put a sentence together you shouldn't expect anyone to give a lot of weight to whatever it is you're trying to say. And don't try to sound so fancy if you're going to trip over yourself: "the opals are formed through a biological rather than a geological process."
Also I'm sure the weevil "grows opal on its back," not on it's back, which would mean "on it is back."
providence: (1) Care or preparation in advance; foresight. (2) Prudent management; economy. (3) The capital of the state of Rhode Island.
Provence: A historical region and former province of southeast France bordering on the Mediterranean Sea.
province: (1) A territory governed as an administrative or political unit of a country or empire. (2) A division of territory under the jurisdiction of an archbishop. (3) A comprehensive area of knowledge, activity, or interest: a topic falling within the province of ancient history. (4) The range of one's proper duties and functions; scope or jurisdiction. (5) Ecology. An area of land, less extensive than a region, having a characteristic plant and animal population.
provenance: (1) Place of origin; derivation. (2) Proof of authenticity or of past ownership. Used of art works and antiques.
You had better learn the shift PATTERN pretty quick, though there aren't a lot of variations because you only have up and down clicks to work with. I agree that determining the gear from the sound or the RPM is not always easy, but unless you're racing or trying for maximum fuel efficiency it's also not important. Experienced riders go by the sound and feel of the bike -- we're more connected to the engine than a car driver is. I'm not talking about racing or other special conditions (or squids), just everyday riding and touring. If my instruments were unplugged the only ones I'd miss are the clock and the trip odometer (no fuel gauge on either of my bikes).
I suppose squids who spend more on their sunglasses than on their helmet, and who ride with headphones blasting hip-hop music in their ears, probably need the instruments because they can't hear the bike. And people who outfit their bikes with exhausts that always rumble and roar may need HUD because they're going deaf.
My BMW mechanic used to advise me to redline my bike for a few minutes every once in a while to clear out the carbon and to remember what the bike sounds like at redline. Again unless you're racing or doing something special the actual RPMs are not really important; the bike tells you when it's overrevving or lugging.
I wouldn't mind HUD on my helmet or windscreen for clock, miles, speed, and some warning lights, but I already have those things (and more) available with a quick downward glance/scan (no head movement needed on either of my bikes). I would prefer them to be just outside the center of the field of view, but not on the periphery -- the edges are where you don't want any blockage because that's where the SUV/bicyclist/deer/truck tire will first appear.
Although my K75S has a gear indicator I don't usually look at it and I agree that it's kind of a wuss instrument.
Remember: always ride with two fingers over the front brake. Sounds like you've been to Pridmore's CLASS. The squid version: always ride with two twos over the rear brake, but don't let the flip-flop sandal fall off.
My bike (BMW K75S) has the usual instruments: speedo, tach, odometer, gear indicator, clock, high beam indicator, low fuel indicator, idiot lights. I don't need to look at any of them to ride. People who actually ride usually know what gear they're in. You listen to the engine for RPMs and to tell if you need to shift. The speedo is just as unimportant as it is in a car--you are either going too slow or too fast for the traffic and conditions, and if you can't determine that without a speedometer you shouldn't be on a bike, or even on the road.
I imagine that changing visual focus to see those indicators on my visor would take about as much time as glancing down. I only do it at a safe moment, not when surrounded by idiots in Escalades and Yukons trying to merge onto the freeway while watching DVDs and playing with their On*Star.
As the MSF instructor pointed out, alcohol and drugs account for way too many motorcycle accidents and injuries. Inexperienced riders and people who spend all their money dressing up their bad-ass Harley with chrome skulls and leather fringe but didn't want to take a wussy riding class just drive insurance rates up for the rest of us. And what instruments do you need to ride from home to the nearest fake biker bar every Friday night?
If you don't ride or don't know anything about motorcycles, shut up. We've already heard the witty organ donor jokes, thanks. They're about as clever as a five-year-old saying "poop."
You're making a lot of fuss over nothing. If you simply move overseas and keep your U.S. bank account open, get your paychecks direct deposited, and don't cause any fuss, the state of California will never know or care where you live. No one will investigate or sue on your behalf against your will. You file your tax returns and I promise the IRS and Calif. Dept of Revenue don't care where you live as long as you pay.
Getting money out of your U.S. bank in Tokyo is easy: just use your ATM card, or transfer the money online to a U.S. credit card account (you'll get better exchange rates).
The same principle would apply if you contracted: if neither party (you or your employer) complain the state won't know or care what's going on. And if you're contracting a bunch of labor laws go away... again no one from the state is going to investigate a case of ONE stray contractor, assuming they had reason to come around in the first place. Unless your employer has lots of dicey foreign employees already they will never get a visit from the INS. Those people have their hands full with real illegal immigrants and abusive employers to chase down theoretical abuses like you're describing.
Simply getting on a plane to Japan is not going to trigger any investigation by the labor dept. Just go, get your paychecks, and stop worrying about it. I lived and worked on and off in England working for both U.S. and English companies, and the only government agencies that ever care are the tax authorities.
What a dipshit. I wrote 'scrotii' to MAKE FUN of people who write 'virii' and other fake plurals on slashdot. If you can't tell that the entire post is a satirical version of the original, practically word-for-word, I feel sorry for your humorless existence.
Slashdot Mirror
Our bodies are designed to operate in a virus/bacteria rich environment, and has the ability to fight of most of them.
Almost, but no design was involved. Our bodies evolved in a microbe-rich environment, as did every other living thing on Earth. The microbes were here first. We swim in a sea of microbes. Any organism incapable of surviving almost all microbe attacks would not last a day.
If You Liked SQL,You'll Love XQUERY .
There are several more good articles on XML databases and relational databases in general at the Database Debunkings site.
That explanation makes more sense, though you didn't defend your earlier comment about the alleged difficulty of changing a column type in an RDBMs.
It's easy to demonstrate that any hierarchical or nested data (such as a document marked up with XML) can be stored in a relational schema: the relational model is a superset of the hierarchical and network models (with much better integrity). So the question isn't can an XML database do something an RDBMs can't do, but rather does it make sense to manipulate and query XML marked-up data directly in some circumstances.
Clearly documents marked up with XML have useful applications independent of relational databases; the two technologies don't really overlap except in arguments like this one.
I think RDBMs and XML markup can be complementary. In the example you gave, for example, I would think that storing the documents in XML has many benefits, but structuring some of the elements in an RDBMs for query purposes would add a lot of performance, and perhaps allow a level of integrity enforcement that XML does not. If part numbers and applications, for example, were stored in a relational schema with the document names they applied to, one could query the RDBMs (fast) to identify the specific XML marked-up documents one was interested in, for further querying or formatting.
Whenever this XML database topic comes up it's framed as either RDBMs or XML. But relational databases solve different problems than XML markup, and the fact that some people have ignored relational technology and tried to re-invent it in terms of XML does not mean that XML is a data storage and retrieval technology. Likewise relational databases are not mark-up or full-text tools.
Of course non-normalized data can be hard to query, but that doesn't say anything about data integrity, or whether a normalized database is easier to query.
Data integrity can be implemented with triggers and stored procedures, but that isn't the same thing as a schema that guarantees integrity. A normalized schema cannot contain duplicate information (that's different from not allowing duplicates through the use of procedural code). If there's no possibility of duplication there is no need to write application code to implement integrity -- that's the whole point of normalization.
Maybe you mean that relational databases don't have invisible pointers, that everything in the database is visible. But that is not the goal driving relational technology. Read Codd's papers, or the many articles and books by Chris Date. The history of relational technology is well-documented.
For many people, earlier versions of PHP have been their first programming language.
I don't know which crowd of young programmers I'm more worried about -- those who learned PHP as their first language, or those who learned Java. I've mopped up enough amateur PHP (and ASP/VBScript) projects in the last few years. It's a flashback to the days when people learned some simple home computer BASIC and then got a job in corporate IT. Not necessarily bad, but you sure can learn a lot of bad habits, and fail to learn some good ones, if you start with the wrong language.
I think Python is a much better first language, but I have to admit it doesn't have the traction PHP has -- I use PHP for almost all of the web projects I do. But I also know enough about programming to know what parts of PHP to avoid, when OOP is overkill and when it helps, etc.
I'll be pleased when PHP gets static typing.
Why? If you want that just use Java.
Adding more and more Java-like features to PHP is going down the wrong path. Web programmers took to PHP enthusiastically because the language is simple, the libraries are extensive (if not always robust), and you can get something working fairly fast.
If PHP continues to bloat with OOP and exceptions and perhaps static typing, it will lose its advantage and appeal. If PHP morphs into a kind of patchwork Java -- with all of the requirements and hassles but none of the grace -- programmers will just use Java.
I don't think Java is a particularly graceful or friendly language, but PHP is even less graceful (though more friendly).
I'm seeing the same thing happen in the Microsoft world, as ASP programmers get pushed into .NET. ASP/VBScript is less powerful (and less graceful) than PHP, but it is much easier to get easy things to work in old-style ASP than in .NET. Fortunately for Microsoft .NET is well-designed enough to keep most of their platform developers from looking too fondly at Java.
But PHP 5 is a base for more than mere web applications. The version 5 update readies PHP to leave the web application scope and makes it a fully blown scripting language. PHP is already being used in this context, albeit not yet fully recognized - most people still associate PHP with the web, like you did.
I know that PHP 5 is being positioned as more than a web language. I doubt it will succeed there. That space is well-served by more mature and better thought-out dynamic languages such as Perl and Python, and compiled languages such as Java and C++.
I have nothing against PHP as a general-purpose language, but I'll be a little surprised if it makes serious inroads outside of the web application domain. Maybe PHP 5 will tip the balance.
I worked on several large web projects that had non-web scripts to do various maintenance tasks (like indexing, workflow, publishing). We started to use PHP 4 for those things, thinking it would be easier to have everything in a single language. But PHP 4 proved frustrating as a general-purpose scripting language, and hard to debug. We eventually used Python and Perl for the non-web code.
Let me add an example of what I'm getting at. Is this:
Somehow worse or less preferable than this:
The second example drags in a the whole Pear::DB class and all of its baggage, to do the exact same thing as the first example. I know that Pear::DB supports multiple database back-ends and has other conveniences, but if I don't use them, and my database back-end is unlikely to change (as is usually the case), is Pear::DB worth the extra code?
Taking the idea a step further, what about programmers who wrap Pear::DB inside more layers of abstraction:
I've seen fairly elaborate class structures that essentially do what could be accomplished in a few lines of PHP. As for reuse, putting the common bits of code in an include file accomplishes the same thing as the classes. As I mentioned in my first post, the main benefit of classes in this situation is to get namespaces, so re-using included code is less likely to cause conflicts.
I understand that in some applications OOP techniques simplify code and encourage re-use. But in other applications OOP techniques add a lot of extra code and overhead with no actual benefit. Just doing everything with classes and objects without getting a real benefit (not just ideological satisfaction) doesn't make any sense.
If the class hierarchy (whether Pear or something else) includes hundreds or thousands of lines of interdependent code, it's hard to argue that OOP is simpliying or adding to maintainability, even if we ignore the performance issues.
I have written PHP applications that benefited from OOP techniques, but the majority of the PHP work I've done was (or would have been) simpler and faster without trying to force an OOP style on it.
Thanks for answering your own questions.
I did not question OOP in PHP only for performance reasons. And I know that the web applications can maintain state on the server, including PHP applications.
If it is, then I would say that performance is the foremost non-issue of modern software development, and following Moore's law, it becomes 50% less relevant to your development approach every 18 months.
Moore's Law (a conjecture that has more or less held so far) refers to hardware; in fact it refers to the density of transistors on integrated circuits, not to performance. It does not necessarily follow that software automatically gets faster as transistor density increases. Anyone who used computers ten or twenty years ago knows that modern applications are not thousands of times faster than they were back then, even though the hardware is.
Application performance is not a non-issue. Concern for code size and performance, as it relates to programming techniques, is not the same thing as premature or micro-optimization, which is generally a bad way to write code.
Your command of buzzwords is impressive, but you didn't address my original question.
Thanks for the thoughtful reply. My question was "Does OOP make sense for web scripting." You answered a different question, something like "Explain what OOP is for."
I don't have any problem understanding OOP, thank you -- I've been programming for a long time and learned OOP in Smalltalk and C++ back when they were new.
I'm not asking whether OOP is a worthwhile technique or not. I'm asking if it makes sense, in general, for web applications, where class definitions and object instantiations and initializations are done to handle a single HTTP request.
I don't have benchmarks, but it stands to reason that defining a class, initializing objects from a persistent store, then using those objects will frequently involve more code than a non-OOP approach. Not always, but I could give some examples if the principle isn't apparent. In an interpreted language like PHP, performance is usually directly correlated to code size (again, not always). The ZEND compiler and caching mechanisms may make this a non-problem, as would using the commercial ZEND products or one of the add-on PHP caches, but in my PHP experience (4 years now) I've never known any client site to use those, and none of the ISPs I've worked with have those features installed.
Simplifying code, improving module cohesion and reducing coupling, making code easier to understand -- all of the selling points of OOP -- may offset the (possible) performance penalties. I've coded PHP both ways, I'm not persuaded that OOP makes a lot of sense given the straightforward and transient nature of many (not all) web applications. So with PHP 5 emphasizing OOP much more than PHP 4, I ask, does OOP make sense for web scripting?
If you have insightful comments or experience, great, but I don't need programming lessons or irrelevant defenses of OOP.
Does it make sense to define classes, create objects, restore objects from some serialized storage or database, etc. etc. in the context of a web application? That's a lot of scaffolding to build and tear down for every HTTP request.
OOP clearly makes sense in many applications where the class definitions and objects have a lifetime longer than a single call. And it's possible to write server-side applications that "live" longer than a single HTTP request. But that isn't the PHP execution model.
The ZEND Accelerator has clever caching and compilation mechanisms, but how many people have the Accelerator installed? How many ISPs? Without those optimizations the PHP interpreter is scanning/compiling the entire script (including all of class definitions) for each request. In that environment it makes sense to keep the scripts as short and simple as possible, not add code and complexity with OOP.
I'm not saying that OOP is a bad idea, even in PHP code. But does it make sense to implement full-blown OOP instead of using included files for common code? In my PHP 4 projects I mainly used classes to get a namespace, not for any other OOP purposes.
If you bother to make slides for a presentation, and then publish them on the web, you should take the extra minute or two and run a spell check over them. Reading something that includes misspellings and grammatical errors every other sentence is not just distracting -- it makes me wonder if the content and examples are correct.
That's my commuting vehicle of choice, but there are lots of decent motorcycles to choose from. Get a good helmet, Gore-Tex boots and gloves, an Aerostich suit, and you're all set for almost any weather. Take the MSF and/or Pridmore classes to learn defensive riding skills.
A K75S in good shape will cost $3,000 - $5,000, and you can find them for less on eBay.
> while 10 do ...
> How can I ensure that this cannot be exploited?
First ensure that it does what you expect. You wrote an endless loop. Who needs hackers to exploit code when programmers can't even write code that works?
You can use the online tax programs for free up to the point you either print or file. Once you get there, just use a pen to copy the final numbers from the online forms to a printed tax return form (free, as in speech/beer from the IRS, your local post office or library, etc.).
If you want to e-file to get your refund faster, your already did your taxes wrong: you over-withheld. Fix your withholding and try again this year.
If you're getting a big enough refund to be anxious about it, your are already doing your taxes wrong by having too much withheld. You should adjust your withholding (allowances) so you get the money in your paycheck rather than in the form of a tax refund.
You're better off owing $100 or less on April 15th than overwithholding all year and then figuring out how to get that refund a few days faster.
As for the simple math required on the tax forms, what a lame excuse! Get an $18 printing calculator. Go over the numbers twice. The IRS will check your calculations and correct them anyway, and in that case you have a fifty-fifty chance of getting a reduction or increase in taxes. For small discrepancies resulting from arithmetic errors you won't get into any trouble, they'll just send a refund or a bill -- don't you think they get LOTS of those already?
If you're going to defend the big refund by saying that it's a great way to save, it's not. Set up an auto-withdraw savings plan with your bank, credit union, or U.S. Treasury in the form of savings bonds. Overwithholding is just an interest-free loan to the government, and then when the "windfall" check comes you're probably going to blow it rather than save it anyway.
I also prefer the eager over the prima-donna. But not every skilled, experienced programmer acts like a prima-donna. An experienced, talented programmer who doesn't have a big ego will produce more quality work faster than an unskilled eager programmer. And I've worked with plenty of eager unskilled prima-donnas, too, and they poison the pool just as fast as the skilled ones.
Learning to program well takes a lot of time. A college degree or self-study can make for a good start, but programming well takes five to ten years to learn well, and you only learn it from experience and working with people who know more than you do.
See Peter Norvig's excellent article Teach Yourself Programming in Ten Years and some comments on Philip Greenspun's blog.
More important than programming skill or knowledge of the latest cool languages is business experience. You might dream in XML but if you don't know accounts payable from payroll you won't be much use to a company working on accounting software. Without a degree I routinely get hired over people with more technical credentials because I know more about the business domain.
I've worked overseas, too. You'll have all of the same problems as here, with culture shock on top of that. The shock can range from mild (Canada, Australia) to extreme (India). If you can't get a job here, no foreign company will take the risk of sponsoring you. The people who get hired overseas are hired because they have unique skills and experience. Do you really think a four-year degree will make you exceptional in Bangalore?
Take it or leave it, but I've been employed without a break as a programmer/analyst for 26 years, without a degree, and I've worked at big companies like Nike and Apple that always put degree requirements in their job postings. In decreasing order of importance here's what you need to get a job:
1. Good network of friends/contacts, preferably people who have jobs. Don't pass up opportunities to socialize and meet people. To get a job you have to get an interview, and you get interviews a lot faster through contacts than you do replying to ads. A good recruiter can help, too, but you will have to work with a lot of them to find a few who have contacts and aren't sleazy.
2. Social/presentation/communication skills. Learn to write and type accurately. Join Toastmasters or a speech/debate club until you can comfortably talk to an audience. Look people in the eye when they talk to you. I can't even count how many interviewees I've seen sabotage themselves with social awkwardness and an apparent inability to communicate with other members of their species. How you present yourself is the single most important factor in most hiring decisions, and I'm not talking about which tie to wear.
3. Business domain expertise. This mostly comes from experience. Don't be too cocky, learn from the people you work with about their jobs. Learn the lingo. I've been hired over a room full of other programmers just because I know what LTL means in the trucking business.
4. Technical skills. A talented programmer can get at least conversant with a new language or technology in a few days. Some things (relational databases, web architecture, compiler design) take considerably longer and are best learned from a mentor. But employers are often happy to supply technical training or let you learn on the job if you are otherwise a good fit in the organization -- a good fit with the people.
5. Don't whine. No one cares about your unmet expectations or how your cubicle is too small. Make yourself useful to the employer before you demand to use a Mac. And when you're job hunting you aren't in a strong position to make demands, like "I only work with open source software" or "I only want to work on new projects in Java." You'll probably have to shovel shit for a while before you get to pick and choose. The boom is over and all t
...this source is not the providence of geology, but biology.
You must mean "...this source is not in the province of geology, but rather biology." If you can't choose the right words or put a sentence together you shouldn't expect anyone to give a lot of weight to whatever it is you're trying to say. And don't try to sound so fancy if you're going to trip over yourself: "the opals are formed through a biological rather than a geological process."
Also I'm sure the weevil "grows opal on its back," not on it's back, which would mean "on it is back."
providence: (1) Care or preparation in advance; foresight. (2) Prudent management; economy. (3) The capital of the state of Rhode Island.
Provence: A historical region and former province of southeast France bordering on the Mediterranean Sea.
province: (1) A territory governed as an administrative or political unit of a country or empire. (2) A division of territory under the jurisdiction of an archbishop. (3) A comprehensive area of knowledge, activity, or interest: a topic falling within the province of ancient history. (4) The range of one's proper duties and functions; scope or jurisdiction. (5) Ecology. An area of land, less extensive than a region, having a characteristic plant and animal population.
provenance: (1) Place of origin; derivation. (2) Proof of authenticity or of past ownership. Used of art works and antiques.
You had better learn the shift PATTERN pretty quick, though there aren't a lot of variations because you only have up and down clicks to work with. I agree that determining the gear from the sound or the RPM is not always easy, but unless you're racing or trying for maximum fuel efficiency it's also not important. Experienced riders go by the sound and feel of the bike -- we're more connected to the engine than a car driver is. I'm not talking about racing or other special conditions (or squids), just everyday riding and touring. If my instruments were unplugged the only ones I'd miss are the clock and the trip odometer (no fuel gauge on either of my bikes).
I suppose squids who spend more on their sunglasses than on their helmet, and who ride with headphones blasting hip-hop music in their ears, probably need the instruments because they can't hear the bike. And people who outfit their bikes with exhausts that always rumble and roar may need HUD because they're going deaf.
My BMW mechanic used to advise me to redline my bike for a few minutes every once in a while to clear out the carbon and to remember what the bike sounds like at redline. Again unless you're racing or doing something special the actual RPMs are not really important; the bike tells you when it's overrevving or lugging.
I wouldn't mind HUD on my helmet or windscreen for clock, miles, speed, and some warning lights, but I already have those things (and more) available with a quick downward glance/scan (no head movement needed on either of my bikes). I would prefer them to be just outside the center of the field of view, but not on the periphery -- the edges are where you don't want any blockage because that's where the SUV/bicyclist/deer/truck tire will first appear.
Although my K75S has a gear indicator I don't usually look at it and I agree that it's kind of a wuss instrument.
'93 BMW K75S -- '73 Honda CB350/4
I can see it now, mounted on the helmets of Gold Wing riders everywhere, helping them know the speed at which they are adjusting their radio pre-sets.
Don't laugh. If it's (a) expensive and (b) lame someone will fit it to a Gold Wing. Just look at this: landing gear (or training wheels) for Gold Wings.
Remember: always ride with two fingers over the front brake. Sounds like you've been to Pridmore's CLASS. The squid version: always ride with two twos over the rear brake, but don't let the flip-flop sandal fall off.
My bike (BMW K75S) has the usual instruments: speedo, tach, odometer, gear indicator, clock, high beam indicator, low fuel indicator, idiot lights. I don't need to look at any of them to ride. People who actually ride usually know what gear they're in. You listen to the engine for RPMs and to tell if you need to shift. The speedo is just as unimportant as it is in a car--you are either going too slow or too fast for the traffic and conditions, and if you can't determine that without a speedometer you shouldn't be on a bike, or even on the road.
I imagine that changing visual focus to see those indicators on my visor would take about as much time as glancing down. I only do it at a safe moment, not when surrounded by idiots in Escalades and Yukons trying to merge onto the freeway while watching DVDs and playing with their On*Star.
As the MSF instructor pointed out, alcohol and drugs account for way too many motorcycle accidents and injuries. Inexperienced riders and people who spend all their money dressing up their bad-ass Harley with chrome skulls and leather fringe but didn't want to take a wussy riding class just drive insurance rates up for the rest of us. And what instruments do you need to ride from home to the nearest fake biker bar every Friday night?
If you don't ride or don't know anything about motorcycles, shut up. We've already heard the witty organ donor jokes, thanks. They're about as clever as a five-year-old saying "poop."
You're making a lot of fuss over nothing. If you simply move overseas and keep your U.S. bank account open, get your paychecks direct deposited, and don't cause any fuss, the state of California will never know or care where you live. No one will investigate or sue on your behalf against your will. You file your tax returns and I promise the IRS and Calif. Dept of Revenue don't care where you live as long as you pay.
Getting money out of your U.S. bank in Tokyo is easy: just use your ATM card, or transfer the money online to a U.S. credit card account (you'll get better exchange rates).
The same principle would apply if you contracted: if neither party (you or your employer) complain the state won't know or care what's going on. And if you're contracting a bunch of labor laws go away... again no one from the state is going to investigate a case of ONE stray contractor, assuming they had reason to come around in the first place. Unless your employer has lots of dicey foreign employees already they will never get a visit from the INS. Those people have their hands full with real illegal immigrants and abusive employers to chase down theoretical abuses like you're describing.
Simply getting on a plane to Japan is not going to trigger any investigation by the labor dept. Just go, get your paychecks, and stop worrying about it. I lived and worked on and off in England working for both U.S. and English companies, and the only government agencies that ever care are the tax authorities.
What a dipshit. I wrote 'scrotii' to MAKE FUN of people who write 'virii' and other fake plurals on slashdot. If you can't tell that the entire post is a satirical version of the original, practically word-for-word, I feel sorry for your humorless existence.