understand c programming logic but can't write a tough program

[khatus]

Hello guys I am a beginner in c programming.I understand the logic behind a solved problem in c programming, but I can't write a tough program(like Pascal's triangle,pyramid) without any algorithm or flowchart by myself.When the program gets a little tough, I can't solve it. What should I do now?Which book should i follow.I  need some useful advice.

[Byonnem]

To be honest, practice makes perfect... It took me 140 Hours to understand pointers and structs, so don't demotivate yourself but instead keep trying.

I found that the best way to motivate myself was by doing "realistic" challenges.

Some practical tips:

First step should always be on paper. Think, how to approach a challenge: divide it in sub-parts, flow charts and so on..
I like to layout my functions, before i start to fill them with code. Make clear with comments what you expect each function, object or what ever should do, or to what it corresponds to on the paper you made in the step before.
Comments, i cannot stress enough how important documentation is. If you can't explain what you're doing, there is something wrong.

And my final tip would be, buy a rubber duck and explain your code to him

Good Luck!

M.D.S

[rstofer]

I find it useful to write some kind of pseudo-code that explains, in sequence, what needs to be done to solve the problem.  Make this fairly fine grained and then you can write C functions for each of the steps.

Many years ago, one of the premier computer scientists suggested that programmers not have access to a computer or keyboard.  In those days we were doing flow charts and a lot more paper modeling than is typical today.

But you must be able to solve the problem on paper before you even begin to write code.  Comments explaining each step are helpful.

The C code for Pascal's Triangle is near the bottom of this page:
https://www.programiz.com/c-programming/examples/pyramid-pattern

On paper, walk through the for loops and make certain you truly understand how the code works:

Code: [Select]

// just the important stuff...

    for (i=0; i<rows; i++) {  // do as many rows as the user requested  I would rename 'i' to 'row' everywhere!

        for (space=1; space <= rows-i; space++)  // rows near the  start require more spaces to center - walk through it on paper

        for (j=0; j<=i; j++) {  // walk across the row
            if (j==0 || i==0) // the left and right edge are always '1'
                coef = 1;
            else
                coef=coef*(i-j+1)/j; // ok, this is awkward, STUDY it
            printf("%4d", coef);
        }
[/font]

The linked code works in Microsoft Visual Studio by substituting scanf_s() for scanf().  Otherwise, the compiler whines and snivels about scanf being unsafe.

The working code:

Code: [Select]

#include<stdio.h>

int main() {
    int rows, coef = 1, space, i, j;
    printf("Enter number of rows: ");
    scanf_s("%d", &rows);
    for (i = 0; i < rows; i++) {
        for (space = 1; space <= rows - i; space++)
            printf("  ");
        for (j = 0; j <= i; j++) {
            if (j == 0 || i == 0)
                coef = 1;
            else
                coef = coef * (i - j + 1) / j;
            printf("%4d", coef);
        }
        printf("\n");
    }
    return 0;
}
[/font]

ETA:  Walk through the code for rows = 1, rows = 2 and rows = 3.  That will do for a start.  Include more rows if you are so inclined.

[brucehoult]

Strange code. What is the " || i == 0" for? The program is fine without it. I could understand if it was " || i == j" but that is also unnesessary.

And it seems just overly "clever", especially in the "coef = coef * (i - j + 1) / j". Ugh!

I'd split the calculation of coef out into a very simple function:

Code: [Select]

#include <stdio.h>

int coef(int i, int j) {
  if (j == 0 || j == i)
    return 1;
  else
    return coef(i-1, j) + coef(i-1, j-1);
}

int main() {
  int rows, space, i, j;
  printf("Enter number of rows: ");
  if (EOF == scanf("%d", &rows)) return 1;
  for (i = 0; i < rows; i++) {
    for (space = 1; space <= rows - i; space++) printf("  ");
    for (j = 0; j <= i; j++) printf("%4d", coef(i, j));
    printf("\n");
  }
  return 0;
}

You can think that coef() will be inefficient. You're unlikely to be using a big enough value of rows that this will matter, but if you are then you can memoize the results:

Code: [Select]

#define MAXROWS 1024
int coefs[MAXROWS][MAXROWS]; // initialized to 0s

int coef(int i, int j) {
  if (coefs[i][j] != 0) return coefs[i][j];
  return coefs[i][j] = (j == 0 || j == i) ? 1 : coef(i-1, j) + coef(i-1, j-1);
}

This will about as fast as the original code -- or even faster as there is no multiply or divide. Of course it will use more RAM. Tradeoffs :-)

[rstofer]

Agreed!  The code, as given, may be short but it is ugly too!

I would break out the user interaction to a function called get_rows() just to make it clear in main() what was going on so rows = getrows().  I like the idea of aborting if there is no entry.

I would also break out the spaces bit to a function print_leading_spaces(int rows), again to make it clear in the  main() function exactly what was happening.

Functions will kind of spill out of the block diagram and pseudo code.  Find something that is more or less isolated logic and make it a function.  It just makes things easier to read.

There's nothing ambiguous about a function named 'print_leading_spaces(rows).  I would also substitute 'row' for 'i' and maybe 'col' for 'j'.

We could get a lot more specific with something like 'print_leading_spaces(number_of_rows)' and change the variable 'rows' to 'number_of_rows'.  Or, leave well enough alone.  But the more descriptive the name, the better.  Until it looks stupid....

[nigelwright7557]

Start off with small programs and build up to the complicated stuff slowly.

For simple stuff I just bang the code in.
For more complicated stuff  I take a step back and write out a flowchart of what I want the software to do.
Its easier to change it on paper than having to rewrite all the code again.

[SilverSolder]

I find it useful to write some kind of pseudo-code that explains, in sequence, what needs to be done to solve the problem.  Make this fairly fine grained and then you can write C functions for each of the steps.  [...]

This is a very powerful approach.  Basically,  write your program in (structured) English first.   When you have done that, you will have defined the algorithm that you want to use.

