3 ms·

Not simulation, but here is my example from finance which does things pretty similar to those in technical computing. First you want to prototype things and see

Not simulation, but here is my example from finance which does things pretty similar to those in technical computing. First you want to prototype things and see what works. You need low-overhead fast iteration interpreted language with good graphing abilities. This is usually Excel, sometimes Matlab, R, or Python. The solution that you get does not scale, so you roll up your sleeves and re-implement calculations in C++, C#, or Java (and in some cases more exotic languages like F#, Haskell or OCaml). Then you need to present these results to users, which means you need Visual Basic or C# to integrate that back into Excel, or C# or Java (or maybe Python) to build a standalone desktop GUI application or web application. At this point build and deployment is supported by a bunch of other technologies, like Makefiles, batch scripts, maven files and what not.

deleted 12y ago
[deleted]
tjradcliffe 12y ago
A large part of this is discipline and knowledge. There is nothing to stop you from writing a nice-looking, fast app in C++. I routinely do this kind of thing in a mix of C++ and Python because wxPython makes it easier to throw together a UI, but the development overhead for doing it in C++ is relatively small. There are very few algorithms in Matlab or R that you can't find in decent libs for C++, so translating is no big deal given you're going that way anyway. The question is: are we better to put resources into new special-purpose, highly-optimized-for-a-single-type-of-job languages like Julia (which for some reason the article talks about as universal, then admits at the end it is totally special purpose and unsuited for a whole bunch of applications)... or are we better off learning to use the tools we have with greater discipline? I generally opt for the latter. Changing our behaviour as developers will produce better results than building new tools. We have the tools to manage our processes now (CMake, for example, rather than Makefiles). We need to be disciplined about using them. If we aren't, no new tools will help that much.

deleted 12y ago

[deleted]

tjradcliffe 12y ago

A large part of this is discipline and knowledge. There is nothing to stop you from writing a nice-looking, fast app in C++. I routinely do this kind of thing in a mix of C++ and Python because wxPython makes it easier to throw together a UI, but the development overhead for doing it in C++ is relatively small. There are very few algorithms in Matlab or R that you can't find in decent libs for C++, so translating is no big deal given you're going that way anyway. The question is: are we better to put resources into new special-purpose, highly-optimized-for-a-single-type-of-job languages like Julia (which for some reason the article talks about as universal, then admits at the end it is totally special purpose and unsuited for a whole bunch of applications)... or are we better off learning to use the tools we have with greater discipline? I generally opt for the latter. Changing our behaviour as developers will produce better results than building new tools. We have the tools to manage our processes now (CMake, for example, rather than Makefiles). We need to be disciplined about using them. If we aren't, no new tools will help that much.