• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Necessary to learn C#?


You know one thing I get slightly suspicious about is that I never hear bad things about python.

An old friend of mine wrote this:

50 lines is fine. But dealing with someone else's 5000 line Python application is a nightmare. There is almost no guarantee you can make about any fragment of Python code. And large classes of bugs that compilers for many languages would catch often don't show up until runtime, often well into it, so if you write 50 lines of code you'd better make sure you wrote 200 lines of tests. But I use Python all the time for short throwaway applications. The libraries are pretty good.
 
Last edited:
50 lines is fine. But dealing with someone else's 5000 line Python application is a nightmare. There is almost no guarantee you can make about any fragment of Python code. And large classes of bugs that compilers for many languages would catch often don't show up until runtime, often well into it, so if you write 50 lines of code you'd better make sure you wrote 200 lines of tests. But I use Python all the time for short throwaway applications. The libraries are pretty good.

That was in fact my question. We are probably in the early adopter phase so the experience reports have yet to come in. Like in the halcyon days of C++ (1991) and Java (1997).

History has a strange way of repeating itself; as Fred Brooks said "no silver bullet".

// Is Python the new Matlab?
 
Last edited:
50 lines is fine. But dealing with someone else's 5000 line Python application is a nightmare. There is almost no guarantee you can make about any fragment of Python code. And large classes of bugs that compilers for many languages would catch often don't show up until runtime, often well into it, so if you write 50 lines of code you'd better make sure you wrote 200 lines of tests. But I use Python all the time for short throwaway applications. The libraries are pretty good.

That was in fact my question. We are probably in the early adopter phase so the experience reports have yet to come in. Like in the halcyon days of C++ (1991) and Java (1997).

History has a strange way of repeating itself; as Fred Brooks said "no silver bullet".

// Is Python the new Matlab?


No.

1) Python is a generic programming language. It can be used for matlab stuff, databases, shell scripting, web programming, server programming, building complete systems - basically everything.
2) Python is free, and open-source. If we need to explain to you why this is a significant advantage, all hope is lost.

As I said, Matlab's death has begun courtesy of python. Btw, python is not "new" - it's been around for 20 years now. Not old, but not new.
 
An old friend of mine wrote this:

Tbh, I don't buy that argument. You just move the errors from compilation stage to run-time stage, which makes little difference in the grand scheme of things. Proper testing and software engineering would eliminate those problems anyway. So it seems to me it's more a case of bad programming, rather than bad language.
 
Tbh, I don't buy that argument. You just move the errors from compilation stage to run-time stage, which makes little difference in the grand scheme of things. Proper testing and software engineering would eliminate those problems anyway. So it seems to me it's more a case of bad programming, rather than bad language.
BigBadWolf has historical precedent on his side. The software crisis is still with us.

Software systems become more unstable as time goes on. I don't believe any language can stop the rot because programmers do not know to to design systems beyond a certain level of complexity. They add on bits and pieces, leave the job and let others fix it, in many cases an extern IT company. Amen.

Today's developers are akin to the shoe makers in New England in the 18th century ... each pair of shoes was hand-crafted.

http://ab.mec.edu/departments/techinteg/resources/students/newlife/shoemaking.htm

Bad programming is caused by bad programmers. If a builder does a bad job, who do you blame?

Maybe Python is the saviour. Who knows you might be right.
 
Last edited:
Today's developers are akin to the shoe makers in New England in the 18th century ... each pair of shoes was hand-crafted.

Off on a tangent but we may need to re-learn these old skills again as our present era draws to a close. Some of those old skills will be calculating without computers:

http://thearchdruidreport.blogspot.com/2014/01/seven-sustainable-technologies.html

7. Computer-free mathematics. Until recently, it didn’t take a computer to crunch the numbers needed to build a bridge, navigate a ship, balance profits against losses, or do any of ten thousand other basic or not-so-basic mathematical operations; slide rules, nomographs, tables of logarithms, or the art of double-entry bookkeeping did the job. In the future, after computers stop being economically viable to maintain and replace, those same tasks will still need to be done, but the knowledge of how to do them without a computer is at high risk of being lost. If that knowledge can be gotten back into circulation and kept viable as the computer age winds down, a great many tasks that will need to be done in the deindustrial future will be much less problematic.
 
