Well, fair point about too many languages, and people getting carried away thinking it's ok to use as many languages as possible. But I also think you summarized a key point pretty well, which is finding the right set of complementary languages and avoiding using languages that overlap each other too much.
Eric ----- Original Message ---- From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, January 8, 2008 6:11:11 AM Subject: Re: [service-orientated-architecture] Predictions for this Group in 2008 Actually I'm pretty sure that any single Turing complete language on a Turing complete computer can do everything that all the DSLs in the world can do :) 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". 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?) & VB & Ada & PSQL & Perl & JavaScript etc etc for the application development is a right pain in the arse, Having one application that contained Java&Ruby&Perl&C&SQL&VB would increase costs. Having JavaScript for the "active GUI" bit, Java (or Ruby) for the application bit and then SQL for the database bit could decrease costs (although replacing the SQL with a Java/Object centric approach would be cheaper than using Stored Procs). My issue is with the mindset which thinks that multiple languages is the best thing. its that mindset that put scripting into Java SE as "standard", hence why I'm not a fan of the latest DSL craze. I'm not sure how it actually moves us forwards rather than sideways. Steve On 07/01/2008, Eric Newcomer <[EMAIL PROTECTED] com> wrote: IMHO a set of easy to join DSLs will help reduce cost more than a single general purpose language that attempts to do it all...no language can, and as you said there have been many attempts such as Ada to prove the point. It's a nice idea - if the world could only agree on a single programming language things would be rosy (or should I say Ruby) but I for one don't anymore think that will be possible. Eric ----- Original Message ---- From: Steve Jones < jones.steveg@ gmail.com> To: service-orientated- architecture@ yahoogroups. com Sent: Sunday, January 6, 2008 2:23:12 PM Subject: Re: [service-orientated -architecture] Predictions for this Group in 2008 On 04/01/2008, Eric Newcomer <[EMAIL PROTECTED] com > wrote: > > > > > > > > > > Hi Steve, > > > > Good examples of DSLs that are already helping with some of these problems > include > SQL, JavaScript/Ajax, and Erlang (maybe that's a stretch but I believe it was > designed for > a specific purpose). > Which are fine, but are they DSLs or just technical programming languages for a specific purpose? Many purported DSLs are just other general languages that are better at certain specific tasks rather than being domain specific. Like the way LISP is better at lists than C but I wouldn't say that LISP was a DSL. > > > Simply put, DSLs recognize the fact that no general purpose programming > language is > good at everything, and in human terms the more that's crammed into a > language such > as Java the more difficult it is to learn and master. Breaking the problem up > helps with > things like division of labor, creating the right tool for the right job, > etc. You will find (I > believe) people who swear by Ruby on Rails because of its built in data > handling > capabilities. Different languages have different strengths, in other words, > which creates > overall benefit. Also however multiple languages cause disconnects in support and tend to drive up support costs to a large, potentially exponetial degree as they reduce the amount of industrialisation that can be done. This was something that the DoD discovered in the 1970s and which led to the definition of Ada. Now Ada wasn't a success but I haven't seen any research since that says that mutliple technical languages don't increase support costs. My point on DSL v new general langauge is born out by Ruby, its a new general language that has some potentially better data handling bits. What is the "domain" of Ruby? > > > > In the area of integration, an interesting emerging trend has been the > identification of > common patterns. Using a DSL to implement an integration pattern greatly > simplifies its > use. People can express an integration pattern using a few DSL keywords. Now this could be good, but I think we often in IT focus on reducing the 10% of software cost in development and ignoring the 90% of cost in support. Steve > > > > Eric > > > > ----- Original Message ---- > From: Steve Jones <jones.steveg@ gmail.com > > To: service-orientated- architecture@ yahoogroups. com > > Sent: Friday, January 4, 2008 10:17:35 AM > Subject: Re: [service-orientated -architecture] Predictions for this Group in > 2008 > > > > > Is DSL actually a problem or just something that IT technologists would like > to do? What is the problem that DSLs actually solve and how do these DSLs > reduce the TCO of ownership of systems and the complexity of IT estates. > > I'm sure that DSLs will gain ground, but I'm not convinced that there are > benefits. > > > On 28/12/2007, Eric Newcomer < [EMAIL PROTECTED] com> wrote: > > > > > > > > > > > > > > > > > > I think this just goes to validate the conclusion of the W3C workshop earlier this year - people are using both REST and SOAP based approaches and getting value out of them. > > > > What I think we have solved (at least I would hope so) is that people on > > both sides have begun to acknowledge the reality of this situation. The > > world is neither entirely REST-oriented nor SOAP-oriented and is not likely > > to be any time soon. I think it's time to move on to the next problem, > > maybe domain specific languages... ? > > > > Eric > > > > > > ----- Original Message ---- > > From: Mark Baker < [EMAIL PROTECTED] org> > > To: service-orientated- architecture@ yahoogroups. com > > Sent: Thursday, December 27, 2007 3:40:28 PM > > Subject: Re: [service-orientated -architecture] Predictions for this Group > > in 2008 > > > > > > > > > > On 12/22/07, jeffrschneider <jeffrschneider@ hotmail.com> wrote: > > > 7. Mark Baker, aka, "I wont rest until you REST", finally gets to > > > rest. Congrats Mark. > > > > Promise? For every new RESTafarian convert, it seems like a couple > > more naysayers-sans- clue pop out of the woodwork, e.g. > > > > http://wisdomofgane sh.blogspot. com/2007/ 12/paying- restafarians- back-in-their- own.html > > > > But thanks for the kind words. It's been a long time coming 8-) > > > > Mark. > > -- > > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbake r.ca > > Coactus; Web-inspired integration strategies http://www.coactus. com > > > > > > > > ____________ _________ _________ __ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. > > > > > > > > > > ____________ _________ _________ __ Looking for last minute shopping deals? Find them fast with Yahoo! Search. > > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. <!-- #ygrp-mkp{ border:1px solid #d8d8d8;font-family:Arial;margin:14px 0px;padding:0px 14px;} #ygrp-mkp hr{ border:1px solid #d8d8d8;} #ygrp-mkp #hd{ color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px 0px;} #ygrp-mkp #ads{ margin-bottom:10px;} #ygrp-mkp .ad{ padding:0 0;} #ygrp-mkp .ad a{ color:#0000ff;text-decoration:none;} --> <!-- #ygrp-sponsor #ygrp-lc{ font-family:Arial;} #ygrp-sponsor #ygrp-lc #hd{ margin:10px 0px;font-weight:bold;font-size:78%;line-height:122%;} #ygrp-sponsor #ygrp-lc .ad{ margin-bottom:10px;padding:0 0;} --> <!-- #ygrp-mlmsg {font-size:13px;font-family:arial, helvetica, clean, sans-serif;} #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select, input, textarea {font:99% arial, helvetica, clean, sans-serif;} #ygrp-mlmsg pre, code {font:115% monospace;} #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family:Georgia; } #ygrp-text p{ margin:0 0 1em 0;} #ygrp-tpmsgs{ font-family:Arial; clear:both;} #ygrp-vitnav{ padding-top:10px;font-family:Verdana;font-size:77%;margin:0;} #ygrp-vitnav a{ padding:0 1px;} #ygrp-actbar{ clear:both;margin:25px 0;white-space:nowrap;color:#666;text-align:right;} #ygrp-actbar .left{ float:left;white-space:nowrap;} .bld{font-weight:bold;} #ygrp-grft{ font-family:Verdana;font-size:77%;padding:15px 0;} #ygrp-ft{ font-family:verdana;font-size:77%;border-top:1px solid #666; padding:5px 0; } #ygrp-mlmsg #logo{ padding-bottom:10px;} #ygrp-vital{ background-color:#e0ecee;margin-bottom:20px;padding:2px 0 8px 8px;} #ygrp-vital #vithd{ font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;} #ygrp-vital ul{ padding:0;margin:2px 0;} #ygrp-vital ul li{ list-style-type:none;clear:both;border:1px solid #e0ecee; } #ygrp-vital ul li .ct{ font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;} #ygrp-vital ul li .cat{ font-weight:bold;} #ygrp-vital a{ text-decoration:none;} #ygrp-vital a:hover{ text-decoration:underline;} #ygrp-sponsor #hd{ color:#999;font-size:77%;} #ygrp-sponsor #ov{ padding:6px 13px;background-color:#e0ecee;margin-bottom:20px;} #ygrp-sponsor #ov ul{ padding:0 0 0 8px;margin:0;} #ygrp-sponsor #ov li{ list-style-type:square;padding:6px 0;font-size:77%;} #ygrp-sponsor #ov li a{ text-decoration:none;font-size:130%;} #ygrp-sponsor #nc{ background-color:#eee;margin-bottom:20px;padding:0 8px;} #ygrp-sponsor .ad{ padding:8px 0;} #ygrp-sponsor .ad #hd1{ font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;} #ygrp-sponsor .ad a{ text-decoration:none;} #ygrp-sponsor .ad a:hover{ text-decoration:underline;} #ygrp-sponsor .ad p{ margin:0;} o{font-size:0;} .MsoNormal{ margin:0 0 0 0;} #ygrp-text tt{ font-size:120%;} blockquote{margin:0 0 0 4px;} .replbq{margin:4;} --> ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
