Quote don't think matlab is very good for large-scale apps though. Its natural workflow is jotting down some lines, refining them on the fly, breaking it down into functions as it starts to become unmanageableIs this situation caused by 1) inherent limitations of the language 2) not using OO or 3) other reasons? 4) combination of 1-3?Of course - as you say - memory considerations do play a role.

Not using OO may be a part of it. Mainly I think Matlab encourages 'sloppy' coding: eg. assigning to a variable/array element/struct field that doesn't exist will create the variable/resize the array and pad it with zeros/add a field to the struct. Likewise, since you can eval arbitrary strings at any point, it's impossible to know in advance what variables will even exist at a given point in the code; etc, etc.This is exactly the behavior you want when playing around, and exactly _not_ the behavior you want for writing and debugging production code that is hard to break. I wouldn't say it's a limitation as such - just that any language encourages certain things and discourages others. eg Java encourages a reckless approach to memory allocation , C++ encourages you to think in terms of interfaces and to think ahead - so it's silly to use just one language for everything.

QuoteI wouldn't say it's a limitation as such - just that any language encourages certain things and discourages others. eg Java encourages a reckless approach to memory allocation , C++ encourages you to think in terms of interfaces and to think ahead - so it's silly to use just one language for everything. The question we should ask is: why do we use a language?From the posts one scenario seems to be to use Matlab for the prototyping (i.e. when we try to understand the problem) and then when we understand the problem or it becomes too big move on to C++.Another option is to do the prototyping in _no_frills C and concentrate on the data flow and algorithms. Then incorporate the reusable parts of the code into a _generic_ C++ design.QuoteI think Matlab encourages 'sloppy' coding: eg. assigning to a variable/array element/struct field that doesn't exist will create the variable/resize the array and pad it with zeros/add a field to the structWhen you get to the stage that it takes longer to fix a bug than it does to introduce a new feature, it's time to redesign. And just fixing silly bugs is not good for anyone's motivation

QuoteAnother option is to do the prototyping in _no_frills C and concentrate on the data flow and algorithms.Having to know exactly the size of each array at compile time? No runtime-extensible structs? Lousy string handling? No interactive debug (ie pause at a location in the code and execute arbitrary commands there)? No ability to browse, and plot, the contents of an array just by clicking on its name in the code?No thanks!

QuoteHaving to know exactly the size of each array at compile time? No runtime-extensible structs?pointers & malloc?QuoteNo interactive debug gdb?

QuoteOriginally posted by: ZmeiGorynychQuoteAnother option is to do the prototyping in _no_frills C and concentrate on the data flow and algorithms.Having to know exactly the size of each array at compile time? No runtime-extensible structs? Lousy string handling? No interactive debug (ie pause at a location in the code and execute arbitrary commands there)? No ability to browse, and plot, the contents of an array just by clicking on its name in the code?No thanks!I think you should should be using Haskell or Lisp and not Matlab in this case.For testing algorithms _basic_style_ C is fine.

QuoteOriginally posted by: zetaQuoteHaving to know exactly the size of each array at compile time? No runtime-extensible structs?pointers & malloc?QuoteNo interactive debug gdb?Well I knew you are a mashochist when you advocated gdb as the way to teach C++ to newbiesDoes gdb allow you, when you're stopped at a breakpoint, evaluate any expression that would be valid in that scope, if it were part of the source code?Why should I use C when any reasonably mature scripting language will give me the same functionality (arrays, if statements, and for loops, pretty much, no? ), and usually a much nicer syntax (except for perl, that is ) ?

QuoteWhy should I use C when any reasonably mature scripting language will give me the same functionality My C code can be directly used in my C++ framework. No rewrite as in Matlab case.BTW, do you use design patterns? Then the language becomes a non-issue, well almost One can use a language to discover requirements, but it is relatively expensive option.