Designing the algorithm is a very different thought process from coding that algorithm in a specific programming language.

[admiralk]

When the program gets a little tough, I can't solve it.

Can you solve the problem without it being a program? If so, just imagine explaining the solution to a 5 year old. Then use that solution to base your program on, instead of the one you are trying to use. Write the simple steps out in comments and then replace the comments with code. That way, instead of looking at the big picture, you will only focus on one step at a time which is all you need to do. Do not even think about functions, until you find yourself writing the same thing over and over again. Once you get it working, then worry about cleaning it up.

[Simon_RL]

The C Programming Language by Brian Kernighan is by for the best book on C. It is what I used at Uni instead of the recommended book and it was the best decision I made.

[rstofer]

The C Programming Language by Brian Kernighan is by for the best book on C. It is what I used at Uni instead of the recommended book and it was the best decision I made.

There is the original (pre-ANSI) version that works with classical C and a newer ANSI version that is more aligned with modern C.  I have both!

I actually use the string and numeric conversion functions in my own projects.  This is useful when I want to avoid using a heap for the library string functions.  And that is just about always!

[westfw]

I have a special dislike for "programing challenges" that are actually "figure out the mathematical algorithm" problems.
But for program in general (using Pascal's Triangle as an example):

• Understand the problem.  Do you know how to make a Pascal Triangle by hand?
• Document the problem.
• Research prior art and algorithms.  Is there an existing library that you're allowed to use (consider honor codes, licensing issues, etc)?  There's a well known formula for the Kth element of the Nth row of PT, for instance.  You CAN decide to echo the "by hand" method, though.
• Document how you intend to solve the problem.
• Implement.  Use whatever language you want (but keep in mind your final target.)  Get the correct output.
• Optimize.  Convert to the desired language, if necessary.  Don't over-optimize for the problem.
• Make it pretty.  Make the output pretty, make the code pretty, fix all your formatting and documentation.  Remove obscure language constructs (why did you use them in the first place?)
• Document how to use it.
• Goto (1) if your understanding changes along the way.

Writing code before you understand the problem is probably the biggest cause of bad software in the world.  It is, alas, frequently necessary, because problems in real world programming situations are frequently not very well defined.
And also: "premature optimization is the root of all evil." (and many bugs)  :-)

[aeberbach]

In 20+ years as a software engineer when I look back at the times I failed badly I have realised it was almost always* because I tried to do too much at once. If you are feeling overwhelmed or stuck or there's a bug you can't solve the solution is almost always to break down the steps further and understand each smaller step - they add up to success in the broader problem. Eat the elephant one bite at a time, as they say.

*OK, once or twice it was Nethack.

[SilverSolder]

[...]Writing code before you understand the problem is probably the biggest cause of bad software in the world.  It is, alas, frequently necessary, because problems in real world programming situations are frequently not very well defined.[...]

My favourite tactic against "not very well defined requirements" is to write as little code as possible,  having as few features as possible.  This way, the real requirements tend to get flushed out in the open faster.

[nigelwright7557]

In 20+ years as a software engineer when I look back at the times I failed badly I have realised it was almost always* because I tried to do too much at once. If you are feeling overwhelmed or stuck or there's a bug you can't solve the solution is almost always to break down the steps further and understand each smaller step - they add up to success in the broader problem. Eat the elephant one bite at a time, as they say.

*OK, once or twice it was Nethack.

Just break down big problems into lots of smaller easier problems.
Old saying,"You can move mountains, if you do it by the barrow load."

[Elestaten_Harold]

I'm really not good at it yet, maybe someone can recommend good udemy c++ course?

[brucehoult]

I'm really not good at it yet, maybe someone can recommend good udemy c++ course?

Modern C++ is horrendously complex. And the standard library is worse. I doubt that anyone really knows it. Every company I ever worked at that said "We use C++" also had a long list of C++ features that were forbidden. Mostly they might as well have used Java.

When C++ came out it had a lot of features that were just "Better C". For example being able to declare and initialize a variable at the point of first use instead of only before the first statement in a block. Modern C has adopted those, making it much more pleasant than C89 was (let alone K&R).

I suggest people learning to program start with a very simple language that they can easily learn all of, and then concentrate on how to use that to build real programs. C is on the border of that. Pascal and Python do everything C can (except speed in the case of Python) but with easier syntax. Scheme had much simpler syntax but some annoying quirks that Dylan fixed -- similar to the "Better C" things C++ did.

Personally, I think it's not stupid for beginners to start with a simple assembly language, and use stdio and malloc/free from the C library. Original MIPS or ARMv2 or RISC-V RV32I -- something with just a handful of instruction formats so it's easy to understand what instructions and variations are possible. AVR is ok too. 6502 is very simple to learn, but runs into the problem that it's so simple it's hard to get anything done.

A great thing these days is it's so very easy to start programming in any of these instruction sets. One simple command will install a compiler and assembler and linker and libraries and debugger and all that stuff, and another will install an emulator (usually qemu).

My biggest problem when I started learning programming -- and in fact any time I learn a new programming language -- is not in understanding the examples that are shown to me, but in understanding where the limits are: what I CAN'T say in the language. C is just awful for this. Just look at some of the things a smart guy like Simon tries to force into C that it actually can't do. Python and Pascal and Go aren't a lot better for this. Unless you understand the underlying machine model or registers and ram and instructions it's very hard to make sense of them.

[tggzzz]

I'm really not good at it yet, maybe someone can recommend good udemy c++ course?

Modern C++ is horrendously complex. And the standard library is worse. I doubt that anyone really knows it. Every company I ever worked at that said "We use C++" also had a long list of C++ features that were forbidden. Mostly they might as well have used Java.

When C++ came out it had a lot of features that were just "Better C". For example being able to declare and initialize a variable at the point of first use instead of only before the first statement in a block. Modern C has adopted those, making it much more pleasant than C89 was (let alone K&R).

I suggest people learning to program start with a very simple language that they can easily learn all of, and then concentrate on how to use that to build real programs.

