learning programming. the best path?

[Vokbuz]

Does anybody (yes and I'm looking at all of you who call yourself software engineers actually do any sort of formal (in the informal sense of the word) A & D?

A&D of what exactly? There is no silver bullet, each problem requires its own solution. Even goto's can be right and the most expressive solution sometimes.

[mystran]

Does anybody (yes and I'm looking at all of you who call yourself software engineers actually do any sort of formal (in the informal sense of the word) A & D?

A&D of what exactly? There is no silver bullet, each problem requires its own solution. Even goto's can be right and the most expressive solution sometimes.

http://dspace.mit.edu/bitstream/handle/ ... sequence=2

[Vokbuz]

http://dspace.mit.edu/bitstream/handle/ ... sequence=2

I didn't mean that goto is faster. Modern compilers are very good at reorganizing code. What I meant is that it can be the most expressive approach. For example, when writing final state machine or breaking outer loop from inner loop.

[earlevel]

I didn't mean that goto is faster. Modern compilers are very good at reorganizing code. What I meant is that it can be the most expressive approach. For example, when writing final state machine or breaking outer loop from inner loop.

At times I've wished for "comefrom".

[resynthesis]

All of this talk about languages. I'm yet to see anybody around here mention RS, analysis and design methods. Does anybody (yes and I'm looking at all of you who call yourself software engineers actually do any sort of formal (in the informal sense of the word) A & D? Or are VSTs too trivial for such things.

I hope I'm not derailing here.

choosing a language was my primary concern. i did mention near the start of the thread that i have many years of experience with audio physics and maths as well as DSP design etc and it was really just about choosing the right path to be able to use those skills along side a programming language to program audio toys.

however now i have chosen C++ and am moving forward along that path so am mostly looking for info about C++ and things like juce etc.
i am still keen to learn other related things though so would love to hear about the things you mention, could you tell me more about RS, A&D, etc please? i dont even know what they are.
thanks

Not trying to be daft about this (and I stayed well clear of the open source thread). The things I mentioned are the stages in software development that take place before any coding. Have a quick look at the software lifecycle and all may become clear. All I mean is that before developing any system with non-trivial complexity it's a good idea to know what you need/want to produce and have some idea of how you will structure your system. This does not have to be a heavy, formal or semi-formal method but it's just nice to know what you're doing and have some sort of documentation (especially if it's something you need to support for some time).

EDIT: Use of analysis and design tools can also make your programming task easier by generating some of the more trivial code and documentation for you.

[dmbaer]

All of this talk about languages. I'm yet to see anybody around here mention RS, analysis and design methods. Does anybody (yes and I'm looking at all of you who call yourself software engineers actually do any sort of formal (in the informal sense of the word) A & D? Or are VSTs too trivial for such things.

I wrote my first computer program in 1966 (it was in FORTRAN). For the next four and a half decades my main focus frequently involved ways in which to make programmers more effective and productive. During that time, the most significant development in this area that I encountered was OOP, with nothing being a close second, IMO. I was well into my career before OOP became commonplace, at least in the non-acedemic IT community.

I would say that if a programmer/software-engineer has a natural and fundamental grasp the proper use of OOP (and not one in ten do even today, I'd say), then the design takes care of itself. At least this is the case for modest sized initiatives. When a project grows to involve more than a few closely-working participants, that's another story, and formal methodologies become necessary to coordinate the diverse parts. But for a single programmer or a small team, if they can wield OOP to best advantage, they will already be thinking in a way that makes the need for some peripheral design approach largely unnecessary ... again, just IMO.

[parricide]

Not trying to be daft about this (and I stayed well clear of the open source thread). The things I mentioned are the stages in software development that take place before any coding. Have a quick look at the software lifecycle and all may become clear. All I mean is that before developing any system with non-trivial complexity it's a good idea to know what you need/want to produce and have some idea of how you will structure your system. This does not have to be a heavy, formal or semi-formal method but it's just nice to know what you're doing and have some sort of documentation (especially if it's something you need to support for some time).

EDIT: Use of analysis and design tools can also make your programming task easier by generating some of the more trivial code and documentation for you.

ah yes i see what you are saying. also thanks to @BertKoor for explaining.
that is actually one of the first things they taught in the tutorials i have been following, to spend more time planning what you do before you even get to the programming stage. i agree, it will cut down the programming time significantly.

what kind of tools do you mean though? what things are out there to help this stage?

thanks for the info

[parricide]

I wrote my first computer program in 1966 (it was in FORTRAN). For the next four and a half decades my main focus frequently involved ways in which to make programmers more effective and productive. During that time, the most significant development in this area that I encountered was OOP, with nothing being a close second, IMO. I was well into my career before OOP became commonplace, at least in the non-acedemic IT community.

I would say that if a programmer/software-engineer has a natural and fundamental grasp the proper use of OOP (and not one in ten do even today, I'd say), then the design takes care of itself. At least this is the case for modest sized initiatives. When a project grows to involve more than a few closely-working participants, that's another story, and formal methodologies become necessary to coordinate the diverse parts. But for a single programmer or a small team, if they can wield OOP to best advantage, they will already be thinking in a way that makes the need for some peripheral design approach largely unnecessary ... again, just IMO.

i am starting to really see the benefits of OOP. while i was following the tutorials i was obviously playing around in my IDE at the same time and started to get carried away in writing things before moving back to the tutorials.
the program was far too long and confusing for what it was and when i got back to the tutorials i started learning about OOP and realised how i could have saved myself so many lines of code and made things so much easier right off the bat
thats how i learn best though, i guess