Programming Trends to Follow?

a_unique_person said:
Pi is your data.
Click to expand...

You didn't address the second and primary rebuttal of your argument at all.

Anyway, pi is not data in any meaningful sense. The program doesn't even have to store the calculated value of pi anywhere: maybe it's just displaying the most recently calculated digit briefly on screen as part of an art installation. But let's disregard that, and concentrate on the other objection I raised: that even for those computer programs that clearly do deal with data, data is not necessarily the driving aspect of modelling.
 
aggle-rithm said:
We should probably draw a distinction between data and persistence.
Click to expand...

I don't think it's a question so much of persistence as of conceptual integrity: A web-page being sent from a web-server to your browser is clearly a transfer of data (in the meaning "part of the data-model"), even if it's not persisted on either end. However, a value which has no existence1 independently of a program or computer system can not be said to be data in this sense.

Nobody would in all seriousness claim that, for instance, a loop index should be part of the data model. Likewise, button-presses in an elevator control system are not data. They are "merely inputs."


[1] Whether in a raw or transformed form.
 
Leif Roar said:
I don't think it's a question so much of persistence as of conceptual integrity: A web-page being sent from a web-server to your browser is clearly a transfer of data (in the meaning "part of the data-model"), even if it's not persisted on either end. However, a value which has no existence1 independently of a program or computer system can not be said to be data in this sense.
Click to expand...

That's similar to the way Domain Driven Design draws a distinction between an entity and a value, even though both can be complex data types. The value has no existence independent of an entity.
 
aggle-rithm said:
The value has no existence independent of an entity.
Click to expand...

That's not really correct. A value can indeed exist independently. The distinction lies in how the two define their identity. A value has no identity distinct from its content, whereas an entity does. For example, three Money values that all contain $100.00 are said to be the same (and thus interchangeable). They are distinguished by the information they hold. However, three Employee entities that all have the name John Smith are not necessarily the same. They are distinguished by something else (e.g. employee ID).
 
a_unique_person said:
Since all computing is about data in some way, the data is important, including the metadata.
Click to expand...

As Leif has already pointed out, this is not true. All computing involves information in some fashion, but not everything necessarily revolves around (or even uses) an organized and managed data-model. Regardless, you're ignoring the other term of the computing equation, which is behavior. Both are required for anything meaningful to be accomplished. Information is pointless if nothing is done with it, and code is pointless if there's nothing for it to operate upon.

Relational theory provides a means of managing complex data-models. Object orientation provides a means of managing complex behavioral-models. The two are designed to handle very different situations. Whether or not those situations exist, and their relative importance, depends on the context. It's naive to just walk into a new project and say, "Let's use Java and MySQL." It may be better to use Ruby and CouchDB, or perhaps Python and flat-files, or even BASH and no persistence whatsoever.
 
Last edited:
daSkeptic said:
As Leif has already pointed out, this is not true. All computing involves information in some fashion, but not everything necessarily revolves around (or even uses) an organized and managed data-model. Regardless, you're ignoring the other term of the computing equation, which is behavior. Both are required for anything meaningful to be accomplished. Information is pointless if nothing is done with it, and code is pointless if there's nothing for it to operate upon.

Relational theory provides a means of managing complex data-models. Object orientation provides a means of managing complex behavioral-models. The two are designed to handle very different situations. Whether or not those situations exist, and their relative importance, depends on the context. It's naive to just walk into a new project and say, "Let's use Java and MySQL." It may be better to use Ruby and CouchDB, or perhaps Python and flat-files, or even BASH and no persistence whatsoever.
Click to expand...

The "Third Manifesto" outlines an extension of the RDB to include

*code with native access to the RDB
*much better SQL which is easier to use
*definition of OO that is inherently part of the RDB, not just hack tacked onto it.

It was written specifically to address the behaviour of data or objects.

It combines the two elegantly. I would really like to see the result of as much effort had been put into this as into the current OO fad.

I still don't see why so many data structures by default are tree based, such as the average file system.
 
a_unique_person said:
The "Third Manifesto" outlines an extension of the RDB to include

*code with native access to the RDB
*much better SQL which is easier to use
*definition of OO that is inherently part of the RDB, not just hack tacked onto it.

It was written specifically to address the behaviour of data or objects.

It combines the two elegantly.
Click to expand...

Do you understand the purpose of the relational model?

I still don't see why so many data structures by default are tree based, such as the average file system.
Click to expand...

Think outside the computer. What hierarchies exist in the physical world?
 
a_unique_person said:
The "Third Manifesto" outlines an extension of the RDB to include

*code with native access to the RDB
*much better SQL which is easier to use
*definition of OO that is inherently part of the RDB, not just hack tacked onto it.

It was written specifically to address the behaviour of data or objects.
Click to expand...

This looks good on paper, but I believe that persistence and behavior are two separate issues, and should not be shoehorned into the same model. Perhaps that is why this hasn't been developed more thoroughly.

It combines the two elegantly. I would really like to see the result of as much effort had been put into this as into the current OO fad.
Click to expand...

The current OO fad has been going on for about 25 years.

I still don't see why so many data structures by default are tree based, such as the average file system.
Click to expand...

Many schemas in a RDMS are tree based as well. Just follow the dependencies through foreign keys and the tree structure begins to emerge.

On the other hand...with a lot of systems moving towards a distributed model, the structure is often dislocated at several carefully chosen points so parts of the structure can act independently. In many cases, these autonomous modules can make good use of a non-relational storage method.
 
The truth is, OO solves all the problems it was intended to solve IF USED CORRECTLY. The same is true of the SQL/relational model...there is nothing to keep a clueless organization from putting all their data into a single denormalized "God Table".

When I was doing tech support for Microsoft Access, there was an unfortunate lady who was having trouble with a database she had been putting together for several months. The more tables she added to it, the harder it was to enter new records.

Turns out all the tables had one-to-one constraints placed on them, so to insert a record in one you had to simultaneously insert records in all the others.

I used Viseo to draw up a more rational database design, then sent it to her with instructions to start over.
 
a_unique_person said:
Why does it seem to be the default structure for software development? There are more options.
Click to expand...

I'm sure it's the default structure for most enterprise software development, just because it matches up well with the actual conditions it's designed to model. I can see where there would be other applications (scientific, mathematical, etc.) in which different approaches might work better.
 
You must log in or register to reply here.

Back
Top Bottom