QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: TraderJoeTake your pick .This one was built by ex-colleagues of mine (Cambridge/Rotterdam). It was built for GIS applications and is a dynamic OO languages with run-time 'mixins'. The language was very flexible and knocking up GIS applications was very easy.Smalworld then became part of GE.MagikI would consider it a DSL. QuoteObjects are implemented in Magik using exemplars. Exemplars have similarities to classes in other programming languages such as Java, but with important differences. Magik supports multiple inheritance, and mixins (which implement functionality with no data). New instances are made by cloning an existing instance (which will typically be the exemplar but does not have to be).99 bottles of beer in 1189 languages!PS - Sorry for the threadjack.

Daniel,I find this is one of the essential issues in programming.Would you describe the path of a robot in C++ (in an off-line robot programming system)?You might probably argue for a task-oriented robot programming language, but implement inverse kinematics and dynamics in C++.IMO, many programmers do not distinguish between the literal part of programming and its operational semantics.We do literal programming in Mathematica (domain specific) but implement critical algorithms in C++, services in Java, user interaction in html,..),all tied together by clever link technologies.It is the AND-effect?

QuoteOriginally posted by: exneratunriskDaniel,I find this is one of the essential issues in programming.Would you describe the path of a robot in C++ (in an off-line robot programming system)?You might probably argue for a task-oriented robot programming language, but implement inverse kinematics and dynamics in C++.IMO, many programmers do not distinguish between the literal part of programming and its operational semantics.We do literal programming in Mathematica (domain specific) but implement critical algorithms in C++, services in Java, user interaction in html,..),all tied together by clever link technologies.It is the AND-effect?Exner,Ich arbeite gerne mit fachmenschen, sprache und 'umgebung' macht nichts aus edit: it would be good to have a library of modules that we could just use over and over again.

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: exneratunriskDaniel,I find this is one of the essential issues in programming.Would you describe the path of a robot in C++ (in an off-line robot programming system)?You might probably argue for a task-oriented robot programming language, but implement inverse kinematics and dynamics in C++.IMO, many programmers do not distinguish between the literal part of programming and its operational semantics.We do literal programming in Mathematica (domain specific) but implement critical algorithms in C++, services in Java, user interaction in html,..),all tied together by clever link technologies.It is the AND-effect?Exner,Ich arbeite gerne mit fachmenschen, sprache und 'umgebung' macht nichts aus edit: it would be good to have a library of modules that we could just use over and over again.Wouldn't we expect from a DSL that it does automatic model/algorithm/data selection, instead of providing a variety of modules?In which domains do we have consensus on models, algorithms, data for calibration,.... ? So, we have constructs like Valuate[MyOption, MyContractFeature, MyCashFlowSchedule, MyModel, MyMarketData, MyInput, MyOutput] instead of Valuate[MyOption]Designers of DSL need to be aware that they need to act as kind of "Supersolvers" or provide a language architecture (a uniform task description language / domain)which allows for model, algorithm,..plug ins?

QuoteWouldn't we expect from a DSL that it does automatic model/algorithm/data selection, instead of providing a variety of modules?It is not necessary imo. In certain well-defined utopian fields code generation might be possible. It might exist somewhere, I just have not seen it yet, and to be honest it is a bridge too far.We can standardise an M10 nut, but software is more difficult.QuoteIn which domains do we have consensus on models, algorithms, data for calibration,.... ? Some algorithms in Fortran, E.g. NAG libraries.MCAD is somewhat standardised.

I think the things that are standardised are a priori truths - no-one in their right mind would start thinking about implementing a function that calculates sine from an input unless they really had to. It is the a posteri functions where the abstract world puts rubber to the road and start modelling real things where there is a mushrooming of opnion / implementations etc.

QuoteOriginally posted by: rmaxI think the things that are standardised are a priori truths - no-one in their right mind would start thinking about implementing a function that calculates sine from an input unless they really had to. It is the a posteri functions where the abstract world puts rubber to the road and start modelling real things where there is a mushrooming of opnion / implementations etc.I do agree, but see the situation as more nuanced than a priori vs. a posteri. The real question is the trade-off between development of a new implementation versus reuse of an old one. For well-known (a priori) functions, the decision is strongly biased toward reuse. But even with extremely well implemented code, some situations will always call for a fresh implementation. For example, someone might implement their own sine function code for a special purpose or situation such as high speed with low accuracy or special hardware. There's no shame in re-inventing a wheel if: 1) re-invention is faster than adaptation 2) re-invention yields run-time performance or a performance envelope that was not available with existing code. The issue of DSLs clouds the re-invent vs. reuse decision. On the one hand, a good DSL lets one create new code, in the DSL's domain, that is superior to code created by a more generic language. A good DSL reduces developer labor, enables sophistication, and reduces domain-related bugs. On the other hand, a DSL often leads to greater amounts of re-invention because the DSL may lack the broad library of modules that are available in more popular languages.