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 ---