This would save so many man hours... At my shop, for every MATLAB engineer (mostly older guys) you need a C++ guru (mostly younger guys) to translate his stuff into something that will run fast.
On the other hand having seen the code the MATLAB folks write... I'd be worried. It's possible to write MATLAB in a way that is clean and makes the core algorithm presentable but that's rarely a priority. The real advantage of MATLAB is the quick development cycle. With the right packages you can make C++ look comparable... sorta.
Fundamentally the problem with MATLAB engineers is that they don't understand how to optimize code b/c they don't understand what's going on under the hood and they don't understand how to organize code b/c they don't have a concept of object oriented development, writing to interfaces, design patterns etc. etc.
EDIT: Just to clarify, I don't mean to denigrate MATLAB engineers. I'm just saying that in the current system you have two groups that specialize in different things. One focuses on algorithm development, and one on programming. I'm just speculating that maybe there is a good reason for it, and it may be unreasonable to ask one person to do both.
From what I've seen - it's incredibly hard to find a good engineer that knows his stuff. They generally have PhDs and years of training in math and whatever particular field they work on. If you get one that is actually doing novel algorithm development, each one is a golden goose that will bring in revenue for the company for years to come.
By contrast if you offer a decent salary you can get a good C++ programmer with 3-4 years of experience to do all your C++ grunt work. (we hire CS students from the local University, and bring them up to speed within 6 months)
While not incredibly hard, the problem with learning "appropriate structure for long term maintainability and production use" is that it takes an awfully long amount of time. You need to go through a lot of trial and error and learning from your mistakes. You need to read programming textbooks, and keep up with the latest trends. It's actually a huge time investment.
> it's incredibly hard to find a good engineer that knows
> his stuff. They generally have PhDs and years of
> training in math and whatever particular field they work
> on. If you get one that is actually doing novel
> algorithm development, each one is a golden goose that
> will bring in revenue for the company for years to come.
Like ritchiea, I admit I don't have a huge breadth of experience, but I've worked with enough PhDs to say with confidence that, more often than not, they represent a net negative contribution to an engineering team. Novel algorithms aren't useful if they can't run in production, and the PhD's I've known, with one or two exceptions, lacked both the ability and desire to produce production-quality code. I grew to deeply resent those "engineers" who would read papers for half the day, make buggy commits to prototype repos that never got released, and refuse requests from both peers and managers alike to contribute to the team's extant backlogs.I know what you're talking about.
However outside of SV there are a lot of places where that's simply not the case. What you have is basically a cross disciplinary collaboration where you just don't have the educational background nor the expertise to do the engineering yourself.
The resentment your describing is really the same resentment you can feel towards your boss -"All he does is tell us what to do. He's not in the trenches like us!" - and it's directly related to the amount of mutual respect. In essence, how hard do you feel the other person is working relative to you.
Your description of your coworkers seems to indicate that you didn't feel like they're pulling their weight, and that's definitely a big problem.
I've heard second hand that in the valley there are a lot of incompetent PhDs that use their educational background as leverage to slack off. People will often hire graduates solely based on a degree thinking that if someone has a Math PhD "they're smart, they can learn on the job, and they'll contribute in some magical way just by being there". But actually these guys have just spent 5 years in poverty getting an advanced degree and don't want to be a code monkeys with a bunch of fresh out of college 21 year-olds. And, oh yeah - reality check, no one cares about their degree in abstract algebra.
9/10 of these PhDs are crappy engineers and 9/10 times they are thrown at problems they don't really have a background in (so they can't even be crappy and regurgitate equations they're memorized).
Think of the people that for example made the traction control system for your car. You think the same person that worked out the math in some simulation in MATLAB wrote the code that went on the controller circuit? It's not impossible, but it's not likely.
Closer to home, you can think of companies like Leap Motion, the Oculus folks, the Kinect people. Often companies that deal with video processing or control systems depend on a core set of algorithms to set them apart from the competition. The engineers behind it generally have a high level of understanding of linear algebra and often statistics and 15+ years of experience in a field.
It's very hard (though in many areas not impossible) for a programmer to learn that stuff to a level where they can innovate and contribute - so you end up relying on specially trained people who don't know about inheritance and how to use git hahaha
Where I work algo development is done by about 50% PhDs, 25% MAs and 25% BA/BS.
Having one language that spans more of the space from the bare metal (C-like fine-grained numerical manipulation) to the top level (say, training a complex model on a large dataset in a REPL) would be very helpful.
I'm actually working on related prototyping then deploy tools myself for numerical computing. Albeit using ghc Haskell as the substrate so I'm making a different set of tradeoffs than julia.
Now give me some plotting and good Qt bindings, and I'm all set!
cc -o myprog myprog.c -ljulia
and be able to call julia_domath()?edit: reference to julia documentation
[0] http://docs.julialang.org/en/latest/manual/calling-c-and-for...
You can find recent binaries here: http://status.julialang.org/
You can also check the dev mailing list: https://groups.google.com/forum/?fromgroups#!forum/julia-dev
There are several aspects to this:
- Julia cannot generate linkable shared libraries, yet.
- There is a fairly small "libjulia" C API (the embedding reference in another comment), but this is a means to interact with/control the program "julia" (for dynamic interop. or IDE use, for example). "libjulia" does not export symbols for arbitrary Julia code.
- It is possible to generate a C-callable function pointer from a Julia function at runtime and to pass this into a C routine controlled by Julia (for example, to pass a comparator to a sorting routine, or an objective function to an optimizer).