Very very true For an amusing demonstration of why very few people understand C++, see the FQA http://yosefk.com/c++fqa/

But back to the OP. They need to understand the difference between an algorithm and a language and a library.

If you cannot outline the algorithm that you will use, then

• the language is irrelevant; if an author doesn't have a story then they can't write it in English, German, Malayalam, ...
• find a library that encapsulates the necessary algorithm

Occasionally the algorithm suggests that one language would be more appropriate than others.

[westfw]

A problem is that when you take an "Algorithms" class, you don't learn about how to turn a big problem into a program, you just learn about a set of relatively small tools that can (maybe) help solve part of the problem.
"We spent 5 weeks learning about graph algorithms, but I can't figure out how to make my email program use any of that!"

[tggzzz]

A problem is that when you take an "Algorithms" class, you don't learn about how to turn a big problem into a program, you just learn about a set of relatively small tools that can (maybe) help solve part of the problem.
"We spent 5 weeks learning about graph algorithms, but I can't figure out how to make my email program use any of that!"

... in which case letting such a person near a keyboard with a compiler/IDE would be a disaster in the making.

Practice without theory is blind fumbling.
Theory without practice is mental masturbation.

[hwj-d]

Ok, don't read the complete thread now, only the first post.
The biggest failure is when you try to achieve too much at once. Programming is a time-consuming activity for a beginner with a very large overhead to climb the practical learning curve. Here only learning by doing helps. If an algorithm doesn't work, or the compiler doesn't want to compile for syntactic reasons, it helps to take the problem out, break it down into its rudimentary components, and test and debug those separately until you get the error or difficulty. This is time consuming, but necessary. So even now you are only just learning the necessary techniques, and you get more realistic ideas about the time needed to get larger program blocks working. You have to go this way yourself, you cannot study it theoretically. The literature supports only this way, i.e. it follows it, not the other way around.

[SilverSolder]

Ok, don't read the complete thread now, only the first post.
The biggest failure is when you try to achieve too much at once. Programming is a time-consuming activity for a beginner with a very large overhead to climb the practical learning curve. Here only learning by doing helps. If an algorithm doesn't work, or the compiler doesn't want to compile for syntactic reasons, it helps to take the problem out, break it down into its rudimentary components, and test and debug those separately until you get the error or difficulty. This is time consuming, but necessary. So even now you are only just learning the necessary techniques, and you get more realistic ideas about the time needed to get larger program blocks working. You have to go this way yourself, you cannot study it theoretically. The literature supports only this way, i.e. it follows it, not the other way around.

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

[grizewald]

I have a special dislike for "programing challenges" that are actually "figure out the mathematical algorithm" problems.
But for program in general (using Pascal's Triangle as an example):

• Understand the problem.  Do you know how to make a Pascal Triangle by hand?
• Document the problem.
• Research prior art and algorithms.  Is there an existing library that you're allowed to use (consider honor codes, licensing issues, etc)?  There's a well known formula for the Kth element of the Nth row of PT, for instance.  You CAN decide to echo the "by hand" method, though.
• Document how you intend to solve the problem.
• Implement.  Use whatever language you want (but keep in mind your final target.)  Get the correct output.
• Optimize.  Convert to the desired language, if necessary.  Don't over-optimize for the problem.
• Make it pretty.  Make the output pretty, make the code pretty, fix all your formatting and documentation.  Remove obscure language constructs (why did you use them in the first place?)
• Document how to use it.
• Goto (1) if your understanding changes along the way.

Writing code before you understand the problem is probably the biggest cause of bad software in the world.  It is, alas, frequently necessary, because problems in real world programming situations are frequently not very well defined.
And also: "premature optimization is the root of all evil." (and many bugs)  :-)

Not a bad list, but I'd object to step 7 on principle because if you have that step at all, it never ends up being done in the real world because it's not perceived as adding value if the program already works.

Good formatting and commenting is something that should be done as you write the code, not relegated to a "nice to have" afterwards.

I've dealt with far too much code which looks like it was written by a dyslexic in a hurry. You should always spare a thought for the guy who has to maintain what you've written, maybe decades later. Oh, and comments should tell me WHY you are doing something, never WHAT you are doing.

 

[nfmax]

Good formatting and commenting is something that should be done as you write the code, not relegated to a "nice to have" afterwards.

I've dealt with far too much code which looks like it was written by a dyslexic in a hurry. You should always spare a thought for the guy who has to maintain what you've written, maybe decades later. Oh, and comments should tell me WHY you are doing something, never WHAT you are doing.

If you use a special algorithm you found somewhere, you should place a reference to the original in a comment, perhaps with an explanation why you used it. (I mean a bibliographic reference, not a gentrified pointer)

[hwj-d]

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

Something to laugh about there?

[tggzzz]

I have a special dislike for "programing challenges" that are actually "figure out the mathematical algorithm" problems.
But for program in general (using Pascal's Triangle as an example):

• Understand the problem.  Do you know how to make a Pascal Triangle by hand?
• Document the problem.
• Research prior art and algorithms.  Is there an existing library that you're allowed to use (consider honor codes, licensing issues, etc)?  There's a well known formula for the Kth element of the Nth row of PT, for instance.  You CAN decide to echo the "by hand" method, though.
• Document how you intend to solve the problem.
• Implement.  Use whatever language you want (but keep in mind your final target.)  Get the correct output.
• Optimize.  Convert to the desired language, if necessary.  Don't over-optimize for the problem.
• Make it pretty.  Make the output pretty, make the code pretty, fix all your formatting and documentation.  Remove obscure language constructs (why did you use them in the first place?)
• Document how to use it.
• Goto (1) if your understanding changes along the way.

Writing code before you understand the problem is probably the biggest cause of bad software in the world.  It is, alas, frequently necessary, because problems in real world programming situations are frequently not very well defined.
And also: "premature optimization is the root of all evil." (and many bugs)  :-)

