TopMind is often seen arguing about the inherent superiority of TOP to functional programming. He claims that 'smart' tables are much better than 'dumb' collections. However, I think that this is in fact a meaningless debate, because tables are merely a type of collection, and database queries are the higher-order operations that sort and filter and scan and update them.
This can be most clearly seen in the
LanguageIntegratedQuery [MS LINQ] project, essentially a
LispMacro in a language that doesn't have
LispMacros.
For instance,
from o <- someTable
where o.FrozzBozz
select o.FirstName + " " + o.LastName
translates to
someTable
.Filter( delegate (o) {return o.FrozzBozz()} )
.Map( delegate (o) {return o.FirstName + " " + o.LastName} )
In a language with a better syntax for anonymous functions, it would be:
someTable.filter(o => o.frozzBozz).map(o => o.firstName ++ " " ++ o.lastName)
or (shock!) you could get away with writing it cleanly
without the macro, as in:
someTable filter (_.frozzBozz) map (o => o.firstName ++ " " ++ o.lastName)
[this is
ScalaLanguage, which is really d*mn good at making
DomainSpecificLangauges without ever breaking out the macros.
RubyLanguage is also good for this...]
Order by?
(<some_long_query>).sort_by {|a| a.prod_num}
Even delete from:
date = now()
orderDB.reject! { |rec| rec.date < date - (7 years) }
Microsoft also offers a kind of "RAM table" type that allows one to do "regular" SQL on it. The advantage of this is that one can switch the implementation to a full RDBMS if the requirements grow without rewriting the queries. (I'm not sure if LINQ can do that for non-MS databases.) You are essentially reinventing a query languages with lots of "funny punctuation" in it. If we are going to start over, then let's plan a good query language this time (HowOtherQueryLanguagesAddressSqlFlaws). Ideally the query language should be app-language-independent such that I don't have to learn/use one query language for Ruby and another for PHP, etc. Query languages and GUI languages should strive to be app-language-independent in my opinion. -t
CategoryFunctionalProgramming