Could somebody tell us, by a very rough guestimate, how many lines of code something like

I would guess that different different parts of the program are written in at least three different programming languages, probably including VB and C (or C++ or C#) and maybe assembly language too.  I'm only guessing though.
 

IIRC Sonar stays away from the .NET libraries in favor of direct C++ calls to Win SDK/API and internal libraries. There is some C++ code available through Cakewalk's website that has source code written (I believe) by Greg Hendershott. It outlines how controllers communicate with the host.
 
With regard to EXE size I'm not sure it matters...all things being equal. If you are calling on #include libraries in straight C your executable will be larger but your execution should be (somewhat) faster as there should be no linking at run time.
 
Anywho, back to making music.
 
Regards,

Linear Phase

sharke
Yeah the language used is everything - I wrote a small app in Python for my business, and sometime later rewrote it in C (just for the hell of it). The C version was easily 10 times longer.

 
Interesting..   Just out of curiosity, did you write in Python3 or Python2.xxx... latest version or some other version

It was Python 2.x. I remember back at the time the buzz was all about the upcoming 3.x standard, but the general feeling was that it wasn't worth learning it yet. So I have no specific idea about the differences....as far as I know there were some quite significant syntax changes. I would highly recommend Python to anyone wanting to write anything that doesn't involve heavy processing (i.e. audio, graphics etc). It's one of the easiest and most intuitive languages to learn, and you can get something up and running insanely fast. And if you're looking to build a GUI there is a Python wrapper of wxWidgets, called wxPython.

Linear Phase

konradh
Many developers find it faster to solve issue by brute force than logic, and that makes sense if memory and storage are cheap. I still admire lean and elegant code, though.

 
That's a killer bit of wisdom right there..   So it is, that with proper algorithms the actual amount of tedious typing exponentially shrinks, while time spent with pen and yellow pad exponentially grow.
 
Cheers

Look at some of the video games written in the 80's. I remember playing absolutely huge 3D adventures complete with massive worlds and complex plots, all of which fit into 64K or less. Of course they were written in assembly language, but the coders back then (most of whom cut their teeth in their bedrooms) made sure not a single clock cycle was wasted. There are still coders like that around today - check out the 64K demo scene.  

I write a lot of VB stuff for automating Excel spreadsheets, and I reckon my largest project is roughly 10K lines of code

Had to share this as an example of what a determined coder can fit into a small space: this entire video is from a 4k executable. That's right, 4 kilobytes. 
 

Had to share this as an example of what a determined coder can fit into a small space: this entire video is from a 4k executable. That's right, 4 kilobytes. 
 

There isn't much of a correlation between executable size and lines of code. First of all, what do you count as a line of code? Does that include comments? A well-written program will be heavily commented, and some of those comments will have taken as long to write as the code they describe. Do you include third-party components? For many applications, 90-95% of the program will be external libraries written by somebody else. As noted above, different programming languages will require more or fewer lines of code to achieve the same end (a 1,000-line assembly routine might be functionally duplicated in a single line of VB code, for example).
 
Secondly, there isn't much direct correlation between lines of code and development time, which would be more important to you. It used to be that a good programmer could produce 10 lines of commented and debugged code per day. I know there are days when I don't achieve that. Other days, if the requirements are well-understood and don't cover new ground, I can churn out a couple thousand lines of tested code in a day. Also note that two programmers don't produce twice as much code as one. Application development doesn't always lend itself to parallel divisions of labor.
 
My main application that I sell for a living has been in development since 1993, with the first installation in 1996 (about as long as Pro Audio / SONAR). The executable is 12MB in size, about the same size as SONARPDR.exe. The source code consists of nearly 600 modules and well over a million lines of code (I haven't actually counted them in a while) that I actually wrote myself (as opposed to third-party modules). That works out to about 130 lines of code per day, and believe me those 20 years have included some very long days! And this is just the main application, not counting ancillary utilities.
 
I'd suggest adopting the highest-level programming language that serves the purpose. If that's Python, then go for it - although Python will run out of steam pretty quickly for complex applications. Divide the code into time-critical and non-time-critical sections. The non-time-critical parts can be written in a higher-level language to cut down on development time. Save your C++ and assembly time for those bits that must be highly efficient. Of course, if you're writing a VST plugin, that means 99% of it. 

@DMBaer: Ha ha. We always joke that no documentation is needed. If you can read code, you can always know what it does, so what's the problem? Giggle. And the depth of understanding involved is usually huge from surface to seabed. Anyway, keeping documentation is PIA and it's almost always out of date. Look at Sonar's help file. LOL.
 
Sometimes I think it would be an improvement to make that helpfile updateable ... or at least where we could suggest improvements that they could accept or reject.
 

sharke
Had to share this as an example of what a determined coder can fit into a small space: this entire video is from a 4k executable. That's right, 4 kilobytes. 
 

 
as someone who has worked on demos in the past 8 bit wise, YES the compressed code is 4k.. but you'll find the uncompressed code for it is far bigger. It is generating more code / tables etc at runtime , or by using the GPU for processing etc.  data structures and recursion algorithms do come into it to compress the code / gfx. pretty much like a coiled spring. Even with sound, some of the players they use for audio , the actual instruments that are generated aren't many bytes.
 
much like the game "elite" on 8 and 16 bits had a massive universe... all in 32k of mem.. it was all down to the formula's that would generate far more data on the fly. http://www.youtube.com/watch?v=Rapa3VfUWfs
 
16:45 minutes in
 
 
 
 

dmbaer

bitflipper
A well-written program will be heavily commented, and some of those comments will have taken as long to write as the code they describe.

OK, can't resist jumping in here.  When I've taught programming, I always try to convey the notion that the best documentation is that which isn't there because it isn't needed in the first place.  You can get that with well thought out class, function and variable names.
 

Let's hear it for DoStuff(), Process(), and Calc()!

Changing subjects to an aspect that hasn't been mentioned yet, the issue of amount of code needed for a given function can be much dependent on how well the coders/designers understand and apply object oriented software practice.  For my money, this is the most significant software advancement that's happened during my 45 year career as a software developer.  You can't tell from the outside whether a piece of software uses OO internally (other than it will probably have fewer bugs), but it can make a world of difference in how fast the software gets written and tested.  And when properly utilized, it can significantly cut down on source code length.

That's of course the key - proper utilization of OO techniques.  Having an OO language is not going to help if the classes are tightly coupled, if you let your class hierarchy get out of control, etc.