Not a bad list, but I'd object to step 7 on principle because if you have that step at all, it never ends up being done in the real world because it's not perceived as adding value if the program already works.

Good formatting and commenting is something that should be done as you write the code, not relegated to a "nice to have" afterwards.

I've dealt with far too much code which looks like it was written by a dyslexic in a hurry. You should always spare a thought for the guy who has to maintain what you've written, maybe decades later. Oh, and comments should tell me WHY you are doing something, never WHAT you are doing.

Good formatting should take 1 keystroke in a decent language (i.e. not C/C++). Good commenting is more of a rarity, especially with the XP/Agile "no comments because they are out-of-sync with the self-explanatory code" religious dogma.

As for "why" rather than "what", yes indeed - but add in "why not" where beneficial!

[rstofer]

In terms of formatting, Microsoft Visual Studio does a nice job as does Visual Studio Code.

[SilverSolder]

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

Something to laugh about there?

There are some things so serious, we can ONLY laugh at them!  -- Niels Bohr

[hwj-d]

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

Something to laugh about there?

There are some things so serious, we can ONLY laugh at them!  -- Niels Bohr

Buddy, you are annoying to trigger someone. Try to find a new girlfriend.

[SilverSolder]

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

Something to laugh about there?

There are some things so serious, we can ONLY laugh at them!  -- Niels Bohr

Buddy, you are annoying to trigger someone. Try to find a new girlfriend.

You are taking this the wrong way.

The issue of writing correct / functional programs is not new, and will remain an issue for a long time.  It is beyond our power to solve easily, hence the Niels Bohr quote.

[emece67]

.

[hwj-d]

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

Something to laugh about there?

There are some things so serious, we can ONLY laugh at them!  -- Niels Bohr

Buddy, you are annoying to trigger someone. Try to find a new girlfriend.

You are taking this the wrong way.

The issue of writing correct / functional programs is not new, and will remain an issue for a long time.  It is beyond our power to solve easily, hence the Niels Bohr quote.

Maybe.
It's up to you, to express yourself more clearly. I specifically asked again.
In the text: "someone" and "you" has different meanings, apart from the fact that english/american is not my native language. Shit happens. 

[SilverSolder]

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

Something to laugh about there?

There are some things so serious, we can ONLY laugh at them!  -- Niels Bohr

Buddy, you are annoying to trigger someone. Try to find a new girlfriend.

You are taking this the wrong way.

The issue of writing correct / functional programs is not new, and will remain an issue for a long time.  It is beyond our power to solve easily, hence the Niels Bohr quote.

Maybe.
It's up to you, to express yourself more clearly. I specifically asked again.
In the text: "someone" and "you" has different meanings, apart from the fact that english/american is not my native language. Shit happens. 

Kein problem! 

[hwj-d]

 

[hwj-d]

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

Something to laugh about there?

There are some things so serious, we can ONLY laugh at them!  -- Niels Bohr

Buddy, you are annoying to trigger someone. Try to find a new girlfriend.

You are taking this the wrong way.

The issue of writing correct / functional programs is not new, and will remain an issue for a long time.  It is beyond our power to solve easily, hence the Niels Bohr quote.

Maybe.
It's up to you, to express yourself more clearly. I specifically asked again.
In the text: "someone" and "you" has different meanings, apart from the fact that english/american is not my native language. Shit happens. 

Kein problem! 

Do we know each other from stuttgart?

[Nominal Animal]

Experimenting with problems that interest yourself is a good way to progress.

For example, I am lazy.  I want to do things well enough to trust them, so I can do other, more interesting stuff without worrying about falling down because of shoddy earlier work.  This means I am well suited for low-level, system/OS/library level work, but not as fast as others when it comes to user interfaces or mockups.

If you are interested in mathematics, then the various methods of calculating Fibonacci numbers is an excellent opportunity for testing different things, and learning how to solve problems via computer programs.

You have the standard recursive algorithm.  It is simple to implement, but slow.
You also have the iterative method (remembering the two previous numbers, calculating the next one, and forgetting the oldest number).  It is simple to implement, but has to iterate from F₁ to the desired Fibonacci number.
The next step up is using an array to hold the previously calculated Fibonacci numbers.
The next step up is using the mathematical properties of the series, namely
$$\begin{aligned}
F_{2 n - 1} &= F_{n}^2 + F_{n-1}^2 \\
F_{2 n} &= \left(2 F_{n-1} + F_{n} \right) F_{n} \\
\end{aligned}$$
which lets you calculate any Fibonacci number in logarithmic time and space complexity.
The next step up is direct calculation of any Fibonacci number, using
$$F_n = \frac{\varphi^n - (-\varphi)^{-n}}{\sqrt{5}}$$
and if using truncation (as C uses for integers, for example),
$$F_n = \left\lfloor \frac{\varphi^n}{\sqrt{5}} + \frac{1}{2} \right\rfloor$$
where $$\varphi = \frac{1 + \sqrt{5}}{2} \approx 1.61803$$
The next step up is to realize the limits of the hardware number types (integer and floating-point types), and to write your own bignum (for the logarithmic, integer-based method) or arbitrary-precision (for the direct evaluation) implementation.  At that point, we're writing GNU Scientific Library style code, and well and truly deep into programming, typically with a decade or more practical experience.  So, this is not a series of exercises, but rather a simple problem you can attack again and again, whenever you feel the need or inspiration to develop or hone your skills.

The same goes for most practical problems as well.  One of my old-timey favourites is the venerable sort command, which in general terms accepts input as lines, and outputs them in sorted order.  It is an excellent real-world test for many sort algorithms, because it is a real-world task.  It shows very clearly how some algorithms work best when the data is almost sorted, how some algorithms have weak points (like if the input is in opposite order to output; rare but occasionally occurring situation).  Very informative.