I think you're going to like PTVS: http://pytools.codeplex.com/

Polter,
I can imagine that some organisations would welcome this approach.

A good scenario (possible?) is to write the 50-line Python code and use C++ for integration?

Useful for 'dinos' like me ;)
 
...A good scenario (possible?) is to write the 50-line Python code and use C++ for integration?

Useful for 'dinos' like me ;)

I don't know what you mean by using C++ for integration. However, the common usage is to write mostly Python and use C/C++ when you need to really speed up some routines. Then you can integrate them by using something like Cython (this is usually the preferred method) or SWIG.
 
I don't know what you mean by using C++ for integration. However, the common usage is to write mostly Python and use C/C++ when you need to really speed up some routines. Then you can integrate them by using something like Cython (this is usually the preferred method) or SWIG.
For example, some parts in Python, some in C++. It's not just speed only but 1) legacy and critcal code 2) C++ libraries are robust, 3) and on.

Like in .NET, multi-language programming.
 
For example, some parts in Python, some in C++. It's not just speed only but 1) legacy and critcal code 2) C++ libraries are robust, 3) and on.

The same approach holds. Write code in python that calls or wraps the legacy code either using Cython or SWIG.

That C++ libraries are robust is a discussion for another day.
 
DD, yeah, essentially a way to do Alternate Hard And Soft Layers, Create Flexible Messaging, or Pave The Path:
http://c2.com/cgi/wiki?AlternateHardAndSoftLayers
http://c2.com/cgi/wiki?PaveThePath
http://c2.com/cgi/wiki?CreateFlexibleMessaging

A use case to consider is to have an embedded dynamic contract specification feature (I'd also consider Lua for this).
However, do make note of the trade-offs: http://c2.com/cgi/wiki?CanEndUsersScript

See also (some good discussions):
http://c2.com/cgi/wiki?SymbioticLanguages
http://c2.com/cgi/wiki?SeriousVersusScriptingLanguages
http://c2.com/cgi/wiki?DynamicLanguagesAndLargeApps

I'm not sure about SWIG -- it's relatively easy to use to for simple FFI generation for a simple code, but heard about it choking on some "real" C++ (not just C-with-classes) libs -- and I'm uncertain whether much of multi-language debugging is supported when going this way?
 
I'm not sure about SWIG -- it's relatively easy to use to for simple FFI generation for a simple code, but heard about it choking on some "real" C++ (not just C-with-classes) libs -- and I'm uncertain whether much of multi-language debugging is supported when going this way?
SWIG is a huge PIA for C++ when it gets complex. I have tried it once with the Numerix Library and hate it with passion.... but it's a possible solution though.
 
OK, I surrender. I tried a couple of things in a C# project and IronPython. I like it!


C++:
using System;
using IronPython.Hosting;
using Microsoft.Scripting;
using Microsoft.Scripting.Hosting;
 
// djd
 
namespace Python_CSharp_Combi
{
    class Program
    { // 2 layer (soft/hard)
 
        static void Main()
        {
            double result = (double)doit("2.0*3.0");
            Console.WriteLine(result);
 
            string rule = "A/B > 2.0";
 
            ScriptEngine eng = Python.CreateEngine();
            ScriptScope scope = eng.CreateScope();
            scope.SetVariable("A", 200m);
            scope.SetVariable("B", 10m);
 
            ScriptSource source = eng.CreateScriptSourceFromString(rule, SourceCodeKind.Expression);
            bool auditRequired = (bool)source.Execute(scope);
            Console.WriteLine(auditRequired);
        }
 
        static object doit(string exp)
        {
            ScriptEngine eng = Python.CreateEngine();
            return eng.Execute(exp);
        }
    }
}
 
Back
Top