On Tue, Nov 2, 2010 at 5:03 AM, Jonathan Rochkind <[log in to unmask]> wrote:
> I would be very unlikely to use someone's homegrown library specific
> scripting language. However, if you want to make a library for an existing popular scripting
> language that handles your specific domain well, I'd be quite likely to use
> that if I had a problem with your domain and I was comfortable with the
> existing popular scripting language, i'd use it for sure.

Hmm. The balance between the old and tried, and the new and
experimental will, forever, cause these kinds of discussions. Now, I
agree with the basic sentiment of what you're saying, but ...

> Odds are your
> domain is not really "libraries" (that's not really a software problem
> domain), but perhaps as Patrick suggests "dealing with relationships among
> semantic objects", and then odds are libraries are not the only people
> interested in this problem domain.

I've worked in the three basic tiers of library development world; the
plain vanilla programming world, the semantic web world, and the dark
dungeons of the Cult of MARC. Is the domain of library IT solved by
the generic technologies used? No.

There's nothing bad about a DSL, in fact, I encourage it. If you want
to get away from MARC, say, then having a DSL that approaches meta
data on the programmatic level directly is a wonderful abstraction.
But yes, we have to separate API from language. And API is, mostly
these days, simply a function/method call on top of an abstraction,
and it processes your request with your input. A language, on the
other hand, will let you deal directly with that problem. Most DSLs
are functional abstraction pre-compiled.

The line between a library and a language perhaps these days are more
blurred than ever before, however there are certain things that I
think justifies a library DSL ;

 * focus on identity management
 * mergability on entities
 * large distributed sets
 * more defined line between data and meta data
 * controlled vocabularies and structures

There's generic tools for all of these, however no one central thing
that binds them all together in a seamless way, elegant or otherwise.
No platform binds these together in an easy nor elegant way, and
perhaps such a thing would be beneficial to the library community, to
create a language that tries to create a bridge between computer
programming and what you learn in library school.

But even if we all concede that a library DSL perhaps is not a
practical solution, I'd still like to see us work on it, for nothing
more than sussing out our actual needs and wants in the process. Don't
underestimate the process of doing something that will never
eventuate, even knowingly.

> Some people like ruby because of it's support for creating what they call
> "domain specific languages", which I think is a silly phrase, which really
> just means "a libraryAPI at the right level of abstraction for the tasks at
> hand, so you can accomplish the tasks at hand concisely and without repeated
> code."

Depends on the language. Perhaps this doesn't make sense in Ruby, but
it certainly does in Scala, Haskell, and perhaps more than any, Rebol.
Even Lisp and derivatives, who can create custom structures on the
fly, are well suited to create actual languages that redefine the
language's original syntax and structure. You can redefine the hell
out of C to create any language imaginable, too, even when you
shouldn't.

A well-defined API is not a bad thing, though, but an API are
basically semantic entities in a language to parse structures.
However, a language redefines the syntax used by that language. Sure
you can create a word "record" in an API that mimics, say, a MARC
record, but the interesting part is when you redefine the syntax to
work *with* that semantic concept, like ;

  external_repository {
     baseURI: 'http://example.com/',
     type: OAI-PHM
  }

  my_repository {
     baseURI: 'http://example.com/',
     type: RIF-CS
  }

  some_vocabulary {
     baseURI: 'http://example.com/vocab'
     type: thesauri
  }

  foreach record in external_repository [without tag 850] {
     inject into my_repository {
        with: exploded words ( tag 245 )
            when: match words in some_vocabulary ( NT > 2 )
            merge into: tag 850
     }
  }

Creating classes that deal with record merging based on identity
management and various standards would be trivial to script together
super-fast, because the underlying concepts for us is rather
well-known. Hacking this together in Java or otherwise is a test on
patience and sanity, because they are generic tools, even when known
library-type APIs are used. Of course lots of stuff is assumed in the
example, but these are well-understood assumptions (about merging
subject headings (like multiple tags handling, LCSH lookup, etc.),
about identity control, about word lookup (for example, I'm assuming
some form of stemming before matching), and on and on. A language that
half text manipulation and lookup, and half programming sounds like a
killer to me.

So this is not a *dumb* idea, nor is it one of simply saying "it's the
API, stupid." It does goes deeper than that. Not that you / we should
do it, but that's it a good exercise that should have happened. And,
heck, might even have happened.


Regards,

Alex
-- 
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---