The reason I like it is because when you overcome the need to optimize code, and get to the stage where programs are just tools you wield as easily as you might wield a fork or a spoon, you start looking at what to optimize to get the most bang for your effort; you're essentially optimizing your optimization efforts, for the results to be most useful to you or your users.  Because mass storage is still at least one order of magnitude (10x) slower than working memory (RAM), it turns out that if we want to minimize the real-world time it takes for the data to be output -- i.e. the time the human running the command has to wait, if it is run interactively --, it is better to waste some efficiency in order to increase the throughput.  You do this by reading each line into a sorting abstract data type; usually a tree or a heap.  This way, more CPU time is used in sorting the data, but because each line is sorted as soon as it is read, and the sorting takes typically less time than reading the line into working memory, the entire job takes less real-world time to complete.  The CPU just worked a bit harder, that's all.  (This is obviously not true if the data to be sorted is already in working memory; then, it would be best to just copy the data over, and then run the most efficient sorting algorithm on it.)

Sorting data in itself is a tricky subject, because in most real world cases, the actual amount of unique inputs is limited.  This means that sorting ints, longs, floats, or even doubles is perfectly possible to do in linear time, even though it has been proven that mathematically, logarithmic time is optimum.  The reason is that radix sorting does its work in linear time if there is a limited number of possible input values.  So, given enough data, it will beat all other sort algorithms.  Currently, the breakover point is somewhere around millions of doubles, with typical common sort algorithms like QuickSort being faster for smaller amounts of data.  Again, if you have useful information on the real-world data to be sorted, you can make the typical cases very fast, with some other cases slower than optimum.  This means that a very good programmer (or "software architect", designer, problem-solver, or whatever; not the code monkey, but the person who decides how the program solves the problems it needs to solve), has to be aware of 1) real-world needs, 2) possible algorithms and tools (to have as wide selection as possible, instead of treating all problems the same), and 3) of the hardware possibilities.

But even more importantly, a good programmer is always learning more.  Because you never know enough.

It all starts from interest in problem solving.  Anything and everything you can learn about that, will help.  I'm not talking only about problem solving via computer programs, but even oddball tricks like how to solve a Rubik's Cube in an orderly fashion is really just an algorithm, and understanding how different algorithms work, is like getting new tools in your toolbox.  Then you use those different tools on various problems you are interested in, to see how they work.  Real-world experience beats theoretical knowledge every time, so expect to do a lot of this, basically for the rest of your life.  Fortunately, it is both fun and rewarding!

[westfw]

I'd object to step 7 ["make it pretty"] on principle because if you have that step at all, it never ends up being done in the real world

I dunno.  If your ISO9000 process says your software needs DOxygen comments, this is the place where you carefully fiddle with the comments you've already written (right?) to make them look good in the documentation.  It's where you flush things out so that the Junior Engineers won't have trouble understanding it.  Check for all those dangerous strcpy() and replace them with buffer-overflow-protected, thread-safe, etc versions.   All the stuff that would theoretically be detected in a thorogh code review that you didn't pay that much attention to because you were focussing on THE PROBLEM.

And there is also the non-real world.  Academia and Publication, when you'll (hopefully) want a much better level of "prettiness" than the real world would require.

you get to the point where you can write quite long programs that compile the first time

Interesting.  I've reflected that I frequently don't pay much attention to whether I've made minor syntax errors on initial program entry.  Because, after all, the compiler will tell me about them real quick, anyway.  (of course, occasionally such errors are NOT detected and result in hard-to-find problems, and that's annoying...)

[hwj-d]

Experimenting with problems that interest yourself is a good way to progress.

For example, I am lazy.  I want to do things well enough to trust them, so I can do other, more interesting stuff without worrying about falling down because of shoddy earlier work.  This means I am well suited for low-level, system/OS/library level work, but not as fast as others when it comes to user interfaces or mockups.
...

Yeah, have you ever seen an original win3.1 SDK in a 1.5m long bookshelf? At these early times I programmed an original hp32s with nearly original outer dimensions and dot-matrix scrolling display to learn it. This calculator serves me a long time, and I have it functional these win10 times too. That's my learning by doing with a practical background.

[Nominal Animal]

Yeah, have you ever seen an original win3.1 SDK in a 1.5m long bookshelf?

No, but I did have a '286 in the DOS era, before Windows, and learned Pascal on it.  Was my second computer.  The first one was a C128.

This calculator serves me a long time, and I have it functional these win10 times too. That's my learning by doing with a practical background.

Sure, but having and keeping an useful tool is slightly different to learning programming by doing.  I meant that practice is necessary for learning and honing ones skill, not that doing something like that, or maintaining calculator software across decades, necessarily makes you an excellent programmer

Knowing the importance of good, reliable tools, and treating your own programs as such, seems to help, though.

[hwj-d]

Yeah, have you ever seen an original win3.1 SDK in a 1.5m long bookshelf?

No, but I did have a '286 in the DOS era, before Windows, and learned Pascal on it.  Was my second computer.  The first one was a C128.

This calculator serves me a long time, and I have it functional these win10 times too. That's my learning by doing with a practical background.

Sure, but having and keeping an useful tool is slightly different to learning programming by doing.  I meant that practice is necessary for learning and honing ones skill, not that doing something like that, or maintaining calculator software across decades, necessarily makes you an excellent programmer

Knowing the importance of good, reliable tools, and treating your own programs as such, seems to help, though.

Did you noticed, that i programed this thing by my own from scratch? 
Edit: And SDK means that elementar Software Development Kit for handling all these fundamental ms-routines and parameters and all this new methods for  TrueType, OLE, DragDrop, Mulitastking at this time, that came on paper and a bunch of CD's. That was not Borland Pascal

[SilverSolder]

