Learning to compose and understand music notation is analogous to learning programming. The strange thing is, music is usually in my head (and sometimes I make it a point to listen to music) while in the 'groove' of programming. I have zero musical talent but the basic system of musical notation was easy to learn.

https://www.infragistics.com/commun...sts/is-programming-similar-to-composing-music

Off topic
Music is all about math and physics.
For example, the notes in western music are separated by the 12th root of 2, or 1.05946309436

This, in fact, does not make for the best sounding harmony. Hence we prefer to round things to the next closest integer fractions.
For example, in the scale of the key of A, the note D is 4/3 the frequency of A. E is 3/2 that of A. This is called a Perfect Fifth.

Note	Standard interval name(s) relating to A 440	Frequency (Hz)	Multiplier	Coefficient (to six places)	Just intonation ratio
A	Unison	440.00	20⁄12	1.000000	1
A♯/B♭	Minor second/Half step/Semitone	466.16	21⁄12	1.059463	≈ 16⁄15
B	Major second/Full step/Whole tone	493.88	22⁄12	1.122462	≈ 9⁄8
C	Minor third	523.25	23⁄12	1.189207	≈ 6⁄5
C♯/D♭	Major third	554.37	24⁄12	1.259921	≈ 5⁄4
D	Perfect fourth	587.33	25⁄12	1.334839	≈ 4⁄3
D♯/E♭	Augmented fourth/Diminished fifth/Tritone	622.25	26⁄12	1.414213	≈ 7⁄5
E	Perfect fifth	659.26	27⁄12	1.498307	≈ 3⁄2
F	Minor sixth	698.46	28⁄12	1.587401	≈ 8⁄5
F♯/G♭	Major sixth	739.99	29⁄12	1.681792	≈ 5⁄3
G	Minor seventh	783.99	210⁄12	1.781797	≈ 16⁄9
G♯/A♭	Major seventh	830.61	211⁄12	1.887748	≈ 15⁄8
A	Octave	880.00	212⁄12	2.000000	2

Reference: https://en.wikipedia.org/wiki/Twelfth_root_of_two

 

I think doing mathematical proofs is quite analogous.

I’d agree it is analogous to part of the entire enterprise of computer programming, but the realization of algorithms using a physical Von Neumann Machine adds a very large part that has no mathematics analogy.

 

There is no real analogy to computer programming that isn’t some other computer programming.

I don't think I agree with this, but part of it depends on the degree to which we make the distinction between what is "computer programming" and what is "solving a problem using a computer program".

When designing a mechanical system or an electrical circuit or putting together a financial plan or preparing a tax return, or an educational study plan, or developing a computer program, the approach I take for all of them is very similar. I break the problem down into small enough chunks that I either know how to solve the individual pieces, or have confidence that I understand the small chunks well enough to be able to go learn what I need in order to solve that chunk. Then I put all the pieces together, a bit at a time, performing whatever checks I can devise to test whether things are working properly.

 

Having a strong interest and solid background in mathematics is an advantage. Solving problems in arithmetic, algebra and geometry gives one a head start in mastering computer programming.

Do you enjoy solving puzzles such as Sudoku and Wordle?

I've never had much interest in solving puzzles for the sake of solving puzzles and never had much interest in mathematics other than as a tool to solve the problem at hand. Yes, you need the background for formal programming instruction and for specific types of scientific coding but it's not the kernel of where programming originates in the mind IMO.

 

I was an electronic measurements specialist, My job was to design and build automatic test systems for manufacturing customers. Their products were very diverse. I had to use a very analytical approach to find the simplest ways to make the measurements they required. When including a software solution, I used exactly the same analytical approach to break down the requirements into their smallest logical pieces.
Programming is just problem solving.

 

As a physics major in college I had to take a philosophy course. I (wisely) chose logic. My background in math and physics made it the easiest course I ever took. Not so for the rest of the class, most found it quite puzzling.

For extra credit on a homework assignment, the prof gave us a long, complicated boolean expression to do a truth table for. I handed in the teletype output (on the standard yellow roll paper) of a program I wrote to compute it.

 

