QuoteOriginally posted by: nocturne2Peter Norvig provides a similar argument - he demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan.Another paper showing how a bunch of patterns are directly supported in Haskell can be downloaded here.Luigi

QuoteOriginally posted by: lballabioQuoteOriginally posted by: nocturne2Peter Norvig provides a similar argument - he demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan.Another paper showing how a bunch of patterns are directly supported in Haskell can be downloaded here.LuigiAnd ...All the GOF and POSA can all be made generic, which is the way it should have been in the first place.Language differences are irrelevant, it's yer design that counts.

QuoteOriginally posted by: CuchulainnLanguage differences are irrelevant, it's yer design that counts.I just don't buy that in practice. Its the Turing Tarpit all over ("Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." - Perlis).In every real world system there is a complexity limit beyond which you dare not venture otherwise you'll never make the damn thing work (be maintainable, be evolvable, be performant, etc). Its for this reason that we have invented abstractions, such as c++, otherwise we'd just think I can do it all in C. Or assembly. Or toggle the hex in on the switches on the front of the machine. Each new level has let us build things that are possible with the lower level tools, but not practical with the lower level tools. My experience has been that the teams that ignore the more powerful tools do so at their own risk - they'll get left in the dust. If a more powerful tool than C++, such as allegro or haskell, is practical for you, then I'd say use it, add more value, beat your competitor and go home with a smile on your face. Dynamic architectures, distributed architectures with functions being passed over the nework, process tree networks, code generation on the fly, design patterns in code etc are all possible in C++ but not easy and often not done because of the complexity - most of it requires a guru and sacrifice of goats. Other languages make it trivial where say design patterns in code warrants a famous book in the C++ world. Erlang is another great example of a technology that makes it practical to build highly concurrent and distributed software almost trivially. Ericsson invented it to solve the problem of programming telephone switches; if you make a call in the UK you are almost certainly being connected by software in this high-level language. Telecoms guys prefer not to use UML either. Studies have shown the benefits of this in terms of very reliable high-performance software coming in on time/budget with low variance in programmer's performance. In the first part of a tutorial on Erlang you'll be doing things that require a team of hardened C++ and threading geeks to pull off in practice (and not just some noddy code, I mean properly engineered real world deploy it and my ass is on the line threading and networking code).Lets talk assembly code. Its still the way to go when you must have the last cycle in some circumstances. But the majority of programmers would 1) get easily beaten by a modern compiler that can do better scheduling and register allocation on say out of order or even worse whacky in-order processors like Itanium 2) couldn't quickly and reliably build systems of interesting size 3) would be far better off in the majority of cases using a higher-level tool. Games are a good example. Used to be relatively simple. Often coded with lots of assembly. These days the majority are written in higher-level languages and many include a whole bunch of the game written in a scripting language as its higher productivity. People like Tim Sweeney are crying out for even better higher-level languages - see his talk on this at the last POPL meeting. Some people get stuck with the sympthoms of Stockholm syndrome for whatever technology they are using. Others evolve.

Stunt,There are many wonderful languages out there if one had time to learn them. But many people are not IT gurus but engineers, quants, accountants .. who see language as a *tool*. Once it gets the job done, it's good enough. The two most successful languages were COBOL and Fortran. They are suited to the domains they were made for. A relevant question is: why does a language 'catch on'? Why has C++ become popular, for example? Will C# become popular? Who knows. P.S. Programming ability is one skill, and part of a larger skill set, it is part of the full business solution. In this case most people want to write QF apps.

Quote just don't buy that in practice. Its the Turing Tarpit all over ("Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." - Perlis).I know of Turing and what he did for his country. Who is Perlis?