After about 30 or 40 years of this, you get to the point where you can write quite long programs that compile the first time  (notice, I didn't say "work" the first time!)   

Something to laugh about there?

There are some things so serious, we can ONLY laugh at them!  -- Niels Bohr

Buddy, you are annoying to trigger someone. Try to find a new girlfriend.

You are taking this the wrong way.

The issue of writing correct / functional programs is not new, and will remain an issue for a long time.  It is beyond our power to solve easily, hence the Niels Bohr quote.

Maybe.
It's up to you, to express yourself more clearly. I specifically asked again.
In the text: "someone" and "you" has different meanings, apart from the fact that english/american is not my native language. Shit happens. 

Kein problem! 

Do we know each other from stuttgart?

No, I have not been to Stuttgart for many years.   I live in the USA and the UK.  Funnily enough, I heard a teenage boy speaking German at an American supermarket this weekend.  I asked him where learned.  "School."  -  He also knew a bit of Norwegian.  I like it when young people show an interest in other cultures and languages.  There's not enough of it.

[hwj-d]

...
Do we know each other from stuttgart?

No, I have not been to Stuttgart for many years.   I live in the USA and the UK.  Funnily enough, I heard a teenage boy speaking German at an American supermarket this weekend.  I asked him where learned.  "School."  -  He also knew a bit of Norwegian.  I like it when young people show an interest in other cultures and languages.  There's not enough of it.

Ok, thanks. We had an EEVblog-Meeting last year with some members in Stuttgart.

[SilverSolder]

...
Do we know each other from stuttgart?

No, I have not been to Stuttgart for many years.   I live in the USA and the UK.  Funnily enough, I heard a teenage boy speaking German at an American supermarket this weekend.  I asked him where learned.  "School."  -  He also knew a bit of Norwegian.  I like it when young people show an interest in other cultures and languages.  There's not enough of it.

Ok, thanks. We had an EEVblog-Meeting last year with some members in Stuttgart.

Ah, well now there's a good excuse to go to Stuttgart! 

[Nominal Animal]

Did you noticed, that i programed this thing by my own from scratch? 

No, I missed that.  But that makes it an excellent example of what I meant about being fundamentally lazy!  Do it well enough it from the get go, so you can trust it

Edit: And SDK means

I know; I just chose to not work with Windows low-level stuff.  In the 1996-2003 timeframe, I did mostly internet stuff (both server and client-side; not just HTTP/HTML, but FTP and file servers too), and some interactive cross-platform multimedia with Shockwave Internet Studio.  I did have a work machine with Windows till 2003 or so, but used Linux more since 1997 or so; completely switched to Linux in 2003 or thereabouts.

Before Windows came to the market, I did use Borland Pascal for a couple of commercial programs for MS-DOS.  For one, I did copy protection by rewriting the EXE relocator code, using debug.exe, because I had neither TASM nor MASM available. I did have binders full of descriptive geometry, computer graphics (math side) stuff, as well as Ralf Brown's Interrupt List...  Now that one was absolutely amazing!

[hwj-d]

Did you noticed, that i programed this thing by my own from scratch? 

No, I missed that.  But that makes it an excellent example of what I meant about being fundamentally lazy!  Do it well enough it from the get go, so you can trust it

Don't really know, what you mean with "lazy". That's a nice passing time on the side.

At this time, a little later, i had taken the MCSE examinations(NT) by myself because I needed them for my independence.  That included TCP/IP as well as MS-Server in the enterprise. That don't stop there. Heterogen administration of UNIX like network, FreeBSD, and I became a special programmer for implementing applications (RFC, GnuPGP, and all the protocol-stuff arround) and a forensic analyser. After that I'm a professional IT-consult. But yes, it originally started with 6502(Kim) 8085/Z80 (Nascom) and understanding their 8-bit architecture, hardware and assembler programming. Since that time I still have a penchant for hardware and analog electronics, so i'm here in the blog. 
 

Edit:
I know; I just chose to not work with Windows low-level stuff.  In the 1996-2003 timeframe, I did mostly internet stuff (both server and client-side; not just HTTP/HTML, but FTP and file servers too), and some interactive cross-platform multimedia with Shockwave Internet Studio.  I did have a work machine with Windows till 2003 or so, but used Linux more since 1997 or so; completely switched to Linux in 2003 or thereabouts.

Before Windows came to the market, I did use Borland Pascal for a couple of commercial programs for MS-DOS.  For one, I did copy protection by rewriting the EXE relocator code, using debug.exe, because I had neither TASM nor MASM available. I did have binders full of descriptive geometry, computer graphics (math side) stuff, as well as Ralf Brown's Interrupt List...  Now that one was absolutely amazing!

Similar for me, except for the graphic stuff, but more RFC and network protocols.
But it's been a while ...

[SilverSolder]

Did you noticed, that i programed this thing by my own from scratch? 

No, I missed that.  But that makes it an excellent example of what I meant about being fundamentally lazy!  Do it well enough it from the get go, so you can trust it

Don't really know, what you mean with "lazy". That's a nice passing time on the side.

At this time, a little later, i had taken the MCSE examinations(NT) by myself because I needed them for my independence.  That included TCP/IP as well as MS-Server in the enterprise. That don't stop there. Heterogen administration of UNIX like network, FreeBSD, and I became a special programmer for implementing applications (RFC, GnuPGP, and all the protocol-stuff arround) and a forensic analyser. After that I'm a professional IT-consult. But yes, it originally started with 6502(Kim) 8085/Z80 (Nascom) and understanding their 8-bit architecture, hardware and assembler programming. Since that time I still have a penchant for hardware and analog electronics, so i'm here in the blog. 
 

Edit:
I know; I just chose to not work with Windows low-level stuff.  In the 1996-2003 timeframe, I did mostly internet stuff (both server and client-side; not just HTTP/HTML, but FTP and file servers too), and some interactive cross-platform multimedia with Shockwave Internet Studio.  I did have a work machine with Windows till 2003 or so, but used Linux more since 1997 or so; completely switched to Linux in 2003 or thereabouts.

Before Windows came to the market, I did use Borland Pascal for a couple of commercial programs for MS-DOS.  For one, I did copy protection by rewriting the EXE relocator code, using debug.exe, because I had neither TASM nor MASM available. I did have binders full of descriptive geometry, computer graphics (math side) stuff, as well as Ralf Brown's Interrupt List...  Now that one was absolutely amazing!

Similar for me, except for the graphic stuff, but more RFC and network protocols.
But it's been a while ...

My "gateway drug" was an Acorn Atom (6502)...   Guess that processor has a lot to answer for! 

[brucehoult]

My "gateway drug" was an Acorn Atom (6502)...   Guess that processor has a lot to answer for! 

The 6502 is a horrid little CPU. It uses an incredibly small number of transistors but is worse to program on than all the other 8 bit processors except .. hmm .. 8080, z80, 6800, 2650, SC/MP, 8051, PIC and no doubt some others I've suppressed memories of.

Let me rephrase that .. the 6502 is better than all 8 bit processors except the AVR (which came much much later) and 6809 (which is close to being an 8088 without segment registers, except faster)

[rstofer]

I certainly wouldn't prefer a 6502 to a Z80 (or even an 8080) but that's just me.  I did a bunch of work attaching early hard drives to Apple IIs and, of course, the driver had to run on a 6502.  Maybe I just didn't have enough time in grade.

I started with the Altair 8800 when it first came out and got pretty well indoctrinated into the 8080 way of doing things.  The progression to the Z80 was fairly straightforward.

Several years ago, I bought one of the new Zilog eZ80 boards where the processor runs at 50 MHz.  I build a daughter card to hold a Compact Flash device and two FTDI seriel<->USB chips (before the newer 4 channel devices) and I can tell you, a 50 MHz CPU makes CP/M scream!

No, I would never pick up a 6502 but I still mess with Z80 stuff via RC2014 projects.

https://rc2014.co.uk/

I have 3 of their systems - each different in capability but one runs CP/M.

[gbaddeley]

As a C programmer for 25+ years (and a slew of other languages), it pays to format (pretty) and document from the very start. Investing a little time has big dividends when you (or someone else) needs to look at the code in the future. It should be easy to follow and make logical sense. Extensive comments & documentation  are not always productive. They should aid in code readability, that’s all.

[Nominal Animal]

Don't really know, what you mean with "lazy".

Do the thing well enough from the get go, so that you can trust it later on, instead of wasting time fixing small bugs all the time.

It also leads to the KISS principle and Unix philosophy.  Works well for me.

Nowadays, I mostly do C/POSIX/GNU low-level stuff, and Python for UIs.

[Nominal Animal]

Extensive comments & documentation [...] should aid in code readability, that’s all.

I like to emphasize that the comments should describe the programmer intent; the things you cannot read from the code itself.

Commenting what the code does is unhelpful, as reading the code tells that already; we don't want to have to read it twice.
But reading a comment that describes the general idea behind the operation (like "sort the given array using the QuickSort algorithm") or the reason why a specific detail must be just so ("we need to hold the foo lock while calling this function, because otherwise we can deadlock with baz"), those are helpful.

Even after three decades, I am still trying to learn how to write more useful comments.  I wish someone had pointed out their importance earlier on!

[bsudbrink]

One thing that requires careful attention with comments is to keep them in sync with code changes.  Many times I have seen cases where detailed comments "evolved" into incorrect comments.  All of the "old hands" knew the comments were suspect but it made bringing on new people harder.

[brucehoult]

I certainly wouldn't prefer a 6502 to a Z80 (or even an 8080) but that's just me.  I did a bunch of work attaching early hard drives to Apple IIs and, of course, the driver had to run on a 6502.  Maybe I just didn't have enough time in grade.

The 8080 looks like it should be better than the 6502, with 7 bytes of registers instead of 3, but they're so restricted that's it's just frustrating. You can fit in a fairly nice looking memcpy() or memcmp() or strlen(), str[n][cpy,cmp]() with 16 bit src and st pointers and length, and the code is even quite compact e.g. 9 bytes in the loop (13 total) and 48 clock cycles per byte copied for memcpy(). The z80 is slightly slower at 50 clock cycles per byte.

But anything more complex at all and you simply don't have the resources.

Even then it's annoying that inc/dec of a 16 bit register pair doesn't set any flags, so you have to do something janky like copy one half into A then OR the other half, then check if A is zero (or AND the two halves if you want to check for -1).

6502 handles these simple loops worse, at least in code size and complexity. e.g. suppose dst, src, and sz are in pairs of zero page locations.

Code: [Select]

    ldy #0 ; 2 bytes, 2 cycles
    inc szh; 2 bytes, 5 cycles
    ldx szl ; 2 bytes 3 cycles
    beq decSzh ; 2 bytes, 2 cycles (not taken 99.6% of the time)
    inx ; 1 byte, 2 cycles
loop:
    lda (src),y ; 2 bytes, 5-6 cycles
    sta (dst),y ; 2 bytes 6 cycles
    iny ; 1 byte, 2 cycles
    beq nextPage ; 2 bytes, 2 cycles (99.6% not taken)
decSz:
    dex ; 1 byte, 2 cycles
    bne loop ; 2 bytes, 3 cycles (99.6% taken)
decSzh:
    dec szh ; 2 bytes, 5 cycles
    bne loop ; 2 bytes, 3 cycles
    rts ; 1 byte, 6 cycles

nextPage:
    inc srch ; 2 bytes, 5 cycles
    inc dsth ; 2 bytes, 5 cycles
    jmp decSz ; 3 bytes, 3 cycles

So we have a pretty large total of 30 bytes of code but only 20 to 21 clock cycles per byte copied, depending on the alignment of src.

The 6502 code is 2.31x the size of the 8080 code (your library is 17 bytes bigger), but the 8080 code takes 2.34x (2.44x Z80) more clock cycles to execute, every time you run it.

The Atari 400/800 run the 6502 at 1.79 MHz, so a z80 would have to be at 4.37 MHz to match it on memcpy.
The BBC micro ran the 6502 at 2.0 MHz, so a z80 would have to be at 4.88 MHz to match it on memcpy.


As soon as you have more variables involved in the loop than this, the 8080/z80 get a lot worse because you have to start shuffling things in and out of registers, taking a lot more code and a lot more cycles.

The 6502 doesn't get any worse until you run out of the 256 bytes of "pseudo registers" in zero page.

The z80 lets you have two more pointers in IX and IY registers, possibly freeing up BC and/or DE for more 8 bit variables. But the 6502 lets you have dozens and dozens more 8 and 16 bit variables in zero page.

[hwj-d]

Don't really know, what you mean with "lazy".

Do the thing well enough from the get go, so that you can trust it later on, instead of wasting time fixing small bugs all the time.

It also leads to the KISS principle and Unix philosophy.  Works well for me.

Nowadays, I mostly do C/POSIX/GNU low-level stuff, and Python for UIs.

My suggestion referred to the learner, who always runs into problems (syntactically, logically, language-dependent), because he doesn't do exactly this, namely to want to program much too large blocks at once, or doesn't differentiate into handy algorithm parts based on the overall goal. But this is exactly one of the essential points of the art of programming, which you learn by doing over time. So I was talking about the experimental phase of someone like the OP, who asked just that, who works out the programming precisely in this way of dividing it into manageable parts, and not to the professional in a productive environment, who knows, possibly still in a team. Learning isn't wasting time; someone have to do it bevore he/she is a productive programmer.

[Nominal Animal]

My suggestion referred to the learner, who always runs into problems (syntactically, logically, language-dependent), because he doesn't do exactly this, namely to want to program much too large blocks at once, or doesn't differentiate into handy algorithm parts based on the overall goal.

Yes, exactly: and that is the short-sighted kind of laziness that leads only to more work in the long term.

Those of us who are truly lazy optimize their efforts over the long run!

Postponing work of an hour today so you need two spend two hours tomorrow on it isn't laziness, it is wasteful procrastination.

Keeping changes to a minimum testable set, then re-testing the code, may seem like "more work", but it really does minimize the effort needed to develop working code.

Learning isn't wasting time; someone have to do it before he/she is a productive programmer.

I wholeheartedly agree.  Well, actually, even productive programmers need to learn all the time, because it's not like you solve the same problem over and over again; you move on to new things.  Which is why learning through problems that interest you, is so effective, I think.

[westfw]

The 8080 looks like it should be better than the 6502

Meh.  They always seemed to be about equal in terms of real world performance and program size.  Apple/Atari vs CP/M was always ... unclear.
They're both pretty awful, and both after their subsets of "clever things" you can do.

The Atari 400/800 run the 6502 at 1.79 MHz, so a z80 would have to be at 4.37 MHz to match it on memcpy.
The BBC micro ran the 6502 at 2.0 MHz, so a z80 would have to be at 4.88 MHz to match it on memcpy.

(did you take into account the extra z80 features?)In any case, most Z80 systems WERE at least 4MHz, whereas most 6502 systems were <2MHz (and maybe video contention?  IIRC, the 6502 allowed video to be sneaky WRT shared memory, but many CP/M systems had independent video subsystems.)It's like comparing a 40MHz PIC with a 10MHz AVR (which was another often-argued comparison!)

[_Vlad_]

Well, i'm not a rocket scientist, but i think you can try to start from defining your playground.

1) What you want to program? What is your inner "engie-kid" tells you?
- Do you want to program microcontrollers?
- Maybe write OS drivers or even own OS, like good God Linus?
- Maybe just some general things like "program to do some calculations because i'm quite lazy and hate Excel"
- Maybe you want to create video games?
- Maybe you are so exited about Web-sites?

