On 11/01/2008, Patrick May <[EMAIL PROTECTED]> wrote: > > > > > > > On 9 Jan 2008, at 14:15, Steve Jones wrote: > > On 09/01/2008, Patrick May <[EMAIL PROTECTED]> wrote: > >> On 8 Jan 2008, at 06:11, Steve Jones wrote: > >> > >> But its true that it is sometimes required to have a few languages > >> where that makes sense but what concerns me is that people appear > >> to be heading towards creating lots of languages and starting from > >> a default position of "many languages good" when the mindset should > >> really be "why _won't_ this language work". > >> > >> <politician_mode> > >> That depends on the definition of "work." > >> </politician_mode> > >> > >> A good DSL can significantly decrease the number of lines of code > >> required to express a concept, thereby increasing the > >> understandability of the code and decreasing the maintenance cost. > >> It helps if the DSL can be easily built in the primary language; > >> unfortunately the current crop of popular languages aren't that > >> extensible. > > > > Number of lines != maintenance cost. > > True, but being able to work at a higher level of abstraction can > both reduce the number of lines to maintain and make errors more easy > to detect.
I can yes, but it can also (e.g. Perl) lead to "compressed" comprehension where you have to uncompress the information first before being able to understand it. > > > I can do list manipulation and > > sorting in LISP miles quicker than in Java/C/C++/Ruby et al, but the > > number of buggers who can maintain LISP code is very small. > > There's no need to call me names just because I'm not afraid of > parentheses. :) > > > Its like saying that the tertiary assignment is better than an if > > then else as its less lines and characters, that just isn't true. > > With a DSL it's saying that a command like "calculate VaR for > portfolio XYZ" is more maintainable than 50 lines of code spread over > four methods in three classes. Sort of agreed but how is this different form having those 50 lines in a library and having calculateVaR(XYZ); To me this is pretty much the same as a DSL and I wouldn't call a library a DSL. > > >> I agree, but these aren't DSLs (no, not even SQL). DSLs reflect > >> the important concepts in the problem domain. One of the best > >> examples is Emacs' elisp, a DSL focused on text manipulation. > >> Providing the same level of abstraction to financial services > >> applications or telecommunications systems would be a huge win both > >> in terms of development productivity and maintenance costs. > >> > > > > How is elisp a DSP but SQL isn't? One is focused on text another on > > data. BPEL is another odd one to exclude from the DSL camp. > > elisp is a DSL for text processing. SQL could be considered a DSL > for relational algebra, but not for business concepts per se. I'm just not sure how text processing is a business concept I guess. > > > If I see a DSL, or even a proposed DSL, that has this business centric > > language then great. But I'm skeptical given the issues with business > > language (lets call it technical English) and programming languages. > > Everything I've seen so far talk about that and then creates yet > > another technical programming language but potentially one that claims > > having the word "trade" in the syntax makes it a financial services > > DSL. > > We're definitely in agreement here. DSLs are incredibly difficult to > implement well in the current crop of popular languages. DSLs really > require the ability to modify the structure of the language itself, > adding new constructs, not just new libraries. This, however, gets > back to your point above regarding Lisp. > > > To me the business centric DSL sounds like the philosopher's stone of > > IT namely "the business will code this". > > That would require an implementation of the Universal Programming > Language with the single syntactic construct "doIt". :) I was once asked by a business person what it would take to solve a (nP Complete) problem, my reply was "a non-deterministic programming language", a week later I found out he had put out an RFI... three weeks later he mockingly told me "we've had 3 responses so what do you say about that". Oddly we never signed the contract with a supplier :) > > Regards, > > Patrick > > ---- > [EMAIL PROTECTED] > S P Engineering, Inc. > Large scale, mission-critical, distributed OO systems design and > implementation. > (C++, Java, Common Lisp, Jini, middleware, SOA) > >
