Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Managing Parallel Development in Two Languages? 108

Abhaga asks: "I work for a technology startup and our research work is mostly done in Matlab. The technology has matured, and now we are looking to build prototypes and products in C++. However, the dilemma is about the further research work/enhancements to the system. Should they be done in Matlab and continuously ported to C++, or is it better to move to C++ once and for all, at this point of time? Anyone having experience with similar things, what should we keep in mind while deciding on one or other."
This discussion has been archived. No new comments can be posted.

Managing Parallel Development in Two Languages?

Comments Filter:
  • by antifoidulus ( 807088 ) on Saturday July 22, 2006 @08:25AM (#15762580) Homepage Journal
    Wow, talk about being penny wise and pound foolish. I know this isn't popular here on /., but if you are worried about the cost of matlab, then honestly your organization doesn't have a snowball's chance in hell.
    If you can save time by using Matlab, even in your very unlikely scenario, the extra cost of the software is still dwarfed by the cost of programmers time as well as the potential losses of being 2nd to market. Unless the software is prohibitively expensive(which Matlab isn't), you need to go with what can get the job done the fastest with the fewest errors.
  • by jellomizer ( 103300 ) * on Saturday July 22, 2006 @08:28AM (#15762588)
    Mixing two languages together will cause problems, Technical/Buisness/Political.

    Political: Undoubtedly you will get some changes and fixes that are really easy in one language and a real pain for an other one. So say it takes 5 Minutes in MatLab and could take a week in C++or Vice Versa. Most people don't get this fact especially non professional programmers. So one side group will get a fast change and the other will get the slow change. Thus makes the other group feel like their side isn't as well supported thus making you look really bad.

    Business: Maintaining the application will always require people with skill sets in both. Matlab is a rather uncommon skill set while as of right now C++is fairly common. But finding people willing to do both is much harder. As time goes on and as one language leaves common use finding people with these skill sets combined will be very hard and expensive to keep.

    Technical: Reported bugs will be need to check on both systems and bug will appear in one system and not the other. But when a bug is reported you will need to check on both systems. And sometime you can easily fix on system and the other requires a major rework. Getting performance on one system to be equivalent to the other will be difficult.

    I think you are about to enter a quagmire which you will not come out looking good in. If you do succeed you will probably get a neutral reaction to you work. So it is a Loose/Tie situation. I would spend more time descussing other options. Going one way or the other. Not 2 products that do the same thing but differently.
  • by mangu ( 126918 ) on Saturday July 22, 2006 @08:50AM (#15762629)
    I have done what you said, writing prototypes in Matlab first and porting it later to C++, and it hasn't worked too well. I have found that the two languages are too different, there are always new bugs appearing in the ported code. In my experience, the time spent in developing the math is less than the time spent in the user interface anyway, so I don't see too much problem in developing the math in C++, if you choose a good set of libraries.


    However, having said that, I must say that I *do* write small prototypes first, only I do it in C rather than other languages. I also use plenty of small scripts, mostly in Perl, to perform auxiliary operations. But the main code that constitutes the algorithms used in the program should be prototyped as close to the end code as possible. There is no way you could develop an algorithm in Matlab or Python or Ruby and consider its testing a validation for a deliverable program written in C++.

  • by jellomizer ( 103300 ) * on Saturday July 22, 2006 @09:01AM (#15762647)
    Remember US Programmers are payed between 15-150 an hour say MatLab licenses cost $10,000 and Major Upgrades every 2 year.
    So that is $5,000 a Year of software cost. Now the programmer will work a 35 hour work week. Now the Cheap Programmer year cost is $26,250 a year and the expensive programmer $262,500 a year. So programmers are more expensive then licenses. So if this tool can make a programmer twice as productive then it is worth the license. So unless the programmer is getting like $3.00 an hour which is less then most outsourcing. The costs to do it in C++ vs. Paying for a license is worth it.
  • Re:Ruby is worse (Score:3, Interesting)

    by jlarocco ( 851450 ) on Saturday July 22, 2006 @12:50PM (#15763275) Homepage

    Give me a break. Nobody writes Ruby that way.

    Ruby is far from perfect, and it's not for everyone, but that can be said for any language. You could at least try to criticize it for its faults, not some guy who programs like a moron.

    OMFG!!!1 C is a bastardization. Only crazy zealots program in C, cause they're always doing stuff like this [ioccc.org] or this. [ioccc.org] You'd have to be a zealot to use C!

    See how stupid that looks?

  • Don't drop MATLAB (Score:4, Interesting)

    by vijayiyer ( 728590 ) on Saturday July 22, 2006 @12:59PM (#15763304)
    Your algorithm developers will curse you if you stop the use of MATLAB. I use it every day in a mostly Fortran/C shop, and I can get work done in a small fraction of the time it takes the fortran folks. In one case it took me 35 lines of code to do what would take hundreds of lines in fortran. If I need fast runtime, I port it after I've done the development. Writing it twice in this manner is still _far_ quicker than writing it in C or C++ the first time. Ignore the slashdotters who think MATLAB is bad because it's proprietary - I can assure you that they've never used it in a production environment, and don't understand that time == money.
  • by Latent Heat ( 558884 ) on Saturday July 22, 2006 @11:44PM (#15764888)
    What you really want for this project is Java. Really.

    Matlab is morphing into a Java scripting language. You know why the Matlab UI takes so long to load these days? Its written in Java, so it needs to load a Java VM when it launches with all of the attendant byte code checking of loaded classes.

    Did you know that you can launch Java apps from the Matlab command prompt? That you can also create object instances of individual Java classes and invoke function calls on them? That Matlab automatically manages conversions of array types between the Matlab environment and Java objects? That as of Matlab 7 that Matlab can host Java Swing widgets inside Figure Window GUI's in Matlab?

    Forget about C++ GUI's, Python, Ruby, all the stuff people are telling you. Develop your application-specific widgets in Java Swing. Host them in your Matlab GUI for now. When you are ready, release stand-alone Java Swing apps using those same Java widgets. Continue to support Matlab as a scripting environment for your stuff.

    Need to do some hard-core numerics in C++? The Java implementations may be fast enough. But if you really need C++, link into it from your Java widgets using JNI. You will need to compile your C++ modules for your different target platforms, but the compiled modules will have different names (YourModule.dll under Windows, libYourModule.so under Linux) so you can distribute all of the modules along with the Java class file that calls them and have cross-platform capability. The JNI takes some mastering, but it is no harder than what you do to write MEX files to call C/C++ directly from Matlab, and there are tons of documentation on the Web.

    The people telling you to do a C++ GUI don't know what they are talking about -- you are probably doing a Matlab GUI and may be calling down to C++ in MEX functions. There are C++ solutions -- Qt, wxWidgets, (gasp, choke) MFC/ATL/WTL -- but they will look quited unfamiliar to what you are doing right now. Do your GUI as Swing widgets and you will get Matlab interoperability, a path to ween yourself from Matlab, and a way to operate on all the platforms that have Matlab.

1 + 1 = 3, for large values of 1.

Working...