SERVING THE QUANTITATIVE FINANCE COMMUNITY

 
User avatar
Cuchulainn
Topic Author
Posts: 61563
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Behold the Lambda Calculus

September 1st, 2012, 9:28 am

QuoteSlightly off-topic: what are your productivity levels when work > 48 hours.Henry Ford did not introduce the 5-day workling week because of idealism.QuoteDepends on what you do. You can't write good code or develop new models sitting 12h straight. But you can reconcile risk reports even longer than that, given good coffee supply.QuoteThe number of real lines of code per progammer per day is < 10. But a system manager can be active from 7 am to 7 pm because there are so many things to do.QuoteThe most productive coding days might as well end up with a net negative LOC. LOC is just not a good measure of anything other than file sizes.QuoteIn the distant future maybe code will look like APL or maths, i.e. 1-liners?QuoteMost likely something like that would just be massive abstractions. As long as it makes sense it's okay. APL is quite hard to grasp so I hope that's not what is to come. QuoteBehold the lambda calculus!
Last edited by Cuchulainn on August 31st, 2012, 10:00 pm, edited 1 time in total.
http://www.datasimfinancial.com
http://www.datasim.nl

Every Time We Teach a Child Something, We Keep Him from Inventing It Himself
Jean Piaget
 
User avatar
rmax
Posts: 6080
Joined: December 8th, 2005, 9:31 am

Behold the Lambda Calculus

September 3rd, 2012, 9:15 am

A fast and simple way to construct business solutions is required. Most solutions that I see in Finance are of 1 or 2 generic systems. They are not complex but just have slightly different non-functional requirements.Lambda calculus is probably too abstract as you would be dependent on the underlying implementation. I do advocate the following:1. Unambigous ways of communicating requirements2. Simpler implementations / for the majority of solutions in business. Ideally direct implementation from business requirements3. Simpler coding paradigmsTin-hat on: There seems to be many traps in C++ that are due to the inherent flexibility of the language that make it difficult to maintain (inheritance/operator overloading etc).There will always be a role for more complex languages. 10 LOC is a pretty more level (regardless of metric). Is the current proliferation of language due to salary or to need?
 
User avatar
Cuchulainn
Topic Author
Posts: 61563
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Behold the Lambda Calculus

September 3rd, 2012, 10:37 am

