learning programming. the best path?

[dmbaer]

First, I would suggest you avoid Python. It does way too much high-level stuff that you might get the wrong idea about what a computer language routinely can do. I would second the suggestion of Plug'n Script from the standpoint that you can get early gratification of creating software that does something meaningful to audio.

But any number of languages (other than C++) would be an excellent place to start. Java would be good, as would C# (free IDE and all on both of those), and both are sufficiently C++ like in syntax that the transition, when it's time, would not be painful.

I think most languages are a bit like swimming pools in that there's a shallow end that's great for newbies and a deep end for the serious stuff. But C++ is like a swimming pool four times the size of the others ... and there's no shallow end ... oh yeah, and there's spent nuclear reactor rods resting on the bottom.

Java, C# or other possibilities are far more newbie-friendly. Also, pick some good early projects. Write a program that can display a file in hex (just output the hex values but don't try a fancy GUI at that point). Then write a program that converts Roman numerals to integers (and flags invalid ones). Once you feel your ready, write a sudoku solver, and make it class-based as possible. At some point you'll need to confront writing for GUI display, but skip that early on or you may be overwhelmed with too many challenges.

[mystran]

Attention: the OP just bumped the thread to post that they already got started (and with C++ no less).

For what it's worth, I've written code in some 10-20 languages (including some that I designed myself) and in my humble opinion it is mostly irrelevant which language you start with. The hard part is learning to think like a programmer and this part is largely the same whether you're writing Befunge or Haskell.

[syntonica]

... you're writing Befunge or Haskell.

Same thing! Yeah, I replied to an earlier post before I got to the very end. That'll learn me!

Once upon a time, you'd just recommend BASIC for newbies (since that was all there was for PCs) but these days, with all the languages available, it's hard to recommend something that:

a. Teaches proper code organisational techniques, i.e. spaghetti-avoidance.
b. Teaches the most common and useful coding techniques.
without ghettoizing the poor student into some specific paradigm they might get locked into, thinking that's how programming is supposed to work.

I'd almost go with Rust, Swift, and other newcomers since most of the C-family (C++17+, Java 7+, Object Pascal*, Obj-C, etc.) is getting old and crufty with tons of extra verbosity (i.e. unreadable gibberish) trying to tack on what the aforementioned has already built in.

* Close enough.

[parricide]

thanks for the advice everybody. even the posters that didnt realise i was past the OP, still solid advice that is useful to me and others reading this in the future.
i am already seeing how important proper structuring of code is. my last project was about 1000 lines of code and it was very messy, with functions all over the place and it was a nightmare to debug! tidy coding is something i am now prioritizing on learning.

thanks for the help everyone

[mystran]

i am already seeing how important proper structuring of code is. my last project was about 1000 lines of code and it was very messy, with functions all over the place and it was a nightmare to debug! tidy coding is something i am now prioritizing on learning.

The funny thing about programming is that it's actually really hard to "properly structure" your code when you write it, because more often than not you don't really know exactly what it's going to look like before you've written it. You get a little better with experience, but at the same time your projects tend to get bigger, so it tends to be somewhat of a net-zero effect. Even if you try to be very methodological about it, you'll usually end up with a mess sooner or later. Sometimes people try to throw away their messy code and start over from scratch with the goal of ending up with a better structure, but usually that doesn't quite work either.

The cure is to learn to clean up the mess. It's usually called "refractoring" but there's nothing really fancy about it. You just take the bits and pieces of code and rearrange them into a better structure. Sometimes it's easy, sometimes it takes more effort, but it is almost always worth it and like any type of cleaning, it's usually easier if you do it often.

[syntonica]

It's best if you design from a top-down approach. You start with your main loop and think, What does this thing need to do?
E.g.
Main->
... Load
... Save
... Calculate
... Print
etc. And then you look at each one of those and think how to break them down furtherand so on. With experience, when you get to the bottom, the classes, methods, procedures and data structures you will need should start becoming obvious to you.

Honestly, before I even open up my IDE, I've got most of this planned out with a spiral notebook and a pen. I'm most comfortable writing by hand, but you can use Notepad or whatever on your computer, whichever makes your brain work the best. In the end, you'll get less spaghetti code than if you just winged it and refactoring will come easier.

[mystran]

It's best if you design from a top-down approach.

Oh come on. There is literally decades of heated and entirely useless debate on what the "best" design methodology would be and the cold reality is that (1) it depends on the project, (2) most projects benefit from different methods for different parts, (3) different people benefit from different methods and (4) at the end of the day none of it really works that well anyway, unless you're writing very similar things over and over again and already know what you need before you start.

[DJ Warmonger]

^That being said, it's good to have some design in mind before getting down to coding. If you begin with a blank page and just start piling up random features as they come to your mind, surely you won't get anywhere.

Life tip: A simple Kanban board can be very helpful, not only for software design but planning all your activities