QuoteWell I knew you are a mashochist when you advocated gdb as the way to teach C++ to newbies tis true. But you can do what you suggest in gdb AFAIK, a little like using 'keyboard' in matlab. I use the bt command a lot (backtrace) to look at stack framesQuoteWhy should I use C when any reasonably mature scripting language will give me the same functionality (arrays, if statements, and for loops, pretty much, no? ), and usually a much nicer syntaxMatlab is a blessing and a curse. Like I say, what takes 1000 lines in matlab is 10000 lines in C/C++. Take the imread function in matlab; I got a little spoilt with it and didn't realize the amount of work involved in making something for production. But at least Matlab allows you to focus on the *algorithm* which is generally where the novelty/research is.

QuoteWell I knew you are a mashochist when you advocated gdb as the way to teach C++ to newbiesDoes gdb allow you, when you're stopped at a breakpoint, evaluate any expression that would be valid in that scope, if it were part of the source code?huh?gdb is for debugging C++, not learning/teaching it?

QuoteOriginally posted by: ZmeiGorynychQuoteAnother option is to do the prototyping in _no_frills C and concentrate on the data flow and algorithms.Having to know exactly the size of each array at compile time? No runtime-extensible structs? Lousy string handling? No interactive debug (ie pause at a location in the code and execute arbitrary commands there)? No ability to browse, and plot, the contents of an array just by clicking on its name in the code?No thanks!You sound like Common Lisp would be ideal language for you. And you will have added benefits of, say, compiling the program only when you think you are done developing or being able to modify it without stopping it (just consider applying emergency patch to production system or debugging problems in a client's live system remotely)

Hmm, interesting. Care to give links to a download and a getting-started? Or should I just google?

QuoteOriginally posted by: ZmeiGorynychHmm, interesting. Care to give links to a download and a getting-started? Or should I just google?You mean Lisp? Here is some motivational reading, tons of tutorials and commercial IDE with dynamic debugger etc although I used to do all the development/debugging using (X)Emacs as IDE.

Cool, thanx!

QuoteOriginally posted by: CuchulainnQuote don't think matlab is very good for large-scale apps though. Its natural workflow is jotting down some lines, refining them on the fly, breaking it down into functions as it starts to become unmanageableIs this situation caused by 1) inherent limitations of the language 2) not using OO or 3) other reasons? 4) combination of 1-3?Of course - as you say - memory considerations do play a role.1. Inherent limitation.The main problem with Matlab as a language is its lack of pointers, references, or handles to objects. Basically, it is modeled on Fortran 77, not on C. Matlab also lacks heap, but with dynamic global memory, and few other facilities like an access to the top scope it is possible to work around. The lack of pointers makes hard writing big asynchronous programs. Asynchronous in practice means event processing - including GUI and interactive graphics. Processing of events, as a rule, involves modification of internal data. How to find the modified data without pointers? With smaller programs we can make the data global, but with bigger programs it is not a good solution. At this point most of people abandon Matlab and port codes to C, C++, Fortran or other languages.2. Not using OO in Matlab:- Chicken and egg problem. People do not use OO because nobody uses it. - High barriers to entry to OO:-- Practically no real-life codes to learn from. I do not know a single MathWorks "toolbox" that uses OO. -- Poor documentation. The descriptions and examples of OOP in the documentation are boring and labor intensive: most of them are just long switches with template snippets of codes for each variable. Generic programming saves the Matlab OO, but it is not described at all in Matlab documentation. My impression is that MathWorks does not know that the generics is possible.-- Confusion between three kind of OOP in Matlab: Graphic objects, Java classes (yes, Matlab is open to Java classes), and Matlab classes proper. Personally, I spent three months on learning Matlab OOP, about 1.5 to 2 of them in futile attempts to learn how to inherit Matlab objects from Matlab graphic objects (there was some vague wording in documentation that it is possible, but it is impossible).3. Other reasons:Matlab is positioned as a prototyping tool, and few people ever consider it for production. However, in its current form, I would say after version 6 or 6.5, it can be used in production. I was forced to write in Matlab an interactive graphics / computational geometry / signal processing program, consisting of about 385-390 files / functions. It was fast enough (soft real time) and my users did not complain for crashes for months. I would prefer to code it in C++, but it proved to be possible in Matlab.