As a physics major in college I had to take a philosophy course. I (wisely) chose logic. My background in math and physics made it the easiest course I ever took. Not so for the rest of the class, most found it quite puzzling.

For extra credit on a homework assignment, the prof gave us a long, complicated boolean expression to do a truth table for. I handed in the teletype output (on the standard yellow roll paper) of a program I wrote to compute it.

Off topic
I had a strong background in physics and a developing interest in philosophy. Unfortunately I did not do so well in my undergraduate philosophy course because of my poor reading and comprehension skills.

If they had introduced philosophy based on a book such as The Story of Philosophy by Bryan Magee I would have found it much more enjoyable.

 

I don't think I agree with this, but part of it depends on the degree to which we make the distinction between what is "computer programming" and what is "solving a problem using a computer program".

When designing a mechanical system or an electrical circuit or putting together a financial plan or preparing a tax return, or an educational study plan, or developing a computer program, the approach I take for all of them is very similar. I break the problem down into small enough chunks that I either know how to solve the individual pieces, or have confidence that I understand the small chunks well enough to be able to go learn what I need in order to solve that chunk. Then I put all the pieces together, a bit at a time, performing whatever checks I can devise to test whether things are working properly.

There is no doubt that a generalized skill in systematic problem solving will assist a great deal in learning to program computers. My statement is only intended to reflect the unusual nature of the actual activities of computer programming, that is, its constraints and specific tools used to solve a problem using a computer and programming language as tools.

 

I'd like to mention functional programming at this point. This is an oft neglected area yet is hugely important today when it comes to developing computer/data problem solving skills.

Studying imperative languages exclusively is a bad idea because it compels us to visualize problems and solution only one way when there might be a much better/simpler way.

Functional languages - to varying degrees - generally do not have or allow us to avoid:

1. Loops
2. Variables
3. If statements
4. Side effects

Developing an awareness of how to solve problems without these features and why avoiding them is helpful, can only improve one's mental repertoire of skill. So in addition to Boolean algebra and Turing machines, take some time to look at Lambda calculus.

 

Coding is a lot of work but programming or what is sometimes called "software engineering" is a different matter. Coding it little more than interpreting an algorithm so that it can be executed by the computing engine (compiler, assembler, interpreter).

Programming is what takes a wide range of specialized knowledge. That usually requires in-depth knowledge of the system being used and the problem being solved. Coders are important but they take their direction from software architect if the orgainzation is large enough to support one. In smaller companies it is a one man operation and those guys are amazing.

Coding: An almost mechanized job.
Programming: Requires extensive knowledge of the system and the problem to be solved.

 

Coding is a lot of work but programming or what is sometimes called "software engineering" is a different matter. Coding it little more than interpreting an algorithm so that it can be executed by the computing engine (compiler, assembler, interpreter).

Programming is what takes a wide range of specialized knowledge. That usually requires in-depth knowledge of the system being used and the problem being solved. Coders are important but they take their direction from software architect if the orgainzation is large enough to support one. In smaller companies it is a one man operation and those guys are amazing.

Coding: An almost mechanized job.
Programming: Requires extensive knowledge of the system and the problem to be solved.

This is how I began to write code professionally back in 1981:



For a couple of years before that I coded bare metal microprocessors like this:



and



and



and



The contrast between these weak yet "personal" and very accessible machines and the huge mainframe, with air tight rooms, teams of operators, room full of "punch girls" and tape drives and offsite storage backup was incredible.

 

I'd like to mention functional programming at this point. This is an oft neglected area yet is hugely important today when it comes to developing computer/data problem solving skills.

Studying imperative languages exclusively is a bad idea because it compels us to visualize problems and solution only one way when there might be a much better/simpler way.

Functional languages - to varying degrees - generally do not have or allow us to avoid:

1. Loops
2. Variables
3. If statements
4. Side effects

Developing an awareness of how to solve problems without these features and why avoiding them is helpful, can only improve one's mental repertoire of skill. So in addition to Boolean algebra and Turing machines, take some time to look at Lambda calculus.

