a) Hiring b) were not outsourcing development c) don't have things under control already d) aren't retraining existing staff e) use public recruiting strategies f) don't have other systems that are more important in other languagess.
Statistically, staff will turn over in all areas of a company, so job adverts will be a good sample of what is going on.
I'm not your personal research assistant.
Meaning you aren't going to back your assertions?
You said something that was based on the worst evidence I've seen in a long time - and got called out.
Calling out is when you prove someone wrong.
I did give some hints as to where you can find some informaiton. Perhaps you should add PHP.org to the list - I hear it gets a little traffic:)
PHP is not LAMP! LAMP is Linux AND Apache AND MySQL AND PHP/PERL or Python.
Yet again.. where are the large number of major high-volume robust transactional sites that run on this combination of technologies? PHP has major scalability issues because of a lack of application-level cacheing; MySQL has only in recent releases provided industrial-strength SQL compatibility.
God of the Gaps? Does he rule the space between the platform and subway cars?
In case this does need explanation....
'God of the Gaps' describes a philosophical point of view in which God (or some other intelligence or higher power) is given as the explanation things we don't understand ('gaps' in our knowledge).
The real theory of Intelligent Design doesn't eliminate evolution.
There is no 'theory' of intelligent design. If there were, there would have to be testable evidence and predictions from it. Simply saying 'this feature is too complex for me to believe that it could have evolved' is not a theory!
Intelligent Design is a 'God of the Gaps' type of philosophical position that can never be falsified, simply (hopefully) reduced to irrelevance as more and more aspects of evolution are explained.
Let's not assume so quickly that anything other than paper will be easily readable in 25 years.
One of the design considerations for XML (which is the format that Open Office uses) is that documents which are in this format should be human-readable, specifically to avoid the problem of future data loss.
"LAMP handles a lot less of those sites than you might think. Check up on job adverts for Google, Amazon etc. and you will find a strong demand for Java and C++ as well as LAMP."
This makes absolutely no sense:
Of course it makes sense! The companies hire employees to maintain and adapt current software implementations. Job adverts indicate the range of systems and languages that are used in those
It's kind of like:
We have a low murder rate in Detroit because the department of corrections isn't hiring executioners right now.
No - its like 'we believe have a low murder rate in Detroit because we note there are few openings for criminals':)
Job listings do not indicate what is in production except on the system needing attention at the organization needing the employee.
So you imagine that LAMP systems are so perfect they need no attention?
Assertion: There aren't that many huge-ass LAMP sites on the internet.
I'd be interested to know how many 'huge-ass' sites actually use Linux + Apache + MySQL + PHP/Python/PERL for the majority of their software. I'm certainly not saying that there aren't any; just that I don't know of that many.
Linux is widely used, but so is Solaris! Apache is very common, and so are PERL or Python and PHP, but so are Java and Oracle!
Can you provide evidence of a really high-volume site that runs primarily on LAMP? (Just because a site runs on Linux, or uses Python does NOT make it LAMP!)
Let's look at common sites:
eBay: Java/J2EE on Linux and Solaris + Oracle
Amazon: Uses a range of technologies, including Oracle on Linux clusters.
Google: Uses a wide range of technologies, including Python, C, C++, Java, PHP, Oracle MySQL, and Linux.
If LAMP can scale well enought to handle some of the biggest sites on the INTERNET, I think it can scale to handle a company intranet.
LAMP handles a lot less of those sites than you might think. Check up on job adverts for Google, Amazon etc. and you will find a strong demand for Java and C++ as well as LAMP.
This also depends on what you mean by 'scale'. Handling lots of mainly read-only requests is not difficult; but handling transactions, where data has to be frequently and rapidly changed is fundamentally different. Good examples of this are stock market sites where servers may need to handle tens of thousands of transactions per second. This sort of thing requires very sophisticated transaction handling, messaging, and cacheing and LAMP usually just can't cut it; at least not by itself.
Some of the biggest sites which use LAMP can overcome scalability issues with systems like huge server farms. Other sites (like Stock Exchanges) may need to ensure very high performance at the same time as transactional integrity on just a few clustered servers. It is OK if google forgets your search - it is a disaster if a stock exchange or 'well known auction site' looses your bid or funds transfer!
The plain fact of the matter is that to get funding today in various related disciplines to climatology you have to climb on the global warming bandwagon. Sad, but true.
It's not sad at all - it's called 'science' - ideas become popular and are tested by evidence. The so-called 'global warming bandwagon' is rolling on because it is backed by real reproducible evidence that is getting stronger every month.
The only contender in the long run I see currently is Ruby, with their excellent rails framework.
I would hardly call a framework where the object model has to be defined as database tables, and you then end up locked into a particular database product for the lifetime of your application 'excellent'. Compared to other systems, like Hibernate, where data can be defined as true objects, this is a huge step backwards.
No, it is a theory supported by computer models that may or may not have any relation to reality.
No, it is actual warming that has been actually measured, and is plain to see in areas like Sibera and Arctic ice thickness.
I would challenge the notion that it is necessarily related to any man-related activity (that's for another post if anyone is interested). The only constant about the climate on this planet is change and that has been true since it accreted to a planet.
Change is not good, especially fast change over decades.
To believe that it is not related to man-related activity is to deny that an increase in 1/3 of CO2 levels (which IS man-made) will have no effect. To deny that is simply scientific nonsense.
What you forgot is the whole, its happened hundreds of times over the course of the Earths history from multiple different reasons, making it useless to think humans can stop it, or even SHOULD stop it
Assuming we can't stop it means assuming we aren't responsible. We certainly seem to be. Global warming has certainly happened before, but not this fast (apart from the occasional asteroid collision!).
And the fact remains there is a failsafe people forget. Once the earth gets too warm and the seas grow too big... they reflect the solar energy and become.... yes you guessed it ICE.
Wrong way around. Ice reflects far more heat than water. The more the ice melts, the warmer things get...
yep, will we survive? We have 3 other times already.
Ah, but you're not allowing for species drift, hybridization - which has occurred in supposedly inactive non-reproducing species, or point mutations.
I certainly am allowing for this. Such mutations have been occurring throughout the long history of life on this planet. If a successful general microbial parasite could exist, it would have evolved at some point over several billion years.
Solar radiation alone can have interesting effects, especially in areas where the ozone layer is not available - for example much of Australia and Argentina and South Africa.
There has been plenty of time for natural mutagens and radiation to have had interesting effects for millions of years. A recent decrease in the ozone layer is nothing by comparison.
until we build the beasties, we won't know exactly what they do. even bioengineering luminescence can act differently if it escapes.
This sounds like too much influence from X-Men and Fantastic Four! Just because things mutate, and we don't know what they might do, does not mean that we will magically produce some super-powered bug that has the amazing ability to attack and digest all the thousands of different types of plant cells, as implied by one of the parent posts way back.
Cross-species parasitic organisms are fairly common, as a recent work by some European scientists in France and the UK said, with a publication date of 2005, and unpredicatable results can happen even by removing quail from a parasitic ecosystem, as many parasites have multiple hosts in their life cycles, including backup or reserve (temporary/seasonal) hosts.
This completely different from some hypothetical 'general' parasite which can happly munch through a large variety of plants. Having very specific organisms for different parts of a lifecycle does not mean that a parasite is non-specific - just that the specificity changes. Having one or two backup species does not make a parasite 'general'.
So, I disagree. It only needs to utilize the other plants and metabolize enough to survive until it gets to its desired or sufficiently optimal source, but that won't stop it's behavior, especially if it's a primitive organism.
Yes, but what plants can it utilize? One or two, perhaps, but as I said there are no general non-specific microbial parasites (or none that I know of).
So, from my viewpoint, the concept of manufacturing an organism to crank out oil needs to be thought thru quite a bit - what if it harvests not just the biowaste of corn husks but starts eating grasses and other plant life?
This is extremely unlikely to happen. Different plant species have different proteins and biochemicals, and an organism tailored to deal with the product of one plant is not going to be effective at dealing with those of others. This is why parasitic organisms and infective bacteria, viruses and fungi are so specific to particular species.
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 1
There are a bazillion frameworks for object-caching that don't require careful thread management. PHP doesn't even give you the opportunity.
True, but you don't persuade developers to switch by insulting them.... (as the grandparent post did)
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 1
Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
I have to disagree. The average JDBC application explicitly extracts information for all columns, and the relationship between columns and Java variables can be tested either by compilation or by unit tests.
Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
It is very bad! The point of systems like Hibernate and JDO and EJB3 is to progress away from database dependence. Rails encourages dependence on database schemas. This is something many of us have been trying to move away from for years.
Rails is a huge step back to the way things were a decade ago.
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 2, Insightful
That said, Ruby on Rails is amazing. If java isn't your bag, check it out. It has most of the best features of Java and PHP, almost none of the warts, and a whole bunch of great stuff you won't find anywhere else.
After all your praising of Hibernate, how can you recommend this? Hibernate is an elegant and robust ORM that isolates your code from database specifics and allows you to write highly portable applications. Ruby on Rails requires exactly the kind of embedded SQL you don't like if you are to do anything complex, and makes your application extremely dependent on the database schema and the specific column names contained within it, and has serious barriers to portability.
I agree strongly with almost every aspect of your post, but certainly not this last part!
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 1
I don't usually post to defend those I am debating against, however...
Gonzo is back again. Sweet jebus you are dense.
This is totally unfair. The poster is asking questions I would expect from someone experienced with the PHP way of working. They are intelligent questions.
So what you are telling me is, it's ok to hit the server for a piece of data that isn't changing soon or is complex to get? Lemme guess, calculate and store it in another table? Ugh. Amature.
It is not that simple. Fetching data for each request or each session can be useful in some ways. It allows all all the data relating to an application to be changed without having to restart an application - effectively shutting down the web application. Changing application-scope data in Java is possible, but it requires careful and thread management.
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 2, Insightful
"It is simply not practical to drop through to the database to reload information each time when you have hundreds or thousands of simultaneous users."
It is. I've worked on a site (NB: NOT my URL!) that handles greater traffic than that, with a large number of DB requests on a large proportion of pages. NOT written in PHP. But not even running on a box of its own..
It is not practical for anything but the simplest and smallest of data items. If it were, sites like E-Bay and high-volume stock markets would work like this. They don't.
If you want a dynamic web site, you have to mix HTML with something at some point. It may be characters in a file, string delimiters, php delimiters, whatever.
Yes, but what you don't want to mix is logic. Someone should not have to look through lines of HTML to see how you are doing a price calculation!
Generally, web frameworks have specialised tags that are included in the middle of HTML to indicate where the results of processing are to be included.
I don't see anything in the PHP language itself any different from any other language in this regard. HTML is just a bunch of strings; PHP can be written with nothing outside of the ?php... ? at all.
You can, but the mere fact you have those enclosing symbols indicates that the language was designed to allow embedding in HTML, and not to discourage it.
"Filters allow specific ranges of URLs to have additional functionality wrapped around the requests. This is a highly useful feature, allowing things like post-processing of HTML, or checking authorisation (and diverting to error pages)." Forgive me if this sounds flippant, but isn't that something than can be achieved with an array, a regexp or two, and REQUEST_URI?
It can, but why bother re-implementing this each time? Filter APIs allow Filter classes to be written in just a few lines of code.
Is this something actually within the language itself?
No. It is a standard part of the JSP/Servlet API, which is a subset of J2EE.
"Having logic in the database does not seem to be practical for high-load systems."
First of all, based on what research?
Real websites.
There are incredibly large systems based on keeping business logic in the database. Just last week at OSCON I met several people who are running primary systems on PostgreSQL, some inserting several GB a day of new data. That seems pretty high-load to me.
That is not high load! I am talking about sites that have have thousands or tens of thousands of concurrent users, all requiring access to data which can be altered. Sites like E-Bay, or stock markets use Java, cacheing and ORM to minimise contacts with the database wherever possible.
What magic is there that means re-implementing constraints in Java would be somehow faster than the implementation of most serious DBMSs, which are written in C and usually have many more years of research and stability behind them?
The magic is transparency. It allows business logic and data structures to be set up and used without having to embed the logic of caching, constraints and transactions.
Considering the very widespread use of Java and J2EE for this purpose in almost all aspects of finance and commerce, there are no doubts as to its stability.
Thus the greatly increased possibility that the system will be compromised, because a change in logic here might not be dealt with over there.
Not at all. There are very well-established and widely uses systems like JTA (Java Transaction API) that work with J2EE application servers like WebSphere. These co-ordinate transactions transparently all the way from the web page code down to database access. There is no risk of compromise.
Anyway, if performance is your only reason for not keeping logic centralized then wouldn't you agree that that is either a result of bad implementation on the database side (I mean in the storage implementation of the DBMS itself), or a sacrifice of integrity on the application side?
No. Databases have their function, which is to maintain relational data. They are not suited to general OOP coding which is now the norm for most commercial development. Also, relational systems were never designed for performance! Some of the very highest performance data stores (such the data collection systems at CERN, which deal with Petabytes of information) use Object Databases, as relation systems could not hope with the data rates. APIs like J2EE integrate the OOP work with the database, and guarantee integrity.
3. On the DBMS side, there are all sorts of performance tweaks you can do in addition to automated caching, such as temporary tables, cursors, prepared queries, etc...
Yes, but there are easier and more elegant ways that fit more naturally and transparently with modern OOP development techniques. Java systems handle much of the transactions and caching with little or no additional effort or coding from the developer. There is simply no need for the database-level tuning in many cases.
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 1
Actually, you are right! Ignore my previous post. The 'back button' issue confused me.
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 1
He was talking about applets, which suck except for special purposes. In those cases, only Java will do.
No - it is nothing to do with applets. He was talking about the frameworks available in Java to render HTML and handle web forms.
Re:Posting anon to protect the guilty
on
Spring Into PHP 5
·
· Score: 2, Insightful
"In Java, I can create objects, store them in sessions, hand them to threads, and store them using persistence frameworks. PHP has only the most rudimentary versions of such features."
Good for you. What are the advantages of doing what you're doing that obsolete PHP in every instance?
Scalability. The ability to share objects and information between threads, so that they can be used throughout an application and not just within a request or session is vital for large high-performance websites. It is simply not practical to drop through to the database to reload information each time when you have hundreds or thousands of simultaneous users.
"so you end up with no separation between HTML and code, and you end up with an unmaintainable mess."But what's to stop this from happening in ANY language? And what's to stop it NOT happening in PHP?
In Java, for example, there are web development frameworks such as Tapestry, Struts and JSF, that have cleanly separated presentation and code layers. As for stopping it in PHP - that is tricky, as PHP was designed for HTML + code mixing.
Please explain more - I don't know what filters are. I'd be very surprised if PHP could not support whatever-they-are.
Filters allow specific ranges of URLs to have additional functionality wrapped around the requests. This is a highly useful feature, allowing things like post-processing of HTML, or checking authorisation (and diverting to error pages).
There may be add-ins for this, but as far as I know, it is not standard for PHP, as it is in Java.
Slashdot Mirror
You would be right if:
:)
a) Hiring
b) were not outsourcing development
c) don't have things under control already
d) aren't retraining existing staff
e) use public recruiting strategies
f) don't have other systems that are more important in other languagess.
Statistically, staff will turn over in all areas of a company, so job adverts will be a good sample of what is going on.
I'm not your personal research assistant.
Meaning you aren't going to back your assertions?
You said something that was based on the worst evidence I've seen in a long time - and got called out.
Calling out is when you prove someone wrong.
I did give some hints as to where you can find some informaiton. Perhaps you should add PHP.org to the list - I hear it gets a little traffic
PHP is not LAMP! LAMP is Linux AND Apache AND MySQL AND PHP/PERL or Python.
Yet again.. where are the large number of major high-volume robust transactional sites that run on this combination of technologies? PHP has major scalability issues because of a lack of application-level cacheing; MySQL has only in recent releases provided industrial-strength SQL compatibility.
God of the Gaps? Does he rule the space between the platform and subway cars?
In case this does need explanation....
'God of the Gaps' describes a philosophical point of view in which God (or some other intelligence or higher power) is given as the explanation things we don't understand ('gaps' in our knowledge).
The real theory of Intelligent Design doesn't eliminate evolution.
There is no 'theory' of intelligent design. If there were, there would have to be testable evidence and predictions from it. Simply saying 'this feature is too complex for me to believe that it could have evolved' is not a theory!
Intelligent Design is a 'God of the Gaps' type of philosophical position that can never be falsified, simply (hopefully) reduced to irrelevance as more and more aspects of evolution are explained.
Let's not assume so quickly that anything other than paper will be easily readable in 25 years.
One of the design considerations for XML (which is the format that Open Office uses) is that documents which are in this format should be human-readable, specifically to avoid the problem of future data loss.
"LAMP handles a lot less of those sites than you might think. Check up on job adverts for Google, Amazon etc. and you will find a strong demand for Java and C++ as well as LAMP."
:)
This makes absolutely no sense:
Of course it makes sense! The companies hire employees to maintain and adapt current software implementations. Job adverts indicate the range of systems and languages that are used in those
It's kind of like:
We have a low murder rate in Detroit because the department of corrections isn't hiring executioners right now.
No - its like 'we believe have a low murder rate in Detroit because we note there are few openings for criminals'
Job listings do not indicate what is in production except on the system needing attention at the organization needing the employee.
So you imagine that LAMP systems are so perfect they need no attention?
Assertion: There aren't that many huge-ass LAMP sites on the internet.
I'd be interested to know how many 'huge-ass' sites actually use Linux + Apache + MySQL + PHP/Python/PERL for the majority of their software. I'm certainly not saying that there aren't any; just that I don't know of that many.
Linux is widely used, but so is Solaris! Apache is very common, and so are PERL or Python and PHP, but so are Java and Oracle!
Can you provide evidence of a really high-volume site that runs primarily on LAMP? (Just because a site runs on Linux, or uses Python does NOT make it LAMP!)
Let's look at common sites:
eBay: Java/J2EE on Linux and Solaris + Oracle
Amazon: Uses a range of technologies, including Oracle on Linux clusters.
Google: Uses a wide range of technologies, including Python, C, C++, Java, PHP, Oracle MySQL, and Linux.
If LAMP can scale well enought to handle some of the biggest sites on the INTERNET, I think it can scale to handle a company intranet.
LAMP handles a lot less of those sites than you might think. Check up on job adverts for Google, Amazon etc. and you will find a strong demand for Java and C++ as well as LAMP.
This also depends on what you mean by 'scale'. Handling lots of mainly read-only requests is not difficult; but handling transactions, where data has to be frequently and rapidly changed is fundamentally different. Good examples of this are stock market sites where servers may need to handle tens of thousands of transactions per second. This sort of thing requires very sophisticated transaction handling, messaging, and cacheing and LAMP usually just can't cut it; at least not by itself.
Some of the biggest sites which use LAMP can overcome scalability issues with systems like huge server farms. Other sites (like Stock Exchanges) may need to ensure very high performance at the same time as transactional integrity on just a few clustered servers. It is OK if google forgets your search - it is a disaster if a stock exchange or 'well known auction site' looses your bid or funds transfer!
Who do they think they're foolin'?
More light than comes from through the glass??
if it makes a smoother surface, it could allow more light through
The plain fact of the matter is that to get funding today in various related disciplines to climatology you have to climb on the global warming bandwagon. Sad, but true.
It's not sad at all - it's called 'science' - ideas become popular and are tested by evidence. The so-called 'global warming bandwagon' is rolling on because it is backed by real reproducible evidence that is getting stronger every month.
The only contender in the long run I see currently is Ruby, with their excellent rails framework.
I would hardly call a framework where the object model has to be defined as database tables, and you then end up locked into a particular database product for the lifetime of your application 'excellent'. Compared to other systems, like Hibernate, where data can be defined as true objects, this is a huge step backwards.
This is why EJB 3 is based on Hibernate.
A common misconception! EJB3 is NOT based on Hibernate. It uses ideas from Hibernate, TopLink, JDO and other APIs.
No, it is a theory supported by computer models that may or may not have any relation to reality.
No, it is actual warming that has been actually measured, and is plain to see in areas like Sibera and Arctic ice thickness.
I would challenge the notion that it is necessarily related to any man-related activity (that's for another post if anyone is interested). The only constant about the climate on this planet is change and that has been true since it accreted to a planet.
Change is not good, especially fast change over decades.
To believe that it is not related to man-related activity is to deny that an increase in 1/3 of CO2 levels (which IS man-made) will have no effect. To deny that is simply scientific nonsense.
What you forgot is the whole, its happened hundreds of times over the course of the Earths history from multiple different reasons, making it useless to think humans can stop it, or even SHOULD stop it
Assuming we can't stop it means assuming we aren't responsible. We certainly seem to be. Global warming has certainly happened before, but not this fast (apart from the occasional asteroid collision!).
And the fact remains there is a failsafe people forget. Once the earth gets too warm and the seas grow too big... they reflect the solar energy and become.... yes you guessed it ICE.
Wrong way around. Ice reflects far more heat than water. The more the ice melts, the warmer things get...
yep, will we survive? We have 3 other times already.
At a very low population level.
So in all seriousness, do you believe that scientists have nothing to gain personally by supporting the theory of global warming?
Firstly, most scientists usually gain by supporting ideas that have the backing of other scientists and evidence - that is they way they get funding.
Secondly, global warming is not a theory. It is a fact.
Ah, but you're not allowing for species drift, hybridization - which has occurred in supposedly inactive non-reproducing species, or point mutations.
I certainly am allowing for this. Such mutations have been occurring throughout the long history of life on this planet. If a successful general microbial parasite could exist, it would have evolved at some point over several billion years.
Solar radiation alone can have interesting effects, especially in areas where the ozone layer is not available - for example much of Australia and Argentina and South Africa.
There has been plenty of time for natural mutagens and radiation to have had interesting effects for millions of years. A recent decrease in the ozone layer is nothing by comparison.
until we build the beasties, we won't know exactly what they do. even bioengineering luminescence can act differently if it escapes.
This sounds like too much influence from X-Men and Fantastic Four! Just because things mutate, and we don't know what they might do, does not mean that we will magically produce some super-powered bug that has the amazing ability to attack and digest all the thousands of different types of plant cells, as implied by one of the parent posts way back.
Cross-species parasitic organisms are fairly common, as a recent work by some European scientists in France and the UK said, with a publication date of 2005, and unpredicatable results can happen even by removing quail from a parasitic ecosystem, as many parasites have multiple hosts in their life cycles, including backup or reserve (temporary/seasonal) hosts.
This completely different from some hypothetical 'general' parasite which can happly munch through a large variety of plants. Having very specific organisms for different parts of a lifecycle does not mean that a parasite is non-specific - just that the specificity changes. Having one or two backup species does not make a parasite 'general'.
So, I disagree. It only needs to utilize the other plants and metabolize enough to survive until it gets to its desired or sufficiently optimal source, but that won't stop it's behavior, especially if it's a primitive organism.
Yes, but what plants can it utilize? One or two, perhaps, but as I said there are no general non-specific microbial parasites (or none that I know of).
So, from my viewpoint, the concept of manufacturing an organism to crank out oil needs to be thought thru quite a bit - what if it harvests not just the biowaste of corn husks but starts eating grasses and other plant life?
This is extremely unlikely to happen. Different plant species have different proteins and biochemicals, and an organism tailored to deal with the product of one plant is not going to be effective at dealing with those of others. This is why parasitic organisms and infective bacteria, viruses and fungi are so specific to particular species.
There are a bazillion frameworks for object-caching that don't require careful thread management. PHP doesn't even give you the opportunity.
True, but you don't persuade developers to switch by insulting them.... (as the grandparent post did)
Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
I have to disagree. The average JDBC application explicitly extracts information for all columns, and the relationship between columns and Java variables can be tested either by compilation or by unit tests.
Hibernate it's not, but I'd say that the average Rails app is more adaptable to db changes than the average JDBC application, which still isn't too bad.
It is very bad! The point of systems like Hibernate and JDO and EJB3 is to progress away from database dependence. Rails encourages dependence on database schemas. This is something many of us have been trying to move away from for years.
Rails is a huge step back to the way things were a decade ago.
That said, Ruby on Rails is amazing. If java isn't your bag, check it out. It has most of the best features of Java and PHP, almost none of the warts, and a whole bunch of great stuff you won't find anywhere else.
After all your praising of Hibernate, how can you recommend this? Hibernate is an elegant and robust ORM that isolates your code from database specifics and allows you to write highly portable applications. Ruby on Rails requires exactly the kind of embedded SQL you don't like if you are to do anything complex, and makes your application extremely dependent on the database schema and the specific column names contained within it, and has serious barriers to portability.
I agree strongly with almost every aspect of your post, but certainly not this last part!
I don't usually post to defend those I am debating against, however...
Gonzo is back again. Sweet jebus you are dense.
This is totally unfair. The poster is asking questions I would expect from someone experienced with the PHP way of working. They are intelligent questions.
So what you are telling me is, it's ok to hit the server for a piece of data that isn't changing soon or is complex to get? Lemme guess, calculate and store it in another table? Ugh. Amature.
It is not that simple. Fetching data for each request or each session can be useful in some ways. It allows all all the data relating to an application to be changed without having to restart an application - effectively shutting down the web application. Changing application-scope data in Java is possible, but it requires careful and thread management.
"It is simply not practical to drop through to the database to reload information each time when you have hundreds or thousands of simultaneous users."
..
... ? at all.
It is. I've worked on a site (NB: NOT my URL!) that handles greater traffic than that, with a large number of DB requests on a large proportion of pages. NOT written in PHP. But not even running on a box of its own
It is not practical for anything but the simplest and smallest of data items. If it were, sites like E-Bay and high-volume stock markets would work like this. They don't.
If you want a dynamic web site, you have to mix HTML with something at some point. It may be characters in a file, string delimiters, php delimiters, whatever.
Yes, but what you don't want to mix is logic. Someone should not have to look through lines of HTML to see how you are doing a price calculation!
Generally, web frameworks have specialised tags that are included in the middle of HTML to indicate where the results of processing are to be included.
I don't see anything in the PHP language itself any different from any other language in this regard. HTML is just a bunch of strings; PHP can be written with nothing outside of the ?php
You can, but the mere fact you have those enclosing symbols indicates that the language was designed to allow embedding in HTML, and not to discourage it.
"Filters allow specific ranges of URLs to have additional functionality wrapped around the requests. This is a highly useful feature, allowing things like post-processing of HTML, or checking authorisation (and diverting to error pages)."
Forgive me if this sounds flippant, but isn't that something than can be achieved with an array, a regexp or two, and REQUEST_URI?
It can, but why bother re-implementing this each time? Filter APIs allow Filter classes to be written in just a few lines of code.
Is this something actually within the language itself?
No. It is a standard part of the JSP/Servlet API, which is a subset of J2EE.
"Having logic in the database does not seem to be practical for high-load systems."
First of all, based on what research?
Real websites.
There are incredibly large systems based on keeping business logic in the database. Just last week at OSCON I met several people who are running primary systems on PostgreSQL, some inserting several GB a day of new data. That seems pretty high-load to me.
That is not high load! I am talking about sites that have have thousands or tens of thousands of concurrent users, all requiring access to data which can be altered. Sites like E-Bay, or stock markets use Java, cacheing and ORM to minimise contacts with the database wherever possible.
What magic is there that means re-implementing constraints in Java would be somehow faster than the implementation of most serious DBMSs, which are written in C and usually have many more years of research and stability behind them?
The magic is transparency. It allows business logic and data structures to be set up and used without having to embed the logic of caching, constraints and transactions.
Considering the very widespread use of Java and J2EE for this purpose in almost all aspects of finance and commerce, there are no doubts as to its stability.
Thus the greatly increased possibility that the system will be compromised, because a change in logic here might not be dealt with over there.
Not at all. There are very well-established and widely uses systems like JTA (Java Transaction API) that work with J2EE application servers like WebSphere. These co-ordinate transactions transparently all the way from the web page code down to database access. There is no risk of compromise.
Anyway, if performance is your only reason for not keeping logic centralized then wouldn't you agree that that is either a result of bad implementation on the database side (I mean in the storage implementation of the DBMS itself), or a sacrifice of integrity on the application side?
No. Databases have their function, which is to maintain relational data. They are not suited to general OOP coding which is now the norm for most commercial development. Also, relational systems were never designed for performance! Some of the very highest performance data stores (such the data collection systems at CERN, which deal with Petabytes of information) use Object Databases, as relation systems could not hope with the data rates. APIs like J2EE integrate the OOP work with the database, and guarantee integrity.
3. On the DBMS side, there are all sorts of performance tweaks you can do in addition to automated caching, such as temporary tables, cursors, prepared queries, etc...
Yes, but there are easier and more elegant ways that fit more naturally and transparently with modern OOP development techniques. Java systems handle much of the transactions and caching with little or no additional effort or coding from the developer. There is simply no need for the database-level tuning in many cases.
Actually, you are right! Ignore my previous post. The 'back button' issue confused me.
He was talking about applets, which suck except for special purposes. In those cases, only Java will do.
No - it is nothing to do with applets. He was talking about the frameworks available in Java to render HTML and handle web forms.
"In Java, I can create objects, store them in sessions, hand them to threads, and store them using persistence frameworks. PHP has only the most rudimentary versions of such features."
Good for you. What are the advantages of doing what you're doing that obsolete PHP in every instance?
Scalability. The ability to share objects and information between threads, so that they can be used throughout an application and not just within a request or session is vital for large high-performance websites. It is simply not practical to drop through to the database to reload information each time when you have hundreds or thousands of simultaneous users.
"so you end up with no separation between HTML and code, and you end up with an unmaintainable mess."But what's to stop this from happening in ANY language? And what's to stop it NOT happening in PHP?
In Java, for example, there are web development frameworks such as Tapestry, Struts and JSF, that have cleanly separated presentation and code layers. As for stopping it in PHP - that is tricky, as PHP was designed for HTML + code mixing.
Please explain more - I don't know what filters are. I'd be very surprised if PHP could not support whatever-they-are.
Filters allow specific ranges of URLs to have additional functionality wrapped around the requests. This is a highly useful feature, allowing things like post-processing of HTML, or checking authorisation (and diverting to error pages).
There may be add-ins for this, but as far as I know, it is not standard for PHP, as it is in Java.