[mystran]

^That being said, it's good to have some design in mind before getting down to coding.

Oh, certainly. I'm not against design, I'm just against simplistic notions of a single "best" approach.

edit: Personally I often find it helpful to start from data representations, because these tend to be the trickiest to change later. For example, in a text-editor you really need some solid representation of text buffers. Everything else builds on top of that. Once you have something like a piecetable that directly supports undo, everything else is relatively simple. On the other hand, if you try to first implement a basic editor by directly modifying some strings and then later want to add a feature like undo, you're probably going to have to rewrite large portions of your codebase.

[telecode]

FWIW, if you have never programmed, and know nothing about OOP, I think you are better off learning on something like Python and then work your way towards something like C++ (or whatever DSP programmers use).

But what do I know, I am more of a scripter. I just work on the 3 P's. Python, perl and PHP.

[klaatugort]

well, what kind of job do you wanna get? because programming is easy to excel at, once you learn the basics. can you do the basics do you think? because then you can get a job, get a raise and a better job. now you're working on code, that if you were fired, another rival company could 'head hunt' you, and get bits and pieces of that code from your memory. which is why programmers are routinely murdered by their boss. who get away with it scot-free, because trade secrets are a deadly business. in fact, why don't u come program for me, because u know, i wanna learn what ppl taste like.

[parricide]

The funny thing about programming is that it's actually really hard to "properly structure" your code when you write it, because more often than not you don't really know exactly what it's going to look like before you've written it. You get a little better with experience, but at the same time your projects tend to get bigger, so it tends to be somewhat of a net-zero effect. Even if you try to be very methodological about it, you'll usually end up with a mess sooner or later. Sometimes people try to throw away their messy code and start over from scratch with the goal of ending up with a better structure, but usually that doesn't quite work either.

The cure is to learn to clean up the mess. It's usually called "refractoring" but there's nothing really fancy about it. You just take the bits and pieces of code and rearrange them into a better structure. Sometimes it's easy, sometimes it takes more effort, but it is almost always worth it and like any type of cleaning, it's usually easier if you do it often.

haha its funny you say that. my latest project was a game i already started making, but decided to start from scratch because it got too messy
i even ended up giving up on the second version (although i got much further) because it got too messy and hard to work with (that and i was wasting time on it when i should be learning things i dont know).

i was not giving things their own files and headers and all my functions were lazily placed in a specific order that worked by chance, and if it didnt work i would just reorder it instead of clean things up because i was too keen to play with new ideas

i have learnt from my experience though, from now on i will build a section and then tidy it before moving on.

[parricide]

It's best if you design from a top-down approach. You start with your main loop and think, What does this thing need to do?
E.g.
Main->
... Load
... Save
... Calculate
... Print
etc. And then you look at each one of those and think how to break them down furtherand so on. With experience, when you get to the bottom, the classes, methods, procedures and data structures you will need should start becoming obvious to you.

Honestly, before I even open up my IDE, I've got most of this planned out with a spiral notebook and a pen. I'm most comfortable writing by hand, but you can use Notepad or whatever on your computer, whichever makes your brain work the best. In the end, you'll get less spaghetti code than if you just winged it and refactoring will come easier.

i cant comment on the best practices, but the tutorials i have been following stress planning what you want to do before you even open your IDE, so i did, and it worked really well. i have slightly adapted now though and i use comments in my IDE to describe what i want to do quickly, and as you say, break those tasks down to smaller tasks, before even starting to write the code.
it also helps me remember to not give a function too many tasks!

[syntonica]

It's best if you design from a top-down approach.

Oh come on. There is literally decades of heated and entirely useless debate on what the "best" design methodology would be and the cold reality is that (1) it depends on the project, (2) most projects benefit from different methods for different parts, (3) different people benefit from different methods and (4) at the end of the day none of it really works that well anyway, unless you're writing very similar things over and over again and already know what you need before you start.

It's what has always worked for me, therefore it's the "best"!

For a beginning programmer, I believe it to be the best as it will get them to think about program organization in the easiest, most logical way. Experienced programmers can and will start breaking the "rules" and do some bottom up in data design to meet in the middle. If your program is based around an algorithm, that may be the first thing you write, but that doesn't preclude the example I've given for top-down.

I'm certainly not advocating chucking everything and learning to program in ABC.

[mystran]

i cant comment on the best practices, but the tutorials i have been following stress planning what you want to do before you even open your IDE, so i did, and it worked really well. i have slightly adapted now though and i use comments in my IDE to describe what i want to do quickly, and as you say, break those tasks down to smaller tasks, before even starting to write the code.
it also helps me remember to not give a function too many tasks!

Some editors/IDEs can actually pull TODO items from comments into a list: https://www.dotnetperls.com/todo

Another "comment tag" that sometimes gets special treatment is FIXME (ie. "this code works, but it's ugly and/or has limitations that need to be fixed later").