Thinking linearly and like a flow chart was key when starting out. Later, parallel processes, multiple cores, multiple workstations and networking and prioritizing or load balancing and all the things to control traffic, share resources, all adds to the complexity but also versatility and design freedom. Sometimes it makes your head hurt but careful design and documentation will make it all easier.

 

This is why I make a distinction between program coding and problem solving.

Writing computer code is all about learning the syntax of the language. It would be ideal if you could express the solution to the problem without being tasked with learning the idiosyncrasies of the programming language.

I would suggest that you start off using BASIC in order to gain some useful experience with the full intention of moving on to more advanced languages.

 

As some others have pointed out, learning to write computer programs is far more than learning the syntax of a language. The big problem that many people struggle with is not recognizing that programming is about implementing algorithms. An algorithm is a detailed set of steps that will result in a solution to the problem. We use and devise algorithms every day in life. But most people haven't had to really sit back and think about any of the algorithms they use at the level of detail that is needed to turn them into a computer program. That's because humans are naturally good at working with a lot more ambiguity -- we are generally able to easily figure out what what meant or what intermediate steps need to be used that weren't explicitly stated. Computers aren't that way.

If you ask most people to factor a number, say 5,083, into its prime factors (either by hand or using just a four-function calculator), most of them could do it in a handful of minutes (assuming they recall things like what it means to factor a number or what prime factors are, of course). But if you ask them to write down an algorithm for how to factor an arbitrary number that could then be given to someone that hasn't learned yet how to do this task, most people will fail miserably at it. They know how to do it, but they don't know how to explain, in a generic fashion, what they did. Yet that is precisely the skill -- known as "algorithmic reasoning" -- that is needed in order to devise an algorithm that can be turned into a computer program. If you instead asked that person to write a program that gets a number from the user and then prints out its prime factors, they will also fail miserably, but will be convinced it's that the act of programming is too hard. They will contend that they don't know where to start, or that they don't know whether they should use a loop or a selection construct. But it's not a programming difficulty. They haven't learned how to reason about the underlying problem in order to come up with an algorithm that solves it.

That's what they need to focus on -- and that's what all-too-few courses in computer programming really address.

 

...
That's what they need to focus on -- and that's what all-too-few courses in computer program really address.

Good to hear from you again.

 

It is like a cooking recipe to make an omelette or a quiche.

You can give someone all the ingredients but would they know what to do if they have never cooked something before.

Would you be able to write out clear and precise instructions step by step to make an omelette?

 

It is like a cooking recipe to make an omelette or a quiche.

You can give someone all the ingredients but would they know what to do if they have never cooked something before.

Would you be able to write out clear and precise instructions step by step to make an omelette?

This is actually a point I intended to make and then forgot to -- but it is a real important one.

When programming classes talk about algorithm development, they often use more familiar examples (with "baking a cake" being a common one). But almost none of them specify who the audience is -- in fact, I can't recall seeing any text I've looked at dealing with this. Coming up with a cake recipe for a pastry chef is very different than coming up with a cake recipe for a ten-year old.

The same is true with algorithms that will be implemented via a computer program. The algorithm has to be written at a level of detail such that there is a high confidence that the person using it to write the program has a good chance of correctly implementing each step of it. But what most beginners do is they write it at a level that they could work with. So they might say, "sort the list", or "find the average" and, if asked to do that by hand, they could with no problem. But they don't know how to write a computer program to do either of those things, and so they need to develop their algorithm to a much finer degree of detail.

It's amazing how few people can write down an algorithm that, given three index cards with numbers written on them, will put the median value of the three numbers on a fourth card (using operations that are typical of the second or third week in a programming class, just after selection statements have been introduced).

These are certainly skills that most people can learn, but like most things, requires a lot of practice and failure. Unfortunately, the trend in education seems to be away from expecting practice and repetition to learn new skills.

If you are learning to program, the takeaway for you is that you should write your algorithm down and then ask yourself if you are confident that your existing skills are such that you could perform each step (or at least come close). If the answer is no, then flesh out that step of the algorithm further. Keep breaking it down until you can say yes to each step. You will quickly find that, as you gain experience developing and implementing algorithms, that you will be able to leave out more and more detail because you will have gained the skills to write programs at a higher level.

 

I once taught a course on BASIC programming. I always opened the course with a loaf of bread, a butter knife, a jar of peanut butter and a paper plate.

I then asked the class how to make a peanut butter sandwich. I said I would be a computer. Inevitably, someone would say get two pieces of bread. I’d grab the loaf and mangle it trying to get the bread without opening the bag. Then, I’d guide them to something like:

1. Pick up the loaf
2. Untwist the wire closure
3. Put the closure down
4. Open the bag
5. Take one slice out
6. Put it on the plate

