Tables Are Collections

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