I want a language that is close to meDSL Creating a domain-specific language, with, of course, software to support it, can be worthwhile if the language allows a particular type of problems or solutions to them to be expressed more clearly than pre-existing languages would allow, and the type of problem in question reappears sufficiently often. Language Oriented Programming considers the creation of special-purpose languages for expressing problems a standard part of the problem solving process. Pure OOP is only part of the solution and Generic Programming allows more room for better modularity and black-box composition. Now there is just too much reinvention going on.

You must like Collector's collection (http://www.espenhaug.com/black_scholes.html) of Black-Scholes-Merton code in dozens of languages . My favorite is BS written in Postscript. When laserprinters first appeared, they contained the latest in micrprocessors. Some early printers has as much CPU power, RAM, and even disk space as a desktop PC. I remember wanting to create distributed programs to use the idle CPU cycles of the printer. Yet, as the Postscript for BSM code sample shows, it's not the most parsimonious language for mathematical processing.This notion of DSL and the other thread on programming language popularity does raise the issue of the purpose of a computer language. Is a computer language intended to communicate with the computer? Or is a computer language intended to communicate with other programmers? If it is the former, then DSL and niche languages have a role. If it is the latter, then it's a popularity contest in which the value of the language is more a function of how many other programmers know it.

In a lot of IBs and other firms I have seen people manafacture a DSLs, but have done it badly without realising that was what they were doing. DSLs are the way forward for 80% of the requirement for software development across all industries. Lotus Notes began to have the right idea way back with Lotus Notes 3 - sure it was a pretty cruddy platform, but (I for one hoped) that would change - but no they must have employed somone from Microsoft to stick a large spanner in the works and really mess it up. Now Notes is only good for... no you have got me on that one!

I'm very interested in DSLs. If you've ever watched the video lectures for the MIT SICP course, you'll see that they advocate DSLs as a favoured solution, citing a couple of examples.

QuoteOriginally posted by: rwinstonI'm very interested in DSLs. If you've ever watched the video lectures for the MIT SICP course, you'll see that they advocate DSLs as a favoured solution, citing a couple of examples.You mean? this Is there a video on DSL?

Actually , these are the specific lectures (the original ones by Abelson and Sussman), although you'll find a lot of other courses based on the textbook and content from this original coursehttp://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/These lectures were actually filmed for a private training course for HP employees, and very good they are too. One of the early ones (can't remember which one) looks at a DSL for creating fractal-like patterns.

The word 'Domain' has many definitions but I was thinking of Little Languages here. Jon BentleyQuoteIn the appendix to the first edition of Programming Pearls, he gives out ten pieces of engineering advice: 1. Work on the right problem. 2. Explore the design space of solutions. 3. Look at the data. 4. Use the back of the envelope. 5. Exploit symmetry. 6. Design with components. 7. Build prototypes. 8. Make tradeoffs when you have to. 9. Keep it simple. 10. Strive for elegance. Many applications and libraries founder because they fail to satisfy one or more of the above features. With OOP I see it falling at #9. And #6 is not used. How many s/w developers build scale models/prototypes (#7)?These are like laws of physics in Software. That's why I am not hopeful of yet another library in C# and Java. You have to address the above problems.

Not sure about #10. Sometimes elegant bits of code are very nasty for other people to understand, and hence difficult to maintain. At the risk of wrath from the irish hero: C++ is full of features that will make it very elegant however difficult to understand and wade through when tight coding standards are not used.

QuoteOriginally posted by: rmaxNot sure about #10. Sometimes elegant bits of code are very nasty for other people to understand, and hence difficult to maintain. At the risk of wrath from the irish hero: C++ is full of features that will make it very elegant however difficult to understand and wade through when tight coding standards are not used.In defence of C++, what the software world has not succeeded in yet is making the use of languages easier for 'casual' developers (i.e. those who do not use it on a daily basis). I agree that C++ is difficult (especially templates). There is a need to develop simpler interfaces (facades) consisting of domain-specific operations that are easier for quants to learn. Unfortunately, this seems not to be the focus in s/w.Plan B is that C# takes some of the pain away. Again, you can make it unmaintainable as you wish but there is less danger of doing any real damage.On point #10, I always try to model a system using decomposition (Whole part), stick on an envelope and carry on from there. All those objects will come in their own good time. A good example is to model fixed-income structured products in this way .

QuoteOriginally posted by: CuchulainnQuoteOn point #10, I always try to model a system using decomposition (Whole part), stick on an envelope and carry on from there. All those objects will come in their own good time. A good example is to model fixed-income structured products in this way .Out of interest, do you get much uptake on your classes for the various product classes - is there a taxonomy that firms are willing to buy into, even if it does not quite match their own?

QuoteOriginally posted by: rmaxQuoteOriginally posted by: CuchulainnQuoteOn point #10, I always try to model a system using decomposition (Whole part), stick on an envelope and carry on from there. All those objects will come in their own good time. A good example is to model fixed-income structured products in this way .Out of interest, do you get much uptake on your classes for the various product classes - is there a taxonomy that firms are willing to buy into, even if it does not quite match their own?What many people are interested in are the algorithms (that's clear) while the I/O parts are less important at that moment. Important is how to model a product (whole-part) in terms of its building blocks and this needs some more emphasis IMHO. Traders like to structure in this way. Now, instead of top-down OO class hierarchy (or maybe, as well ) we compose a structured products from existing components with standardised provides/requires interfaces? Much easier...

Take your pick .

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

Hello World in 366 languages. (I like the assembler).Apparently (another thread) Goldman Sachs use their own proprietary code.

oops dbl