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 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.
>> 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.
> 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".
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)
