We need to be careful classifying. Domain-specific Language (DSL) has to be a distinct language, so you need to provide a language parser, translator etc, call it a "language".
When you use a set of certain operations within an existing language, it may be referred to as Domain-specific Programming. There is a term "API", but it supposes an interface to an external subsystem. For operations that manipulate certain data a term "Framework" could be used. However, as was said in a previous post, there is a problem with the placement of abstraction layers. By simply providing cover names for J primitives and using them directly on data objects, exposes too much fuss and detail on the business layer. This takes it away from being domain-specific. (Although quite curious from J language point of view, but not to the benefit of your desing). A couple of use cases of abstraction. 1. Q is a database framework built on top of K language. (You can download a training version and examine Q sources.) Note: while limited low-level structural verbs are exposed as English equivalents, the most of operations are consolidated into bulk routines, which hide the fuss, while themselves defined in vanilla K without the crippling of verbose English covers. With a small help of templates (which makes it part-DSL), it becomes an executable SQL-like notation--not translated. This makes it possible to mingle it with remaining raw structural operations, still being very high-level. 2. (Unrelated to domain-specific, but being an example of power of abstraction) This instance has to do with design-patterns, following a particular design pattern: Model-View-Controller. It is a recent contribution of a GUI Browser for JDB. It was based on a browser in an earlier addon data/sqlite. Surprising was forward compatibility and code-reuse that resulted from clear separation of layers. If you diff the two scripts, there'll be little overall changes, which are isolated in the specific area of the Model: actual interface with the database engine. No need for changes in View parts resulted from extracting variable fragments, such as TITLE, About text, File Open masks etc into separate definitions. A natural improvement to this would be applying yet another pattern, a pluggable Adaptor, in order to use a single shell with many interfaces to different database engines. Common to these examples is decisions about separation of layers and placement of abstractions. This contributes not only to better general understanding and maintainability, but allows to more efficiently exercise optimization--your current goal. > From: Alex Rufon <[EMAIL PROTECTED]> > > Yes, my use of J actually falls within the context of "Domain Specific > Language" and we call this EOE (English Object Engine). The idea was a > scripting language for specific operations in the Supply-Chain Industry > for handling well known operations like Raw Material Requirement, > Production Planning, etc. > > Hahahah. I remember that COBOL was built with the idea that it should be > English like. Wow. JOBOL may be appropriate. ==) heheheheheh. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Raul Miller > Sent: Saturday, September 20, 2008 11:15 AM > To: Programming forum > Subject: Re: [Jprogramming] Verb Sequence or Ranking problem? > > On Fri, Sep 19, 2008 at 10:24 PM, bill lam wrote: > > It is entertaining. Should deserve a name like JOBOL. > > It's certainly a valid programming technique. > > It's just not one I understand very well. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