Yes, it has a place but has limited usability in many domains like were you have I/O with state and were recursion is forbidden due to resources like on most controllers that are built to be efficient, stately, imperative operation devices that normally programmed with lower abstraction for very good reasons.
https://forum.allaboutcircuits.com/threads/why-do-we-use-recursive-function.145874/post-1240875

 

Yes, it has a place but has limited usability in many domains like were you have I/O with state and were recursion is forbidden due to resources like on most controllers that are built to be efficient, stately, imperative operation devices that normally programmed with lower abstraction.
https://forum.allaboutcircuits.com/threads/why-do-we-use-recursive-function.145874/post-1240875

This is true, what I'm talking about though is exposure to these languages not necessarily for work on these resource constrained device but as an alternative problem solving discipline. Recursion can always be done using tail recursion (with continuation passing) which has no costly stack costs.

IO is a whole beast itself of course, but the way these are managed is instructive even if not applicable to low level MCU hardware, the way that Haskell for example represents IO is alien to any imperative developer.

 

View attachment 273378


The contrast between these weak yet "personal" and very accessible machines and the huge mainframe, with air tight rooms, teams of operators, room full of "punch girls" and tape drives and offsite storage backup was incredible.

I started out with machine code, but eventually saved my pennies and was able to buy an AIM65. With it, I wrote my first commercial program for one of those 28 pin 6500 chips. The programming of the EPROMs was done on the AIM65 using a FORTH program with a huge and very expensive (about $500) 16K of RAM added (which I can now buy for about U.S. $1) What glorious days those were, my employer already bought a TRS-80 for another project, leaving nothing so I self-funded the computer.

My second commercial product was written in 6805 assembly running a macro assembler written in Fig Forth under CP/m 2.2.

In my opinion, that was much better that the bloated integrated development environments of today.

 

I started out with machine code, but eventually saved my pennies and was able to buy an AIM65. With it, I wrote my first commercial program for one of those 28 pin 6500 chips. The programming of the EPROMs was done on the AIM65 using a FORTH program with a huge and very expensive (about $500) 16K of RAM added (which I can now buy for about U.S. $1) What glorious days those were, my employer already bought a TRS-80 for another, leaving nothing so I self-funded the computer.

My second commercial product was written in 6805 assembly running a macro assembler written in Fig Forth under CP/m 2.2.

In my opinion, that was much better that the bloated integrated development environments of today.

I still occasional use FORTH on a production machine. It has a processor designed to run FORTH automation control programs.
https://forum.allaboutcircuits.com/...ms-that-are-still-running.132038/post-1092256

 

I started out with machine code, but eventually saved my pennies and was able to buy an AIM65. With it, I wrote my first commercial program for one of those 28 pin 6500 chips. The programming of the EPROMs was done on the AIM65 using a FORTH program with a huge and very expensive (about $500) 16K of RAM added (which I can now buy for about U.S. $1) What glorious days those were, my employer already bought a TRS-80 for another project, leaving nothing so I self-funded the computer.

My second commercial product was written in 6805 assembly running a macro assembler written in Fig Forth under CP/m 2.2.

In my opinion, that was much better that the bloated integrated development environments of today.

I'm definitely of a mixed-mind in this regard. While I strongly believe that a lot is lost when people only learn how to use the IDEs available today and that there is a LOT of fundamental knowledge and skills to be had from working close to the hardware in assembly or C, only being able to work at that level is also extremely limiting. The very scale of the resources we have available today allow us to tackle problems that are at such a scale that we just can't do so if we are limited to working so close to the hardware, no matter how well we might end up understanding it.

So both have their place and someone that can work at both levels (or, more accurately, all along the entire spectrum of available levels of abstraction) is in the best position to get the best out of whatever level they choose to work at for a particular task.

