too much OOP ?
in [OOP]
|
Prev: Should class code access private members or public wrappers for those private members?
Next: Should class code access private members or public wrappers forthose private members?
From: Thomas Gagne on 10 Jan 2008 06:46 frebe wrote: > > One way of telling if something is high-level or not, is to compare > the amount of source code to write to accomplish a given task. True, but SQL doesn't really know what an order or payment is, does it? A higher-generation language would know what those things are and what can be done with them. Someone familiar with orders and payments should be able to look at the higher-order language and recognize what's happening more easily than looking at the SQL. -- Visit <http://blogs.instreamco.com/anything.php> to read my rants on technology and the finance industry. Visit <http://tggagne.blogspot.com/> for politics, society and culture.
From: frebe on 10 Jan 2008 08:30 > > One way of telling if something is high-level or not, is to compare > > the amount of source code to write to accomplish a given task. > > True, but SQL doesn't really know what an order or payment is, does it? > A higher-generation language would know what those things are and what > can be done with them. Someone familiar with orders and payments should > be able to look at the higher-order language and recognize what's > happening more easily than looking at the SQL. No programming language knows what an order or payment is. In most cases the programmers writing the code, doesn't know either. If the SQL statement above can be written in any other language, so that it is easier to recognize what's happening, that would indeed be a more high-level lanugage. Can you give some examples? //frebe
From: Thomas Gagne on 10 Jan 2008 09:35 frebe wrote: >>> One way of telling if something is high-level or not, is to compare >>> the amount of source code to write to accomplish a given task. >>> >> True, but SQL doesn't really know what an order or payment is, does it? >> A higher-generation language would know what those things are and what >> can be done with them. Someone familiar with orders and payments should >> be able to look at the higher-order language and recognize what's >> happening more easily than looking at the SQL. >> > > No programming language knows what an order or payment is. In most > cases the programmers writing the code, doesn't know either. > > If the SQL statement above can be written in any other language, so > that it is easier to recognize what's happening, that would indeed be > a more high-level lanugage. Can you give some examples? > > //frebe > Well, not in inventory. But I can give an example in banking. 10023-8;csp;100.00 For a teller at a credit union, the language above says $100 cash was received for the purchase of an equal amount of shares to be recorded to the account number 10023-8. There were thousands of such transactions. The language's syntax was strict, but once master it was predictable--and quick to type. Being brief was a design feature so processing transactions--including the time to enter them--required as little time as possible. That's important when a lobby is crowded and people are anxious to get back to the office. A 4-or-5th-generation language, I think, isn't intended to become increasing abstract or closer to humans as much as they should become increasing specific to an application domain. In this case it's credit union transactions. In another it may be stock trading or buy and selling short-term commercial paper. The language itself expresses high-level concepts and knows the rules for interpreting them into their next less-business-specific but more-machine-specific instructions. I think the expectation that 4-or-5GLs would be general purpose languages is a huge mistake on many programmers part. A GUI is a good example of a 4GL. The only thing Amazon's interface is good for is buying things from Amazon. It's wouldn't apply to buying Bud Lite from my local convenience store, even if after much processing the transactions all end up on my charge card. -- Visit <http://blogs.instreamco.com/anything.php> to read my rants on technology and the finance industry. Visit <http://tggagne.blogspot.com/> for politics, society and culture.
From: Phlip on 10 Jan 2008 09:56 frebe wrote: > One way of telling if something is high-level or not, is to compare > the amount of source code to write to accomplish a given task. I'd go with a different rationale for SQL. Not just it altitude. SQL is a "domain-specific language" - a language invented to target one domain-specific scenario. Some DSLs use their own grammar, and some are expressed within a host language. SQL's domain is data relations. We should use a DSL if we need to step out of one paradigm (such as OO), and into another one - such as declarative. > Lets > say I want to find all orders that are not fully paid. In SQL it would > look like this: > > select orderid > from order o > join orderrow r on r.orderid=o.orderid > join payment_allocation a on a.orderid=o.orderid > having sum(r.amount) > sum(a.amount) > > If you write the solution in any other language, we could compare the > source code, and tell which language is the most high level for this > kind of tasks. Here's how to declare that in Rails's ActiveRecord: OrderId.find( :all, :include => [:order_rows, payment_allocations], :conditions => 'sum(order_rows.amount) > sum(payment_allocations.amount)' ) The join conditions went to where they belong - has_many directives in the OrderRow and PaymentAllocation model classes. And that ActiveRecord statement could be considered higher-level than SQL. It's also a DSL. It's the moral equivalent of K&C C generating very transparent Assembler for us. So here SQL is the low-level language. -- Phlip
From: frebe on 10 Jan 2008 11:37
> > One way of telling if something is high-level or not, is to compare > > the amount of source code to write to accomplish a given task. > > I'd go with a different rationale for SQL. Not just it altitude. > > SQL is a "domain-specific language" - a language invented to target one > domain-specific scenario. But data management is a pretty wide scenario. > Some DSLs use their own grammar, and some are > expressed within a host language. Many SQL dialects like PL/SQL are Tuning complete and doesn't need a host language. > > Lets > > > say I want to find all orders that are not fully paid. In SQL it would > > look like this: > > > select orderid > > from order o > > join orderrow r on r.orderid=o.orderid > > join payment_allocation a on a.orderid=o.orderid > > having sum(r.amount) > sum(a.amount) > > > If you write the solution in any other language, we could compare the > > source code, and tell which language is the most high level for this > > kind of tasks. > > Here's how to declare that in Rails's ActiveRecord: > > OrderId.find( :all, :include => [:order_rows, payment_allocations], > :conditions => 'sum(order_rows.amount) > sum(payment_allocations.amount)' ) > > The join conditions went to where they belong - has_many directives in the > OrderRow and PaymentAllocation model classes. > And that ActiveRecord statement could be considered higher-level than SQL. Some SQL dialects do support natural joins (you don't have to specify the joins columns when foreign keys exists or the column names are equal). In that case, SQL and ActiveRecord could be considered on the same level. There are also some annoying limitations in ActiveRecord, such as every table/relation can only have one column in the primary key. ActiveRecord is too much emulating the network model (but using the relational model as back-end). //frebe |