For example - my inner engie kid SHOUT LOUDLY as hell that i want to program things that do some stuff in real world. From clock to giant war robot.

2) When you hear yourself you can ask yourself "which language should i use?". Because lets be honest THERE IS NO ONE MAGIC BEST LANGUAGE. Every tool has it's own purpose.
Just try to find out what languages used in field of your interest.

For example. Microcontrollers? C. Maybe C++ (but, please. Don't go C++ madness with bare metal)
Maybe You want create small robot with some kind of raspberryPi. So your device HAVE OS. Well. It still C. It can be C++. But you can also use python.
Maybe it's some tool for automation for some process or you need to process some data in your Linux/Windows/Whatever playground on your PC? It still C. C++. Python. PUT FLAMES DOWN FOLKS! Java or C#.
Maybe it's WEB? Well it's still.. plus PHP and something that i will not say for religious reasons.

3) Start to do basic stuff. Like put "Hello World!" on your screen, or blink a LED on your board. You just need to become fammiliar with basics of your language. Dont worry, programming languages have quite easy rules compare to madness of Grammar and other stuff around any human language.

4) CALM DOWN. Yes, you will not be a rocket-scientist in 2 weeks, so you need to calm down about yourself. You are not the worst monkey on this planet and not a superman.
So main part of this step is to understand that you can do it, but there are 2 problems:
- you try to jump so high that your head will smash ISS. Find smaller project, that say to you "doooo it with mee"
- you just cant figure it out in your head. Try to find parts that are unknown to you. Engineers love to be simple. Maybe this over complicated device have really simple interface? Maybe you horrified about it, but when you will find information about it - you will find out that you need to say "Work, my little slave" and everything will be fine.

And try to figure out how to do it not in programming language. Think like you are the part of whole system. Think more abstract. Like "i need to get this number and put in this calculations".
When you understand what you need to do - it will be much easier to describe your actions in programing language.
And well.. you can sometimes visualize thing in real world. Like use boxes to store rubber ducks that you use like "data" and so on.

5) Don't cry like a Disney princess. You will get mistakes. A LOT. It's scary but it's a good sign that you are progressing.
We always fail. Failure is a opportunity to get a big "AAHHA!" when you find problem.
What difference between expert and beginner? Expert went through a lot of sh...t and failures. Expert will tell you "it's a bad idea" not because he/she is so smart, but because he/she get "Vietnam flashbacks" because they failed as you and now live with this pain and expertise.

Good Luck!