1. OOP is merely a personal preference (it fits your mind better). 2. You are not good at procedural/relational (p/r) techniques, and thus turn to OOP. 3. OOP is objectively better 4. The features of some product that you like are not really about OOP.
It is a complex mix. Although I would strongly dispute that one 'turns to OOP' because it is a poor alternative to p/r. OOP has major benefits that are very hard to model in relational systems, such as polymorphism and inheritance.
This assumes that variations fit and change in a hierarchical way. In the real world they usually do *not* fit or change tree-wise in my observation. Set theory is a superior "variation management technique" than OOP's tree-based subclassing. (Yes, there is multiple inheritance, but it is messier than formal set usage.) And, relational better fits this set-oriented view. There is no "tree cop" to force domain things to fit a tree. Sets are simply more flexible than trees. Trees are impossible to normalise when you get more than 3 or 4 factors of variation.
Well, over 30 years of research here have shown that you are wrong, and in the areas of GUI development things DO fit well in the real world into single-inheritance tree structures. It is practical and useful.
It is all very well for you to claim that they don't, but the experience of millions of developers who have found the OOP approach productive suggest you are wrong.
Anyone who suggested that user interfaces should be based on relational theory would not get much support.
Generally in p/r you do a JOIN to bring in the address information for a given task if you need it.
Why even bother to explicitly do a join? That is SO low level. Instead, with JDO, you express a hint to the query generator that things needs to be fetched and let it do the work. After all, not all persistence methods have an SQL JOIN.
I am sorry, but I feel like someone who codes in C trying to talk so someone who only understands assembler, and who is talking about how to optimise register use. My compiler handles all that!
It is also usually more effecient over a network than to grab one per loop iteration. (In biz apps, network bandwidth is often a bigger bottleneck than CPU.)
I know this.
But *if* one wanted to go your route, nothing stops us from creating something like:
I believe you are thinking at this at far to low a level - it is almost like an 'assembler' of relational use. If you research further, you will see that the systems I describe will automatically fetch things in an optimised way, with considerations of networks.
Also, that is so explicit. The point of transparent persistence is you simply don't need to express retrieval in standard business logic.
I don't think that is true. IINM, Some ODBC drivers implement some form of SQL such that they can read XML, comma-delimited, and spreadsheets via SQL statements because the driver has (or uses) a basic SQL engine. For formal databases, ODBC just passes the SQL along to the RDBMS rather than interpret it itself.
Yes, I said it was a simple description.
And procedural-only languages can use ODBC also. This is getting away from application-centric code issues anyhow. Can't OO fans talk about something besides device drivers and swapping DB engines? It is an interesting topic, but gets into nitty details about SQL intercepting/parsing etc. And, it is very product/vendor specific.
No, on the contrary, it allows vendor-neutrality, and it absolutely isn't product or vendor specific. I am talking about vendor-independent standards.
What you are talking about is a vendor-neutral version of SQL that the driver translates or cleans up based on vendor etc.
As I understand it, determinism in quantum mechanics is a settled issue. The quantum wave function is deterministic. The collapse of said function is not. You may not be able to tell, instant to instant, where a particle is, but you know exactly how the quantum wave function will evolve.
The problem is that quantum mechanics is incomplete, so any conclusions we draw from it are extremely suspect.
In any case, indeterminism only applies at quantum scales. At macro scales, including the level at which neurons exist, statistics ensure that the indeterminism of the collapse will average out into the determinism of the wave function itself. There is little evidence for any kind of quantum effect in the brain.
No, I think you misunderstand. It is collapse itself that produces randomness - things don't average out into the determinism of the wave function. We aren't talking about spooky quantum effects in the brain, we are talking about macroscopic indeterminacy that results from such effects.
Jebus, man! How does Heisenberg enter into human consciousness? Can you show a quantum mechanical mechanism? Some people like Penrose think there has to be, but most people in the field (from covnersations I've had, I could be wrong) think there are NO quantum mechanical processes that play a part in consciousness.
Because every single electrochemical and chemical reaction is subject to quantum mechanics, and so Heisenberg's uncertainly principle.
However, even if there are such processes, they can be modelled. Ever hear of quantum computing?
Go on, please - show me a functional quantum computer.
Atoms and energy must adhere to the laws of physics so they are deterministic.
Woah! Hold it there. Who says that the laws of physics are deterministic? This has been a matter of heated (and unresolved) debate regarding atoms and subatomic particles for close to a century. You simply can't claim this.
Prove that human brain activity is non-deterministic. I have a good friend who is getting his PhD in neuroscience, and from conversations I've had with him, I'd say it's pretty damn deterministic. Human consciousness does not exist outside the laws of nature. It is not a special type of process, unlike any other.
Perhaps you could then, given the current understanding of neuroscience, explain qualia. Not so easy, is it?
The point is not that human conciousness exists outside the laws of nature, just that our understanding of the laws of nature and their consequences is extremely primitive, and any claim that we can talk at this stage about determinism (or lack of) is arrogant in the extreme. Determinism (or lack of) is still a matter of heated debate in terms of subatomic particles, so to claim that it applies to brains and conciousness is a huge extrapolation without any foundation.
Oh, it's not my own idea. You're taking issue with smarter people than I. Thomas Kuhn, for example, in The Structure of Scientific Revolutions:
Which is largely true (although as a scientist myself, I have experienced major deviations from it), but irrelevant. The issue of global warming is not about a scientific revolution, or about novelty. Matters of climate modelling have been subject to strong debate for decades. What has happened is that the current consensus on climate change has been built up over a long time, as the original idea of climate change has been backed up by increasing ly good models and data.
In fact, what was revolutionary decades ago was the idea of man-made global warming. Current client change deniers are rather like those who still wouldn't believe relativity decades after the evidence started to come in.
I've been searching for 8+ years for code-proof that OOP is better. Never found any, at least for biz apps. The samples provided by others had flaws or flawed assumptions about change frequency, bad languages (C vs. C++), or they were just poor procedural programmers.
well that is fair enough, but I have no response but to say that I use OOP in almost everything I write and I find it invaluable.
All GUI programs need an event-loop of some kind. It is just that the guts of the frameworks can hide such so that app developers are not dealing directly with it. This is true of procedural also. Event-driven GUI systems are perfectly at home with procedural. (If C cannot do it, it is a fault of C, not procedural.)
No, it isn't the same for procedural at all. For example, in Swing, I create a subclass of JComponent, and I get all the features of that class. I can override any particular method to add my own behaviour. You can implement this procedurally, but it simply isn't a clean and natural way to do this. This is not a new point of view - this was a major discovery in the 70s.
You are not clear what you are talking about. You keep wavering between talking about DB access API's and a query language itself. Wrapping a file system in a DB API does not give you a query language unless somebody reinvents one on top of the file system under the covers. File systems have no inherent query language, so why are you talking about switching from SQL to a file system? It makes no sense minus a translator.
I am not talking about switching between SQL and a file system. Let me try and explain again. You can get part of an object tree via a portable query language. Then, additional accesses to objects generate queries to tranparently retrieve additional data.
Suppose I have an object called 'Customer', and that is liked to 'Address', then all I need do with querying is retrieve the customer. When I do:
customer.getAddress()
then an additional query is run to retrieve the address, transparently and in the background.
Of course, if this is inefficient, you can configure the system to always fetch the addresses along with the customers. Then, efficient and optimised SQL for this will be automatically generated.
Also, with you talk about wrapping a file system in the API is a valid point. What happens is the following: if someone implements the JDO 2.0 API for a file system, they have to implement functionality so that all of the JDO 2.0 query language works in their product. If I write a JDO query to fetch a customer and associated addresses with a given condition, that query will work on ANY JDO implementation, no matter what the underlying data store.
It is not a case of re-implementing the query language - the query language (unlike SQL) is fixed and guaranteed standard. It is a case of implementing a persistence engine that understands the query language.
You are not being clear. Your SQL will NOT work on XML unless you have an SQL parser that treats the XML like relational tables.
Indeed.
Java kits may provide that, I don't know.
They do.
But again this is no different than ODBC drivers.
Correct, but I am not talking about JDBC or ODBC - I am talking about a far higher level of abstraction (see below).
If one has an ODBC driver that allows one to query XML files via an SQL interface, then swapping can take place. (The advantage is that ODBC is not tied to one language such that one can use Fortran or Perl with the same ODBC driver. This keeps one from having to reinvent the same wheel for each app language.)
I was discussing this in the context of a Java API because it does hugely more than JDBC and ODBC.
JDBC and ODBC aren't good abstractions, and don't provide much portability. All they provide (to simplify) is a common interface for querying what a particular storage system can do, and a way to pass SQL to those storage systems, and fe
But, I NEVER get to see actual code kicking procedure/relational's butt.
You need to look around then.
Plus, even many OO proponents have changed their tune about "reuse". Reuse has fallen out of favor as a key OO claim.
I keep an eye on such opinions.
Me too - advising on technical matters is a key part of my job. I find re-use is a significant help in projects that I work on, and other aspects of OOP, especially polymorphism are absolutely key to much of my work. I regularly write GUI apps in Java. Inheritance, polymorphism and re-use is essential for this kind of development - without it, one would be back to the ghastly event-loop and call-back coding of decades ago.
Procedural can do that also. But most of the difference is in the SQL dialects, not in the DB access API's. I use ODBC for similar such testing also. (Perhaps it the guts of ODBC drivers are written in OO, I don't know and don't need to care. I am talking about helping custom apps, not systems software.)
Again, what's with the SQL? I am talking about portable query languages.
Example changes? SQL is doing most of the "real" domain-oriented work. That is where most of the changes will thus happen. You cannot use non-trivial SQL on flat files, XML, etc.
Any change you can think of.
Where did I mention SQL? Why are you fixated on SQL? I am talking about a rich portable query language (which SQL isn't) that is mapped to SQL on systems that use SQL. Look up JDOQL or HSQL.
SQL isn't doing anything - it is simply a way of expressing what should be done. There are other ways.
And, also, you REALLY need to get up to date. There have been SQL-based systems for a range of file formats - CSV, XML, flat, Excel etc. for years, and not trivial SQL either.
RDBMS are NOT about persistence. Persistence is largely a side benefit. Features/Abilities of RDBMS include:
Yes, of course I know all this, which is why RDMBSes are vital for almost all that I do. All of those facilities are available through the ORM when it is running on an RDBMS. Obviously, you don't get them when persisting to flat files. The point is not to have to re-invent a new API for persisting to flat files.
Perhaps you are one of those OO programmers who uses the RDBMS as merely a dumb file system and reinvents a database in app code. In that case, you would be right. But, I don't like reinventing databases from scratch or using a highly non-standard ones that works with only one language, like Java Prevelayer, etc.
I am not re-inventing anything. What happens is that I have full transactional and multi-user facilities when I need them, using the same API. I certainly don't use a database just as a dumb file system - that is a crazy waste of resources and the power of such systems.
Could I ask that you stop setting up straw man arguments, and actually find out about this before you post again?
Bullsh*t! XML and flat files don't understand SQL. Again, most of the "real work" is in the query language, not the access API's. (Unless you are doing something trivial or wierd.)
Wrong. The work happens in the implementation of the access APIs. If I use a JDO 2.0 implementation that persists to XML files, that implementation will handle the query language. And to say that the real work happens in the query language means you just don't understand how this works. You need to get up-to-date and find out about "transparent persistence".
Sounds like you need to learn what "evidence" means. Brochure-talk does not compile. OO has provided bullsh*t artists with many many new paint brands. You are starting to remind me of one.
Nothing like a good ad hominem attack.
This isn't brochure talk - it is based on real projects and real experience of thousands of developers.
OOP has not been shown to improve any objective metric (except maybe systems software, which is not my domain so I don't care.)
This is just plain wrong. There is no doubt that the ability to refactor code is a major benefit in terms of code quality and productivity, and this is largely due to OOP. I have personally seen huge productivity benefits in my company resulting from code re-use, both between developers in the company and from the use of external libraries, as a result of OOP.
Your example looks like basic DB access API's.
Then I have really done a bad job of explaining things.
I've seen similar things in 30-year-old FORTRAN. They are just an API to send queries and recieve results from databases. OOP does not change the nature of them much. One could do something similar with procedural API's:
You really do need to look at JDO 2.0. It is light-years away from that situation. All I am doing with that query is retrieving a few objects. But then, any changes I make to objects (in normal code) are transparently noted, and saved to the data store automatically. There is no need for an update query or API. I don't even need to retrieve most of the objects. Most of the retrieval is in the background, and automatic. And all this works using the highest efficiency SQL (on relational stores), is transactionally safe and clusterable with no coding required. The key phrase you need to look up is 'transparent persistence'.
Some argue that OOP allows one to switch DB API vendors, but that has almost nothing to do with domain development productivity. And the swappable benefit claims only play out in a very *limited* set of circumstances, which OOP books exaggerate the likelyhood by far.
Sorry, but this is a wildly out-of-date view. I have seen a huge boost in productivity, as it means that business logic need not be expressed in the constrained terms of SQL queries and relational tables - it can be expressed in normal OOP code. It allows a huge amount of freedom for developers; it allows them to express what happens to data without concerns of persistence. This saves a lot of time and code.
As for saying that the swappable benefit only plays out in a very limited set of circumstances - that is not only wrong - it is crazy: Every day that I work on my projects, I develop not caring about what persistence store I use. It so happens that I do most of my development on a laptop using PostgreSQL. I then pass on my code to other developers who use Oracle. This is not trivial code - it is a major project with hundreds of thousands of lines of code, but they only need to change a few lines in a configuration file for my code to work with their database. A few more lines, and it would work with any of a dozen major relational databases, or an XML store or an Object Database. I have no more concern about which database I persist to than the nature of the file system driver that is used when I call a 'File.open' method.
As for the benefits - they are major. This means that development can be done, including substantial testing, off-site, and without requiring expensive hardware and licenses for specific hardware to run enterprise databases. It means that when my company develops products, the client can choose the database - I am not telling them which database they can use. It means that I can release smaller versions of software that will operate of, say, CSV files in low-memory machines, but without having to change a line of code. And, of course, there is the fantastic freedom from vendor tie-in.
It sounds to me like you seriously need to get up to date, and realise how things have changed.
OK, then - I personally find OOP a highly useful abstraction. Popularity does also not equal bad!
For something very simple, yes. But not for non-trivial stuff.
If you look at real examples, it turns out that this approach is actually more powerful for the more complex stuff, as the abstraction saves time.
I've encountered this claim multiple times before and it turned out to be bogus when actual code example was given. They either leave out some important key limit, or use some bloated API that makes for very very verbose ugly code, almost like OOP "query" assembler. With enough effort you can wrap and swap anything, but the result can be far worse than what you wrap. Query languages are not "raw implementation", they can be a powerful abstraction tool if you know how to use them. I'll believe it when I see actual code (that doesn't have described flaws).
Well, there is no way to reply to that, as you are free to label any code I provide as ugly and verbose. What matters is does the API provide performance and productivity? My experience is, unquestionably, yes.
All I can say is that I actually use JDO 2.0 in precisely the way I have described: this is not imaginary.
Also, I am certainly not excluding the use of query languages. JDO 2.0 specifies a rich query language. The difference from, say, SQL, is that it is truly portable, and all implementations of JDO must provide all features of the JDO query language, no matter what platform and no matter what persistence method - no incomplete implementations of standards, as has always been the case with SQL.
Here is an example of using JDO 2.0:
pm.currentTransaction().begin(); Query query = pm.newQuery("SELECT UNIQUE FROM Person WHERE lastName == 'Jones' +
" && age:age_limit PARAMETERS double age_limit ORDER BY surname ASCENDING"); List results = query.execute(24);
That is it. Not verbose; nothing like query assembler.
OK, so in your example variable array is a full-fledged object. As such, in this language, the program tracks the number of references to the object to know when this count goes to zero. Once this happens, a separate garbage-collection thread will run at some time we cannot predict to clean up the space this object is taking up. (As an aside, this is why finally clauses are needed in Java but not C++. In C++ the time at which objects are destroyed are well-defined, so we can use destructors to do necessary clean up precisely when we're leaving a try block.). Compare this to the C/C++ equivalent. There array is simply a block of memory. This memory is cleaned up precisely after we exit the block in which it was defined. Since it takes approximately 2 brain cells to know that the quantity we check in the for loop is the same as the number of elements we define array as having, there is no need to have any built-in bounds checking in the language in the first place.
Well, the history of C and C++ use over decades is that many developers don't possess those particular 2 brain cells, as buffer/array overrun problems are widespread.
I fail to see any big advantage with Java in this case. Quite the opposite.
You haven't actually given any reason why the Java approach should be disadvantageous - you have simply presented a series of facts.
The Java approach is unquestionably safer. And garbage collection can be extremely efficient - just as efficient as manual memory management, even on real-time systems.
I flat-out don't believe you. OOP API's in many ways are a lower-level abstraction than relational query languages.
But almost all coding is done in an OOP way these days, so it is highly useful abstraction.
And the features of those things you listed are not one-for-one exchangable. Let's see you do a 3-way join and then a GROUP-BY-like summary with flat files and handling multi-user concurrency without reinventing a database to pull it off.
You are missing the point completely. No-one is saying that you will get all the features of concurrent high-performance relational database no matter what type of persistence you use; the point is that you can use exactly the same code and queries for all those types of persistence. For example, I can open a transaction, define and run a query including joins and grouping, and retrieve objects, and modify them and have them be persisted when I close the transaction, no matter what persistence store I use - flat file, relational database and so on. Of course you don't get multi-user concurrency with flat files! But who cares? The point is that you get automatically get multi-user concurrency when you run the same code on a relational database without having to change a line of code.
Funding has less to do with quality than whether the research supports or opposes the current paradigm.
A very broad statement, and wrong, but wrong in an interesting way. Paradigms usually become current when they get increasing evidence. This can attract researchers because they want to do research that will go somewhere, and not end up in a dead end. In order to get funding, you have to show that you are likely to find something new. So, simply saying 'I want to do more work to back up global warming' isn't going to be a good way to get funded, which is why you are wrong.
It doesn't take much reading of these threads to remove all optimism.
I am amazed that climate change deniers are brave enough to fly. After all, aerodynamics is only a consensus - there are still one or two people who think it all wrong, and such rebels are always right.
Certain of the measures are what we need to do anyway, and are potentially extremely good for economies (well, most of them) - devising ways of saving energy, finding new non-oil energy resources. We should be doing this anyway, for economic and political reasons.
And every scientist knows that you need a crisis to get funding? No?
No, of course not. The vast majority of science (including climate science) is extraordinarily dull, but gets funded because of the quality of previous research and ideas.
No - someone needs to boost their sarcasm generator. In order to be effective, sarcasm has to push beyond the extremes of what people say. Unfortunately, many climate change deniers have the view expressed.
Exactly correct. Everyone knows that the present of a specific scientific principle is decided by a central committee and then approved by the electorate at large. It's an excellent system, look how the Catholic church managed to keep us at the centre of universe!
If only that were so, then science would be so much easier. Unfortunately science is judged by hundreds of independent journals and through the review of thousands of scientists, many of whom are competing for the same funding you are and so are motivated to find holes in your work. Anyone who thinks science is a friendly group of like-minded souls all patting each other on the back really hasn't a clue.
I agree with this prediction. Database interfaces (such as SQL) do not dictate implimentation. Ideally, query languages only ask for what you want, not tell the computer how to do it.
This can be taken a stage further, with general persistence APIs. The idea is that you don't even require SQL or relational stores: you express queries in a more abstract way and let a persistence engine generate highly optimised SQL, or some other persistence process. I use the Java JDO 2.0 API like this: I can persist and retrieve information from relational stores, CSV, XML, LDAP, Object Databases or even flat text files using exactly the same code and queries, and yet I get optimised queries on each - if I persist to Oracle, the product knows enough about Oracle (and even the specific version of Oracle) to generate very otimised SQL.
Ok, it's not entirely his fault that he's clueless. These are fairly new technologies. Anyone who does database-backed applications for a living these days should crack open some books on this!
Object-relational mapping isn't new at all. Hibernate has been around for years, and TopLink, one of the products EJB 3 was based on, has been around since the early 90s.
That's the real reason the C model persists and will continue to persist, the computing world still needs a standard high level assembly language and won't give it up anytime soon.
The real problem was the widespread decision to use such a high level assembly language as if it were suitable for general purpose development.
Slashdot Mirror
1. OOP is merely a personal preference (it fits your mind better).
// returns associative array
2. You are not good at procedural/relational (p/r) techniques, and thus turn to OOP.
3. OOP is objectively better
4. The features of some product that you like are not really about OOP.
It is a complex mix. Although I would strongly dispute that one 'turns to OOP' because it is a poor alternative to p/r. OOP has major benefits that are very hard to model in relational systems, such as polymorphism and inheritance.
This assumes that variations fit and change in a hierarchical way. In the real world they usually do *not* fit or change tree-wise in my observation. Set theory is a superior "variation management technique" than OOP's tree-based subclassing. (Yes, there is multiple inheritance, but it is messier than formal set usage.) And, relational better fits this set-oriented view. There is no "tree cop" to force domain things to fit a tree. Sets are simply more flexible than trees. Trees are impossible to normalise when you get more than 3 or 4 factors of variation.
Well, over 30 years of research here have shown that you are wrong, and in the areas of GUI development things DO fit well in the real world into single-inheritance tree structures. It is practical and useful.
It is all very well for you to claim that they don't, but the experience of millions of developers who have found the OOP approach productive suggest you are wrong.
Anyone who suggested that user interfaces should be based on relational theory would not get much support.
Generally in p/r you do a JOIN to bring in the address information for a given task if you need it.
Why even bother to explicitly do a join? That is SO low level. Instead, with JDO, you express a hint to the query generator that things needs to be fetched and let it do the work. After all, not all persistence methods have an SQL JOIN.
I am sorry, but I feel like someone who codes in C trying to talk so someone who only understands assembler, and who is talking about how to optimise register use. My compiler handles all that!
It is also usually more effecient over a network than to grab one per loop iteration. (In biz apps, network bandwidth is often a bigger bottleneck than CPU.)
I know this.
But *if* one wanted to go your route, nothing stops us from creating something like:
row = getAddress(customerID);
I believe you are thinking at this at far to low a level - it is almost like an 'assembler' of relational use. If you research further, you will see that the systems I describe will automatically fetch things in an optimised way, with considerations of networks.
Also, that is so explicit. The point of transparent persistence is you simply don't need to express retrieval in standard business logic.
I don't think that is true. IINM, Some ODBC drivers implement some form of SQL such that they can read XML, comma-delimited, and spreadsheets via SQL statements because the driver has (or uses) a basic SQL engine. For formal databases, ODBC just passes the SQL along to the RDBMS rather than interpret it itself.
Yes, I said it was a simple description.
And procedural-only languages can use ODBC also. This is getting away from application-centric code issues anyhow. Can't OO fans talk about something besides device drivers and swapping DB engines? It is an interesting topic, but gets into nitty details about SQL intercepting/parsing etc. And, it is very product/vendor specific.
No, on the contrary, it allows vendor-neutrality, and it absolutely isn't product or vendor specific. I am talking about vendor-independent standards.
What you are talking about is a vendor-neutral version of SQL that the driver translates or cleans up based on vendor etc.
No, I am not! I am not talking about SQL.
I see no rule of the universe that
As I understand it, determinism in quantum mechanics is a settled issue. The quantum wave function is deterministic. The collapse of said function is not. You may not be able to tell, instant to instant, where a particle is, but you know exactly how the quantum wave function will evolve.
The problem is that quantum mechanics is incomplete, so any conclusions we draw from it are extremely suspect.
In any case, indeterminism only applies at quantum scales. At macro scales, including the level at which neurons exist, statistics ensure that the indeterminism of the collapse will average out into the determinism of the wave function itself. There is little evidence for any kind of quantum effect in the brain.
No, I think you misunderstand. It is collapse itself that produces randomness - things don't average out into the determinism of the wave function. We aren't talking about spooky quantum effects in the brain, we are talking about macroscopic indeterminacy that results from such effects.
Jebus, man! How does Heisenberg enter into human consciousness? Can you show a quantum mechanical mechanism? Some people like Penrose think there has to be, but most people in the field (from covnersations I've had, I could be wrong) think there are NO quantum mechanical processes that play a part in consciousness.
Because every single electrochemical and chemical reaction is subject to quantum mechanics, and so Heisenberg's uncertainly principle.
However, even if there are such processes, they can be modelled. Ever hear of quantum computing?
Go on, please - show me a functional quantum computer.
Atoms and energy must adhere to the laws of physics so they are deterministic.
Woah! Hold it there. Who says that the laws of physics are deterministic? This has been a matter of heated (and unresolved) debate regarding atoms and subatomic particles for close to a century. You simply can't claim this.
Prove that human brain activity is non-deterministic. I have a good friend who is getting his PhD in neuroscience, and from conversations I've had with him, I'd say it's pretty damn deterministic. Human consciousness does not exist outside the laws of nature. It is not a special type of process, unlike any other.
Perhaps you could then, given the current understanding of neuroscience, explain qualia. Not so easy, is it?
The point is not that human conciousness exists outside the laws of nature, just that our understanding of the laws of nature and their consequences is extremely primitive, and any claim that we can talk at this stage about determinism (or lack of) is arrogant in the extreme. Determinism (or lack of) is still a matter of heated debate in terms of subatomic particles, so to claim that it applies to brains and conciousness is a huge extrapolation without any foundation.
Oh, it's not my own idea. You're taking issue with smarter people than I. Thomas Kuhn, for example, in The Structure of Scientific Revolutions:
Which is largely true (although as a scientist myself, I have experienced major deviations from it), but irrelevant. The issue of global warming is not about a scientific revolution, or about novelty. Matters of climate modelling have been subject to strong debate for decades. What has happened is that the current consensus on climate change has been built up over a long time, as the original idea of climate change has been backed up by increasing ly good models and data.
In fact, what was revolutionary decades ago was the idea of man-made global warming. Current client change deniers are rather like those who still wouldn't believe relativity decades after the evidence started to come in.
I've been searching for 8+ years for code-proof that OOP is better. Never found any, at least for biz apps. The samples provided by others had flaws or flawed assumptions about change frequency, bad languages (C vs. C++), or they were just poor procedural programmers.
well that is fair enough, but I have no response but to say that I use OOP in almost everything I write and I find it invaluable.
All GUI programs need an event-loop of some kind. It is just that the guts of the frameworks can hide such so that app developers are not dealing directly with it. This is true of procedural also. Event-driven GUI systems are perfectly at home with procedural. (If C cannot do it, it is a fault of C, not procedural.)
No, it isn't the same for procedural at all. For example, in Swing, I create a subclass of JComponent, and I get all the features of that class. I can override any particular method to add my own behaviour. You can implement this procedurally, but it simply isn't a clean and natural way to do this. This is not a new point of view - this was a major discovery in the 70s.
You are not clear what you are talking about. You keep wavering between talking about DB access API's and a query language itself. Wrapping a file system in a DB API does not give you a query language unless somebody reinvents one on top of the file system under the covers. File systems have no inherent query language, so why are you talking about switching from SQL to a file system? It makes no sense minus a translator.
I am not talking about switching between SQL and a file system. Let me try and explain again. You can get part of an object tree via a portable query language. Then, additional accesses to objects generate queries to tranparently retrieve additional data.
Suppose I have an object called 'Customer', and that is liked to 'Address', then all I need do with querying is retrieve the customer. When I do:
customer.getAddress()
then an additional query is run to retrieve the address, transparently and in the background.
Of course, if this is inefficient, you can configure the system to always fetch the addresses along with the customers. Then, efficient and optimised SQL for this will be automatically generated.
Also, with you talk about wrapping a file system in the API is a valid point. What happens is the following: if someone implements the JDO 2.0 API for a file system, they have to implement functionality so that all of the JDO 2.0 query language works in their product. If I write a JDO query to fetch a customer and associated addresses with a given condition, that query will work on ANY JDO implementation, no matter what the underlying data store.
It is not a case of re-implementing the query language - the query language (unlike SQL) is fixed and guaranteed standard. It is a case of implementing a persistence engine that understands the query language.
You are not being clear. Your SQL will NOT work on XML unless you have an SQL parser that treats the XML like relational tables.
Indeed.
Java kits may provide that, I don't know.
They do.
But again this is no different than ODBC drivers.
Correct, but I am not talking about JDBC or ODBC - I am talking about a far higher level of abstraction (see below).
If one has an ODBC driver that allows one to query XML files via an SQL interface, then swapping can take place. (The advantage is that ODBC is not tied to one language such that one can use Fortran or Perl with the same ODBC driver. This keeps one from having to reinvent the same wheel for each app language.)
I was discussing this in the context of a Java API because it does hugely more than JDBC and ODBC.
JDBC and ODBC aren't good abstractions, and don't provide much portability. All they provide (to simplify) is a common interface for querying what a particular storage system can do, and a way to pass SQL to those storage systems, and fe
But, I NEVER get to see actual code kicking procedure/relational's butt.
You need to look around then.
Plus, even many OO proponents have changed their tune about "reuse". Reuse has fallen out of favor as a key OO claim.
I keep an eye on such opinions.
Me too - advising on technical matters is a key part of my job. I find re-use is a significant help in projects that I work on, and other aspects of OOP, especially polymorphism are absolutely key to much of my work. I regularly write GUI apps in Java. Inheritance, polymorphism and re-use is essential for this kind of development - without it, one would be back to the ghastly event-loop and call-back coding of decades ago.
Procedural can do that also. But most of the difference is in the SQL dialects, not in the DB access API's. I use ODBC for similar such testing also. (Perhaps it the guts of ODBC drivers are written in OO, I don't know and don't need to care. I am talking about helping custom apps, not systems software.)
Again, what's with the SQL? I am talking about portable query languages.
Example changes? SQL is doing most of the "real" domain-oriented work. That is where most of the changes will thus happen. You cannot use non-trivial SQL on flat files, XML, etc.
Any change you can think of.
Where did I mention SQL? Why are you fixated on SQL? I am talking about a rich portable query language (which SQL isn't) that is mapped to SQL on systems that use SQL. Look up JDOQL or HSQL.
SQL isn't doing anything - it is simply a way of expressing what should be done. There are other ways.
And, also, you REALLY need to get up to date. There have been SQL-based systems for a range of file formats - CSV, XML, flat, Excel etc. for years, and not trivial SQL either.
RDBMS are NOT about persistence. Persistence is largely a side benefit. Features/Abilities of RDBMS include:
Yes, of course I know all this, which is why RDMBSes are vital for almost all that I do. All of those facilities are available through the ORM when it is running on an RDBMS. Obviously, you don't get them when persisting to flat files. The point is not to have to re-invent a new API for persisting to flat files.
Perhaps you are one of those OO programmers who uses the RDBMS as merely a dumb file system and reinvents a database in app code. In that case, you would be right. But, I don't like reinventing databases from scratch or using a highly non-standard ones that works with only one language, like Java Prevelayer, etc.
I am not re-inventing anything. What happens is that I have full transactional and multi-user facilities when I need them, using the same API. I certainly don't use a database just as a dumb file system - that is a crazy waste of resources and the power of such systems.
Could I ask that you stop setting up straw man arguments, and actually find out about this before you post again?
Bullsh*t! XML and flat files don't understand SQL. Again, most of the "real work" is in the query language, not the access API's. (Unless you are doing something trivial or wierd.)
Wrong. The work happens in the implementation of the access APIs. If I use a JDO 2.0 implementation that persists to XML files, that implementation will handle the query language. And to say that the real work happens in the query language means you just don't understand how this works. You need to get up-to-date and find out about "transparent persistence".
Sounds like you need to learn what "evidence" means. Brochure-talk does not compile. OO has provided bullsh*t artists with many many new paint brands. You are starting to remind me of one.
Nothing like a good ad hominem attack.
This isn't brochure talk - it is based on real projects and real experience of thousands of developers.
Is this a sign of desperation?
I doubt it; Sun server sales are doing very well right now.
OOP has not been shown to improve any objective metric (except maybe systems software, which is not my domain so I don't care.)
This is just plain wrong. There is no doubt that the ability to refactor code is a major benefit in terms of code quality and productivity, and this is largely due to OOP. I have personally seen huge productivity benefits in my company resulting from code re-use, both between developers in the company and from the use of external libraries, as a result of OOP.
Your example looks like basic DB access API's.
Then I have really done a bad job of explaining things.
I've seen similar things in 30-year-old FORTRAN. They are just an API to send queries and recieve results from databases. OOP does not change the nature of them much. One could do something similar with procedural API's:
You really do need to look at JDO 2.0. It is light-years away from that situation. All I am doing with that query is retrieving a few objects. But then, any changes I make to objects (in normal code) are transparently noted, and saved to the data store automatically. There is no need for an update query or API. I don't even need to retrieve most of the objects. Most of the retrieval is in the background, and automatic. And all this works using the highest efficiency SQL (on relational stores), is transactionally safe and clusterable with no coding required. The key phrase you need to look up is 'transparent persistence'.
Some argue that OOP allows one to switch DB API vendors, but that has almost nothing to do with domain development productivity. And the swappable benefit claims only play out in a very *limited* set of circumstances, which OOP books exaggerate the likelyhood by far.
Sorry, but this is a wildly out-of-date view. I have seen a huge boost in productivity, as it means that business logic need not be expressed in the constrained terms of SQL queries and relational tables - it can be expressed in normal OOP code. It allows a huge amount of freedom for developers; it allows them to express what happens to data without concerns of persistence. This saves a lot of time and code.
As for saying that the swappable benefit only plays out in a very limited set of circumstances - that is not only wrong - it is crazy: Every day that I work on my projects, I develop not caring about what persistence store I use. It so happens that I do most of my development on a laptop using PostgreSQL. I then pass on my code to other developers who use Oracle. This is not trivial code - it is a major project with hundreds of thousands of lines of code, but they only need to change a few lines in a configuration file for my code to work with their database. A few more lines, and it would work with any of a dozen major relational databases, or an XML store or an Object Database. I have no more concern about which database I persist to than the nature of the file system driver that is used when I call a 'File.open' method.
As for the benefits - they are major. This means that development can be done, including substantial testing, off-site, and without requiring expensive hardware and licenses for specific hardware to run enterprise databases. It means that when my company develops products, the client can choose the database - I am not telling them which database they can use. It means that I can release smaller versions of software that will operate of, say, CSV files in low-memory machines, but without having to change a line of code. And, of course, there is the fantastic freedom from vendor tie-in.
It sounds to me like you seriously need to get up to date, and realise how things have changed.
That is not true.
:age_limit PARAMETERS double age_limit ORDER BY surname ASCENDING");
OK, then - I personally find OOP a highly useful abstraction. Popularity does also not equal bad!
For something very simple, yes. But not for non-trivial stuff.
If you look at real examples, it turns out that this approach is actually more powerful for the more complex stuff, as the abstraction saves time.
I've encountered this claim multiple times before and it turned out to be bogus when actual code example was given. They either leave out some important key limit, or use some bloated API that makes for very very verbose ugly code, almost like OOP "query" assembler. With enough effort you can wrap and swap anything, but the result can be far worse than what you wrap. Query languages are not "raw implementation", they can be a powerful abstraction tool if you know how to use them. I'll believe it when I see actual code (that doesn't have described flaws).
Well, there is no way to reply to that, as you are free to label any code I provide as ugly and verbose. What matters is does the API provide performance and productivity? My experience is, unquestionably, yes.
All I can say is that I actually use JDO 2.0 in precisely the way I have described: this is not imaginary.
Also, I am certainly not excluding the use of query languages. JDO 2.0 specifies a rich query language. The difference from, say, SQL, is that it is truly portable, and all implementations of JDO must provide all features of the JDO query language, no matter what platform and no matter what persistence method - no incomplete implementations of standards, as has always been the case with SQL.
Here is an example of using JDO 2.0:
pm.currentTransaction().begin();
Query query = pm.newQuery("SELECT UNIQUE FROM Person WHERE lastName == 'Jones' +
" && age
List results = query.execute(24);
That is it. Not verbose; nothing like query assembler.
OK, so in your example variable array is a full-fledged object.
As such, in this language, the program tracks the number of references to the object to know when this count goes to zero. Once this happens, a separate garbage-collection thread will run at some time we cannot predict to clean up the space this object is taking up. (As an aside, this is why finally clauses are needed in Java but not C++. In C++ the time at which objects are destroyed are well-defined, so we can use destructors to do necessary clean up precisely when we're leaving a try block.). Compare this to the C/C++ equivalent. There array is simply a block of memory. This memory is cleaned up precisely after we exit the block in which it was defined. Since it takes approximately 2 brain cells to know that the quantity we check in the for loop is the same as the number of elements we define array as having, there is no need to have any built-in bounds checking in the language in the first place.
Well, the history of C and C++ use over decades is that many developers don't possess those particular 2 brain cells, as buffer/array overrun problems are widespread.
I fail to see any big advantage with Java in this case. Quite the opposite.
You haven't actually given any reason why the Java approach should be disadvantageous - you have simply presented a series of facts.
The Java approach is unquestionably safer. And garbage collection can be extremely efficient - just as efficient as manual memory management, even on real-time systems.
I flat-out don't believe you. OOP API's in many ways are a lower-level abstraction than relational query languages.
But almost all coding is done in an OOP way these days, so it is highly useful abstraction.
And the features of those things you listed are not one-for-one exchangable. Let's see you do a 3-way join and then a GROUP-BY-like summary with flat files and handling multi-user concurrency without reinventing a database to pull it off.
You are missing the point completely. No-one is saying that you will get all the features of concurrent high-performance relational database no matter what type of persistence you use; the point is that you can use exactly the same code and queries for all those types of persistence. For example, I can open a transaction, define and run a query including joins and grouping, and retrieve objects, and modify them and have them be persisted when I close the transaction, no matter what persistence store I use - flat file, relational database and so on. Of course you don't get multi-user concurrency with flat files! But who cares? The point is that you get automatically get multi-user concurrency when you run the same code on a relational database without having to change a line of code.
Using Java and optimizing for performance is like using Windows and optimizing for stability, or like living in hell and optimizing for coolness.
Considering that the most profitable site on the internet, E-Bay, does exactly that, I would say, on balance, that you are wrong.
Funding has less to do with quality than whether the research supports or opposes the current paradigm.
A very broad statement, and wrong, but wrong in an interesting way. Paradigms usually become current when they get increasing evidence. This can attract researchers because they want to do research that will go somewhere, and not end up in a dead end. In order to get funding, you have to show that you are likely to find something new. So, simply saying 'I want to do more work to back up global warming' isn't going to be a good way to get funded, which is why you are wrong.
It doesn't take much reading of these threads to remove all optimism.
I am amazed that climate change deniers are brave enough to fly. After all, aerodynamics is only a consensus - there are still one or two people who think it all wrong, and such rebels are always right.
Certain of the measures are what we need to do anyway, and are potentially extremely good for economies (well, most of them) - devising ways of saving energy, finding new non-oil energy resources. We should be doing this anyway, for economic and political reasons.
And every scientist knows that you need a crisis to get funding? No?
No, of course not. The vast majority of science (including climate science) is extraordinarily dull, but gets funded because of the quality of previous research and ideas.
No - someone needs to boost their sarcasm generator. In order to be effective, sarcasm has to push beyond the extremes of what people say. Unfortunately, many climate change deniers have the view expressed.
But there is no way to do that.
Simply cutting back on emissions is not going to solve anything.
Actually, that is the only thing we have to do: cut back on CO2 emissions - problem solved.
Exactly correct. Everyone knows that the present of a specific scientific principle is decided by a central committee and then approved by the electorate at large. It's an excellent system, look how the Catholic church managed to keep us at the centre of universe!
If only that were so, then science would be so much easier. Unfortunately science is judged by hundreds of independent journals and through the review of thousands of scientists, many of whom are competing for the same funding you are and so are motivated to find holes in your work. Anyone who thinks science is a friendly group of like-minded souls all patting each other on the back really hasn't a clue.
I agree with this prediction. Database interfaces (such as SQL) do not dictate implimentation. Ideally, query languages only ask for what you want, not tell the computer how to do it.
This can be taken a stage further, with general persistence APIs. The idea is that you don't even require SQL or relational stores: you express queries in a more abstract way and let a persistence engine generate highly optimised SQL, or some other persistence process. I use the Java JDO 2.0 API like this: I can persist and retrieve information from relational stores, CSV, XML, LDAP, Object Databases or even flat text files using exactly the same code and queries, and yet I get optimised queries on each - if I persist to Oracle, the product knows enough about Oracle (and even the specific version of Oracle) to generate very otimised SQL.
Ok, it's not entirely his fault that he's clueless. These are fairly new technologies. Anyone who does database-backed applications for a living these days should crack open some books on this!
Object-relational mapping isn't new at all. Hibernate has been around for years, and TopLink, one of the products EJB 3 was based on, has been around since the early 90s.
That's the real reason the C model persists and will continue to persist, the computing world still needs a standard high level assembly language and won't give it up anytime soon.
The real problem was the widespread decision to use such a high level assembly language as if it were suitable for general purpose development.