Where I see the problem is that most students aren't really even given the opportunity, let alone the expectation, to be able to work meaningfully at the lower levels. Instead, they just become code monkeys only able to do what the IDE they've been trained on can do. Fortunately, there will always be some that are either lucky enough to be forced to work at the lower levels, or that just develop the desire to be able to do so. But most resist doing so kicking and screaming as being a waste of time.

 

Programming is no different than writing a detailed standard operating procedure. Ive written thousands of lines of instructions that allowed us to replace a pair long time employees who thought they were irreplaceable because of all of their "knowledge". Their threats was actually just a minor inconvenience. Their knowledge was simply my knowledge that they memorized. Once I wrote it down and taught someone the notation, anyone could do the job of the annoying employees and shutdown was averted. Even the union was pissed at these two members for threatening to shut down the plant and putting everyone out of work.

 

Besides a brief introduction to computer programming with MINI, my computer foundations were built on Fortran and BASIC.

Then I discovered procedural languages such as ALGOL and Pascal and Structured Programming. That opened a totally new chapter on what is proper programming IMHO.

 

I started out with machine code, but eventually saved my pennies and was able to buy an AIM65. With it, I wrote my first commercial program for one of those 28 pin 6500 chips. The programming of the EPROMs was done on the AIM65 using a FORTH program with a huge and very expensive (about $500) 16K of RAM added (which I can now buy for about U.S. $1) What glorious days those were, my employer already bought a TRS-80 for another project, leaving nothing so I self-funded the computer.

My second commercial product was written in 6805 assembly running a macro assembler written in Fig Forth under CP/m 2.2.

In my opinion, that was much better that the bloated integrated development environments of today.

I loved the AIM65, I only ever saw them and used them at electronics college, but when I joined the college I'd already been programing the 6502 in that Acorn System 1 computer, both of course, used 6502.

AIM65 was cool, decent keyboard, nice display and a printer! I badly wanted a SHARP MZ 80B but it never happened.

 

I'm definitely of a mixed-mind in this regard. While I strongly believe that a lot is lost when people only learn how to use the IDEs available today and that there is a LOT of fundamental knowledge and skills to be had from working close to the hardware in assembly or C, only being able to work at that level is also extremely limiting. The very scale of the resources we have available today allow us to tackle problems that are at such a scale that we just can't do so if we are limited to working so close to the hardware, no matter how well we might end up understanding it.

So both have their place and someone that can work at both levels (or, more accurately, all along the entire spectrum of available levels of abstraction) is in the best position to get the best out of whatever level they choose to work at for a particular task.

Where I see the problem is that most students aren't really even given the opportunity, let alone the expectation, to be able to work meaningfully at the lower levels. Instead, they just become code monkeys only able to do what the IDE they've been trained on can do. Fortunately, there will always be some that are either lucky enough to be forced to work at the lower levels, or that just develop the desire to be able to do so. But most resist doing so kicking and screaming as being a waste of time.

I think I agree overall. As you'll know, back then (70s) almost all home computing was done by electronics enthusiasts/hobbyists. So these people already knew what a resistor or capacitor was, we'd built real stuff from discrete components. For many of us it was a small step to go from the 7400 series projects to a basic 6502 or Z80 computer and building the kits was a breeze for us.

You needed to understand (at least to some level) digital electronics in order to get an idea of what these MCUs were all about. Well in the mid late 70s hobby electronics magazines had already started covering TTL and CMOS projects, so again hobbyists were very well positioned to jump onto all this.

When I got my first real programming job on IBM mainframes, I was amazed at the powerful languages, color monitors and so on yet older people were impressed when I could explain boolean logic, something programmers then hardly ever used in their work but was second nature to me.

It was a good time, today most young people do not begin with hardware, they begin sitting at a PC playing with already quite sophisticated software and hardware, the gulf is huge and I suspect harder to bridge than it was for me.

I have a decent collection of back issues of BYTE magazine and a small collection of limited edition signed prints by Robert Tinney, brings back all the atmosphere when I look at this stuff! Tinney had a wonderful imagination and his cover art really captured the times, exciting, anything possible, futuristic promise:

​

That for example, absolutely stunning imagination.