And so on…

Usually, similar jollies ensued with the peanut butter. But they’d eventually get it. And I used this as an example about getting used to thinking about algorithms and how the computer thinks. Not you.

 

That is a very good example @djsfantasi .
I have a similar experience years ago when attending a microprocessor fundamentals course.
We were learning about interrupts. Our teacher, Doug, had us all heads down writing something and, unseen to us, he picked up the blackboard ruler and slammed it down on the desk. We all jumped! Then he brightly explained, "That was an example of an non mask-able Interrupt." I have never forgotten it.

 

I am learning c programming language but i find it very difficult.

What every beginner should know about the journey ahead?

Why Learning to Code is So Hard?

Learning programming is not harder than learning almost any other technical thing. The problem is, you are at a disadvantage because around the year 2000, the 'Establishment' decided to purge most of the educational resources, books, and so forth that had been written before C was created, and at the time C was created, that explained all kinds of things about the environment you are programming in.

C is terse. C expects you as a programmer to take on full responsibility- it does nothing for you- and because of this, it allows you the maximum power to do anything that can be done.

Why don't you PM me with any specific questions you have about C, and I will answer them and help you get your head around it.

 

I then asked the class how to make a peanut butter sandwich. I said I would be a computer. Inevitably, someone would say get two pieces of bread. I’d grab the loaf and mangle it trying to get the bread without opening the bag.

That's a real common example. One of the instructors at the Academy really got into it while we were remote with CoVID because he did the lecture from his kitchen, which gave him carte blanche to be as messy as he wanted to be within the tolerance of his willingness to clean up -- and he was willing to do a LOT of cleaning, including off the ceiling.

While it gets the point across to some degree, I've never been convinced that it really teaches the important lessons. Yes, it forces people to think about how they can be more detailed about instructions as they see how their original instructions can be misinterpreted, and that's a useful thing. But it fails to illustrate what makes a good algorithm, since it relies on someone intentionally misinterpreting things, usually in patently absurd ways. The problem is that it is pretty much impossible to develop any kind of algorithm that can't be misinterpreted by someone going out of their way to do so. As a consequence, it does little to get across the notion that there is a reasonable level of detail in an algorithm and part of the art is in learning to determine what level of detail is close enough to that target. Nearly all of the "make a peanut butter sandwich" type lessons completely ignore that. It's fine to start with an example like this, essentially as an ice-breaker, but it needs to be followed up with a lot more substantive meat -- which I imagine you did -- but so often instructors just go through the example, get a bunch of laughs, and assume that students are now ready to write good algorithms.

 

One of my favorite quotes...

"I really hate this dam machine,
I think that I should sell it.
It never does just what I want,
it just does what I tell it!"

 

It's fine to start with an example like this, essentially as an ice-breaker, but it needs to be followed up with a lot more substantive meat -- which I imagine you did --

Of course I followed up with substantive lessons. Starting that evening by pointing out the ridiculousness of the exercise and explaining why I performed it. But I felt it was more than an ice-breaker. It illustrated the point that the class had to think in another manner. Without understanding that point, chances are poor that one could progress to understanding what is a good algorithm.

The old cliché applies. One must learn how to crawl before one can learn to walk.

I am disappointed to learn that is a common example. I thought it was original! LoL

 

I don't know why the peanut butter sandwich is so common (or sometimes PB&J). Perhaps because (just about) everyone knows, intrinsically, how to make a peanut butter sandwich and is therefore in a good position to first see what was obviously meant by a step in the algorithm and how to then see how what was actually done is conceivably in strict compliance with it. Plus, the ingredients don't require any special prep (not even refrigeration), and there's a host of simple tasks that are easy to misinterpret ranging from how to open a bag of bread or a jar of peanut butter, to how to put the peanut butter on the bread, to how to put the pieces of bread together to finish the sandwich. Another common, but similar, approach is to take something that has simple, easy directions and then showing the same results of deliberately misinterpreting them. The one that comes to mind immediately is the set of directions on a box of Pop Tarts. Then, of course, there's always the classic, "Wash, Rinse, Repeat" from shampoo fame. And who can forget Number Five cooking breakfast by following the directions in "Short Circuit"?

 

where most beginners stumble is in the second area: algorithms.

I agree. If an algorithm is flawed, no amount of translating it to a programming language is going to make it work. Learning a language is straightforward, learning to program isn't.

Language references teach you the language, not how to program. Some will state that explicitly. They use examples to help you understand the syntax, but they don't claim they're going to teach you how to program. At least they shouldn't.

 