I agree with rmax (even on C++). When examining large, complex software systems, in the requirements analysis I use1. Domain architectures (I'm biased )http://www.datasimfinancial.com/forum/v ... php?t=4642. Wha are the requirements?http://en.wikipedia.org/wiki/ISO/IEC_9126Arsenal for the project management to reduce risk (and blood pressure).
Last edited by Cuchulainn on September 2nd, 2012, 10:00 pm, edited 1 time in total.
http://www.datasimfinancial.com
http://www.datasim.nl

Every Time We Teach a Child Something, We Keep Him from Inventing It Himself
Jean Piaget
 
User avatar
rmax
Posts: 6080
Joined: December 8th, 2005, 9:31 am

Behold the Lambda Calculus

September 3rd, 2012, 12:25 pm

QuoteOriginally posted by: CuchulainnI agree with rmax (even on C++). When examining large, complex software systems, in the requirements analysis I use1. Domain architectures (I'm biased )http://www.datasimfinancial.com/forum/v ... php?t=4642. Wha are the requirements?http://en.wikipedia.org/wiki/ISO/IEC_9126Arsenal for the project management to reduce risk (and blood pressure).You have mentioned these before. Whilst the IED 9126 is good at recognising a standard to measure quality, it does to address the linguistic issues that are present. Zachman used the idea of building a house as a good parable for building solutions and it is a good model. When you say to an archictect or builder Soffitt board they have in general the same idea as to what you are talking about. However when it comes to more avant garde designs I do not beleive the language is understood by clients and by architects and by builders - hence the issues. Not all building suffer. The Frank Gehry being a good exception.Software solution design in business needs to have a better language for describing the problem. A kind of loglan like in "The Moon is a Harsh Mistress". Natural language is far to ambgious. The problem is that the language needs to be understood by clients as well...As a rough rule of thumb 80% of business software should either be easily customised versions of pre-existing software. 19% should be written in something where people can't spend ages falling into traps and 1% should be the real cutting edge stuff where anything goes.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Behold the Lambda Calculus

September 3rd, 2012, 1:38 pm

Interesting! What is the productivity of programmers and how do we improve it?The hrs/week metric is like the serving size data on food labels -- it might indicate a central tendency, but the variance of actual values is huge. I've known people who can work very effectively for 60-80 hr/s per week for years on end and others who get physically/mentally spent doing more that 20 hr/wk or if they don't get a long weekend on regular basis.I agree that LOC is a horrible proxy for productivity. I've knew a guy who spent months reducing a piece of code from 5 lines to 4 (about -0.03 LOC/day!). Of course, it was the microcode for the MULT instruction in a big iron CPU so it made every piece of hardware made by the company 20% more productive on the multiply-accumulate benchmark.I agree with rmax about the role of languages but as with human languages, there's no single best one. APL is awesome awesome awesome for processing multi-dimensional numerical arrays and makes FORTRAN look like BASIC's crippled sister. Yet APL sucks dead donkey meat for state machine logic problems and has zero natural features for systems programming or UI stuff. Apple's Hypercard/Hyperscript was excellent for UI design but sucked on data structures and hardcore math.Zachman's analogy is good but falls apart when one realizes that some programmers need to build houses, some need to build seaports, some need to build airplanes, and some need to build proteins. They each need their own languages including both highly technical language elements (the polysyllabic words and complex structures that do the heavy lifting inside the black box) and the simpler pidgin language for interfacing with non-technical customers, users, and executives.
Last edited by Traden4Alpha on September 2nd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
alpher
Posts: 90
Joined: September 1st, 2012, 4:20 pm

Behold the Lambda Calculus

September 3rd, 2012, 4:25 pm

interesting topicso:loc, number of "features" implemented,type of language being used (e.q - object oriented, procedural, functional), hours work,is the software or part of it AI complete,is the software or part of it addressing NP complete problem,is UI programming involved,is memory handled automatically or by the programmer basically the fist half bove vs the rest and convert everything to a "rate" - then you have some index of productivity. But it will ALWAYS be subjective.
 
User avatar
Polter
Posts: 2526
Joined: April 29th, 2008, 4:55 pm

Behold the Lambda Calculus

September 3rd, 2012, 4:51 pm

I still like the "Decremental Development" approach expressed in "Simple Code" by Prof. Peter Sommerlad: http://wiki.hsr.ch/PeterSommerlad/files ... pdf"Reduce software size TO 10%- while keeping required functionality- while improving its quality- while improving its design> measure productivity by Lines of Code removed (LoCR)"Also relevant:1. Simple C++ (Vol.1) -- simpler code through better C++11 usage: http://wiki.hsr.ch/PeterSommerlad/files/2012ACCU-1.pdf2. Simple C++ (Vol.2) -- simpler generic & library code through better C++11 usage: http://wiki.hsr.ch/PeterSommerlad/files/2012ACCU-2.pdf
Last edited by Polter on September 2nd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Polter
Posts: 2526
Joined: April 29th, 2008, 4:55 pm

Behold the Lambda Calculus

September 3rd, 2012, 5:13 pm

Incidentally, I think assembling the ISS is a better analogy for developing software (not just an OS) than building a house.
 
User avatar
Cuchulainn
Topic Author
Posts: 61563
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Behold the Lambda Calculus

September 4th, 2012, 6:17 am

OSs are well-defined beasts and much is known about them (i.e. low risk). Now take market-driven software products with risky requirements. Then a risk-driven approach is needed IMO. The choice of programming language is the least of our worries. The challenges are organisational (e.g. people and politics), not technical.
Last edited by Cuchulainn on September 3rd, 2012, 10:00 pm, edited 1 time in total.
http://www.datasimfinancial.com
http://www.datasim.nl

Every Time We Teach a Child Something, We Keep Him from Inventing It Himself
Jean Piaget
 
User avatar
Cuchulainn
Topic Author
Posts: 61563
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Behold the Lambda Calculus

September 4th, 2012, 6:21 am

Quote"Reduce software size TO 10%- while keeping required functionality- while improving its quality- while improving its design> measure productivity by Lines of Code removed (LoCR)"This is a form of optimisation! And this proposal demands extra project time. Very, very seldom do developers reduce the software size, especially for large systems and under project pressure. I don't condone it, but copy-and-paste is the rule rather than the exception. A well-defind library (e.g. Boost) is another kettle of fish.But how can we be sure that we are creating the right product? The elephant in the room is _we_don't_understand_the_requirements_ Customer say: I want a good product on time and within budget! Especially for fixed price, no_cure_no_pay projects..
Last edited by Cuchulainn on September 3rd, 2012, 10:00 pm, edited 1 time in total.
http://www.datasimfinancial.com
http://www.datasim.nl

Every Time We Teach a Child Something, We Keep Him from Inventing It Himself
Jean Piaget
 
User avatar
rmax
Posts: 6080
Joined: December 8th, 2005, 9:31 am

Behold the Lambda Calculus

September 4th, 2012, 8:47 am

QuoteOriginally posted by: CuchulainnQuote"Reduce software size TO 10%- while keeping required functionality- while improving its quality- while improving its design> measure productivity by Lines of Code removed (LoCR)"This is a form of optimisation! And this proposal demands extra project time. Very, very seldom do developers reduce the software size, especially for large systems and under project pressure. I don't condone it, but copy-and-paste is the rule rather than the exception. A well-defind library (e.g. Boost) is another kettle of fish.But how can we be sure that we are creating the right product? The elephant in the room is _we_don't_understand_the_requirements_ Customer say: I want a good product on time and within budget! Especially for fixed price, no_cure_no_pay projects..I would change your "_we_don't_understand_the_requirements_ " to YOU_don't_understand_the_requirements_ However I think the issue is wider than just this. There are so often integration challenges in the technologies being used that causes immense pain in terms of delivery, let alone that the various components can have immense issues themselves (memory leaks etc). One only get a true scale of the challenges of any project if you down load the manual for the processor your are basing your build on...Then mix in budgets, conflicting priorities, personaility clashes, disagreements in approach etc etc etc.I read a paper that criticised the "average" project spend approach. I seem to remember that the average project spend is about 10MM USD. And overspends on average are around 10%-20%. The problem this is not normally distributed and their is a very long and very fat tail of projects that have put companies under...
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

Behold the Lambda Calculus

September 4th, 2012, 9:52 am

QuoteOriginally posted by: rmaxQuoteOriginally posted by: CuchulainnBut how can we be sure that we are creating the right product? The elephant in the room is _we_don't_understand_the_requirements_ I would change your "_we_don't_understand_the_requirements_ " to YOU_don't_understand_the_requirements_ And I'd change it to "No_one_understands_the_implications_of_the_requirements".I was recently at a small conference on planning where the business people complained about the complexity of off-the-shelf planning software and the vendors complained that they get planning software RFPs with a thousand lines items. What people asked for was not what would useful to them.Productivity in software must be seen in terms of an intersection of contextual factors and needs:-------Ultimately, the performance of a programmer must be measured by their effects on the organization's goals. Programmers can write all the lines of code they want in any language they want to whatever requirements they are given but if people can't use it, won't use it, or don't understand how to use it to get things done, then that code has negative value.
Last edited by Traden4Alpha on September 3rd, 2012, 10:00 pm, edited 1 time in total.
 
User avatar
Polter
Posts: 2526
Joined: April 29th, 2008, 4:55 pm

Behold the Lambda Calculus

September 4th, 2012, 10:23 am

QuoteOriginally posted by: CuchulainnOSs are well-defined beasts and much is known about them (i.e. low risk).Also a good illustration of how "building a house" is not a good analogy, of course.
 
User avatar
Cuchulainn
Topic Author
Posts: 61563
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Behold the Lambda Calculus

September 4th, 2012, 12:14 pm

QuoteOSs are well-defined beasts and much is known about them (i.e. low risk).QuoteAlso a good illustration of how "building a house" is not a good analogy, of course.The 'of course' part is not so obvious.I don't know; have any experience reports been written by someone who attempted it? BTW what is Zachman (method)?Remark:For OS design, the Microkernel architectural pattern (Dijkstra) seems to be influential. I would describe it as a supply/service chain model. It is also very difficult to get right, especially with votatile requirements. Then there is always a monolithic kernel.What are the criteria for any design choice?QuoteA house is built from lots of little general parts that are cut and put together in situ. They have to be put together from the bottom up. Thus, when the foundation has not been built, no substantial part has been built; all you have is a hole in the ground.By contrast, an operating system consists of complex components that can be developed in any order. When you have developed most of the components, most of the work is done. This is much more like the International Space Station than like a house. If most of the Space Station modules were in orbit but awaiting one other essential module, that would be like the GNU system in 1992. Most s/w systems are _not_ built on ISS analogy. There are many reasons why not, some technical but most are organisational. IMO ISS idea only works on a small % of problems.
Last edited by Cuchulainn on September 3rd, 2012, 10:00 pm, edited 1 time in total.
http://www.datasimfinancial.com
http://www.datasim.nl

Every Time We Teach a Child Something, We Keep Him from Inventing It Himself
Jean Piaget
 
User avatar
Cuchulainn
Topic Author
Posts: 61563
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

Behold the Lambda Calculus

September 4th, 2012, 12:39 pm

QuoteOriginally posted by: PolterIncidentally, I think assembling the ISS is a better analogy for developing software (not just an OS) than building a house.Looks like a lot of in-house fighting here What shall we call the OS! LOL
Last edited by Cuchulainn on September 3rd, 2012, 10:00 pm, edited 1 time in total.
http://www.datasimfinancial.com
http://www.datasim.nl

Every Time We Teach a Child Something, We Keep Him from Inventing It Himself
Jean Piaget
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


Twitter LinkedIn Instagram

JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...


GZIP: On