QuoteOriginally posted by: CuchulainnThere are many wonderful languages out there if one had time to learn them. But many people are not IT gurus but engineers, quants, accountants .. who see language as a *tool*. Once it gets the job done, it's good enough. We're in violent agreement. When I joined this forum not that long ago, some of my first questions were to try to understand why C++ was so heavily used, since there are other tools that are significantly easier to use/more productive and are good enough for the job. I was seeking to understand why people were making life hard for themselves. Entertainingly enough I was slapped around a bit and at one point told "if c++ is too hard for you then perhaps you should consider an alternative career". Given the amount of pretty hardcore c++ I've written over the years, this left me rolling in the aisles. Since then I've had lots of educational interactions. I've been told off list in messages and emails that ocaml is in use (jane street are public about it), APL or kdb+ style languages, Mathematica, Matlab, R, Java, C# etc. bits of Smalltalk, python, and even ruby are out there as well. Several people have told me that C++ is, at their institution, used more by a cabal as a way to defend their way of doing things than as a productive tool that helps the quants/traders get the job done or the systems they need built. I've also been lucky enough to hear from folks that have a good need for systems software where I think C++ is the right tool for the job. I do know C++ well, and I've used it heavily in industry, I (with teams I've led) have delivered products in it that some banks may even have part of their infrastructure based on, and its based on this experience that I question its use in some problem areas. As I've said, I'm perfectly happy to use it where appropriate. I would expect that quantitative workers would approach something like language choice using some common sense and not dogmatically, and its been gratifying to hear that is the case, with the caveats I've mentioned above. Something I'm still trying to understand is the rather dramatic split between the IT departments and the quant/trading end of things. Currently it seems like they are often at odds in strange ways. But I haven't (yet?) worked in a finance company mod some consulting and even worse being trotted out by a large company I worked for to give a tech talk that was really a sales pitch. A manager/sales critter actually said to me to 1) explain well for 80% of the talk 2) lose all but the best for 15% but leave the rest wanting more and demanding the product and 3) blow the eyebrows off for the last 5% being as technical as possible to make it easier for him to sell add on consulting. Between that and some of the thing ending up on his expense reports, I'm glad to stay at the technical end of things..QuoteP.S. Programming ability is one skill, and part of a larger skill set, it is part of the full business solution. In this case most people want to write QF apps.Of course. Domain expertise is the main thing. This is true even in CS. Take compilers for instance. Good compiler folks earn 6 figure salaries in their mid 20s (dollars, in the US - for some reason the UK end pay crap salaries for systems programmers and thus have few good ones hanging around) their knowledge of math and algorithms for optimization (not in the operational research sense) and how to create software pipeline algorithms and so on. Not for their knowledge of some programming language or the ability to churn out code.A common pattern across other domains has been the creation of domain specfic languages which let the domain experts do their job better. Lexifi are attempting to break into the finance market using that.QuoteI know of Turing and what he did for his country. Who is Perlis? Alan Perlis. His epigrams are oft quoted in CS.By the way, you and I, and a couple of other folks seem to end up being regular debaters. I appreciate this, and also want to say I'm well aware I don't have all the answers I think, like many engineers I secretly enjoy a good technical argument. Or maybe there's nothing secret about it. So, I appreciate the discussion and hope its not too boring for all the lurkers!

btw for the curious, here is a link to erlang Erlang or here.

QuoteOriginally posted by: stuntprogrammerWhen I joined this forum not that long ago, some of my first questions were to try to understand why C++ was so heavily used, since there are other tools that are significantly easier to use/more productive and are good enough for the job. I was seeking to understand why people were making life hard for themselves. Stunt, aren't we the same person? One big productivity pit with C/C++ is the edit/compile/link/debug cycle, even with today's blazingly fast machines. Eclipse's "incremental compile/automatic build" feature for Java reduces this cycle to edit/debug. But the real treat is Lisp, as Mr. Graham put it:QuoteThere is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime. Running code at read-time lets users reprogram Lisp's syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp's use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea recently reinvented as XML.

QuoteOriginally posted by: nocturne2Anything is possible. You weren't by any chance the person who discussed interesting monte carlo performance results on the cell processor were you? I seem to recognise the nickname.