It must be difficult to try to learn "C" as a very first computer language. It is unfriendly and unforgiving.
The first computer language I learned was Commodor basic on VIC-20. It was a very intuitive language and I found it easy to learn. From there I progressed to learn a number of other versions including quick basic and I-basic which were all very similar. At the same time, I taught myself how to write 4-bit machine language programs for the new computer chips that were becoming available. That taught me a lot about how computer hardware works.
Then I had a need to learn Fortran. It is much more structured than basic and requires much more program planning. That made learning C much easier because by then I understood the necessity of breaking a program down into the very simplest algorithms before writing any code. I also had the good fortune to attend an excellent course on structured programming which made it much easier to construct programs that could be easily understood and edited by others.
The outcome of all this was that I was able to take on very large projects that required a lot of diverse programming. I was able to complete the projects in very short times by analyzing the requirements and breaking them down into the smallest functions possible. Then I was able to share the programming with a whole team. Clear, concise communication was a necessity.
I did it the easy way. It must be much more difficult to try to learn how to write programs in C with no idea of how to convert a requirement into algorithms or how to structure the program or how a microprocessor system works.. There is so much more to learn than just the syntax.

 

When we learn something new the dfficulty is proportional to How analogous the thing is to something we already know.

Learning mostly comprises connecting together knowledge we already have about other things with the particulars of the new thing. When we teach we lean heavily on analogies to communicate a lot of complexity in a compact form.

If you’ve never done something analogous to the thing you are trying to learn, you are at an inherent disadvantage compared to things that are “easy“ to learn. They are “easy” because you already know some large part of what you need to know thanks to your experience providing you analogies that you can compare and contrast to the new thing,

It is “hard” to learn your first card game but thanks to the inherent similarities and frameworks for card games, each onne you learn makes learning new ones easier, “it’s like go fish but with the scoring system of draw poker…” or the like leaves only details to learn, and so it is “easy”.

There is no real analogy to computer programming that isn’t some other computer programming. But once you can program competently in a language that doesn’t hide details from you, learning a new language is much easier. And, like the card games, the more variations on how computer languages can operate that you encounter, the “easier” to learn the next random language you encounter.

A big part of being a “good learner” is finding and using the analogies you have at your disposal. Seem parts of computer programming do have analogies in every day life. For example a “stack” is often explained by the stack of plates in an old-timely plate dispenser in a cafeteria. It uses a heavy spring so the plates are always levei with the top. Putting a plate on makes it go lower, taking one off raises it. It is as FIFO (first in first out) arrangement, just like the stack.

One more thing: programming appeals to, and is easier for, people with a certain style of thinking. Programming demands not only knowing the mechanics of the language you are using but the ability to break down the task you want the program to do into logical, interconnected steps.

Some people are just better at this than others. But, people not naturally inclined can and do still learn to be competent and productive programmers, it’s just harder for them.

 

When we learn something new the dfficulty is proportional to How analogous the thing is to something we already know.

Learning mostly comprises connecting together knowledge we already have about other things with the particulars of the new thing. When we teach we lean heavily on analogies to communicate a lot of complexity in a compact form.

If you’ve never done something analogous to the thing you are trying to learn, you are at an inherent disadvantage compared to things that are “easy“ to learn. They are “easy” because you already know some large part of what you need to know thanks to your experience providing you analogies that you can compare and contrast to the new thing,

It is “hard” to learn your first card game but thanks to the inherent similarities and frameworks for card games, each onne you learn makes learning new ones easier, “it’s like go fish but with the scoring system of draw poker…” or the like leaves only details to learn, and so it is “easy”.

There is no real analogy to computer programming that isn’t some other computer programming. But once you can program competently in a language that doesn’t hide details from you, learning a new language is much easier. And, like the card games, the more variations on how computer languages can operate that you encounter, the “easier” to learn the next random language you encounter.

A big part of being a “good learner” is finding and using the analogies you have at your disposal. Seem parts of computer programming do have analogies in every day life. For example a “stack” is often explained by the stack of plates in an old-timely plate dispenser in a cafeteria. It uses a heavy spring so the plates are always levei with the top. Putting a plate on makes it go lower, taking one off raises it. It is as FIFO (first in first out) arrangement, just like the stack.

One more thing: programming appeals to, and is easier for, people with a certain style of thinking. Programming demands not only knowing the mechanics of the language you are using but the ability to break down the task you want the program to do into logical, interconnected steps.

Some people are just better at this than others. But, people not naturally inclined can and do still learn to be competent and productive programmers, it’s just harder for them.

Great observation! I’ve used so many different programming languages in my lifetime, I feel that I can almost immediately be productive in a new one, for a specific limited task.
It works in reverse as well. It is hard to teach programming if you are experienced because subtly we have built these analogues over time and may be unaware that we are using them.

 

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

I think doing mathematical proofs is quite analogous.

 

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

 

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?