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. 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. 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. > > In support (where skills are not normally as high as in development) having > multiple languages, especially "optimal" and esoteric DSLs doesn't reduce > costs. The key is to have a limited set of languages, so Java (for example) > for basic app development, BPEL for process, SQL for databases etc. Having > Ruby & Java & PHP & C(where is the sharp key on a mac?) > > > Alt-3 > > > > & VB & Ada & PSQL & Perl & JavaScript etc etc for the application ! > development is a right pain in the arse, > > > 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. 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. To me the business centric DSL sounds like the philosopher's stone of IT namely "the business will code this". > > > 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) > > > > > >
