What to learn first? Coding 101
What are the five most important programming concepts?
19 Answers
Views • Upvoted by Gilles Castel, I program in Javascript and Python and Kurt Guntheroth, 35+ years wrangling bits; 20+ doing C++ development. Windows, Linux, embedded.
Concept 1:
The horrible truth: Both an insistence that everything in your project is perfect and the notion that the only important thing is "does it work?" are likewise unworkable concepts.
Concept 2:
The horrible truth: There is lots of crappy code in the world written by people who were drunk or at least it seems so to their colleagues. Deal with it.
Concept 3:
The horrible truth: No, your boss will never understand why this is taking so long unless you really take a lot of time to explain it to them, again, and they give a crap - both must be present.
Concept 4:
The horrible truth: A developer's "diligently lazy" modus operandi is both his secret weapon and his Achilles Heel. Learn to gently guide it, or die trying.
Concept 5:
The horrible truth: I don't care what mascot is on the language's site - it won't really make you fly, trust me.
—
While some of the other answers here are quite good, I don't think you can reduce programming down to five key principles. And the idea that you can might be a limiting factor to someone trying to learn or master it. There are lots of important concepts, and there are many times when it may be appropriate to break the rules. Some best practices for certain languages are considered poor practices in others. Certain language constructs that are a core concept in some languages (inheritance in C++) are absent in others (no inheritance in Go, at least not exactly).
So at the end of the day, it's a matter of judging the various factors and learning how to play the instrument and put the right notes in at the right times.
(Stuff like Second System Syndrome, Brooks’ Law, Parkinson’s Law, and many other such things are worth learning about and taking into account.)
NOTE: Images are from xkcd, one of the truly awesome sites on the interwebs.
Views • Upvoted by Till Hänisch, CS Professor and Guzman Safon, Learning to code, step by step
Most Viewed Writer in Computer Programming with 570+ answers
- Programming is, ultimately, self-taught. You can take classes to help that process along, but eventually you have to form and refine your own mental models of the language, the machine, and your program. If you're not spending time outside of class doing this work, you're memorizing trivia, not learning to program.
- The audience for computer code is other human beings, in particular, you six months from now. Be considerate to these people.
- Coding is easy, debugging is hard. Code to make debugging trivial. That can be test cases, source control, smaller and well-defined functions.... basically all of the "best practices" out there speak to this.
- A debugged, tested, and documented line of code costs on the order of $100. The best code is code that's never written because you were able to come up with a non-coding solution or reuse existing code. The second-best solution involves deleting code to get the functionality you need. Remember that as a programmer, you're hired to solve problems, not write code.
- Back when you were learning to read and write, you spent far more time reading than writing. Current pedagogy emphasizes writing code over reading code --- what was the last programming class you took where you started with an existing 1k line program and read it? As a professional, you'll be spending most of your time reading code you didn't write in order to find a bug or add a feature. It's a skill worth developing early.
- Data type – a variable (or memory location) may hold a piece of data of a particular type, say, an integer or floating point or memory pointer or string or a data structure. A variable can by statically or dynamically typed.
- Assignment – a variable can be assigned a different value, even using the previous value just held by the variable, for example, x = x + 2. This statement does not say that x is actually equal to x + 2; it says take the value of x, add 2 to it, then replacethe old value of x with the new value.
- Conditional – a means of selecting which piece of code to execute based on some condition. A conditional can be an if statement or a case (or switch) statement orpattern matching in a functional programming language.
- Data structure – the encapsulation of a set of variables that represent a logical grouping. It is a type of data that can be assigned to a variable or passed to a function. A structure is also known as a record in some languages. In object-oriented languages, a structure is a class that may have methods (or functions) associated with it.
- Function – a function (or procedure) is the encapsulation of a piece of code that allows for re-use. It may take on arguments (or parameters) and it may optionally return a value (or another function in the case of functional programming!).
Upon these five concepts, all of computer programming rests. I don't talk about loops because they don't exist in pure functional programming and otherwise can be easily simulated by using branching (or "go to" statements). Pure functional programming languages, which are uncommonly used, also don't have variable assignments because data is supposed to be immutable.
I've been working on writing my own programming language, and I asked myself this same exact question. You are thinking, what are the five most important programming concepts. From my experience, these would be my top five:
- You don't have to recode anything if you plan and design it first
- How can I make the end user experience more intuitive? (Please read this one Microsoft, Please!)
- Write in such a way so that the next programmer picking up your project can actually read and understand your code
- Document your lessons learned. As you are going to code, you'll make mistakes, learn new things, implement things a certain way. If you document your lessons that you are learning, others coming after you could benefit greatly from this. As I'm writing my programming language, I wish others would do this.
- If you are stuck on a concept, go play frisbee or golfing or something, often times the best, most clear ideas and solutions will come to my mind, once I'm not thinking too hard about a solution.
- Abstraction. Realise that programming is about computation and computation has nothing to do with electronic computers. Electronic computers are just the fastest current way to perform computations. That is what abstraction is about. Abstraction means we can be machine independent in our computations.
- Single level of Memory. Memory is single level and programmers should not be concerned with how memory is allocated or released or moving data between different levels of memory. The ideal Turing machine only had one level of infinite memory. Memory levels have nothing to do with the computational model (as above, most things we do with electronics is just implementation detail). Virtual memory realised this early and it is invisible to programmers. That means programmers should not be concerned with IO to move between memory layers - that is IO at a physical level, but by abstraction again, be concerned with problem-domain IO that gets input from a user and gives them feedback. Processor registers should also never be visible at any programming level, including machine-oriented languages such as assembler. The Burroughs B5000 computer realised this and did not have programmer-visible registers. It was also the first commercial machine with virtual memory. So a machine that blurs memory levels has been around for over 50 years. (B5000 is documented on Wikipedia, but now you can play with it for yourself MCP Express Is Here!)
- Structured programming - the basic principle is one-way-in, one-way-out of any control structure. That means no unbridled jumps or returns out of routines - a jump out of a routine should be an exception. This rigour is necessary so that small bits of code can be reasoned about and given preconditions, postconditions and invariants. Unbridled jumps are difficult to give such formality. An unbridled jump is difficult to discern what the code is doing, but jumps that implement conditionals, loops, and recursive routine calls have meaning and can be reasoned about. Similarly unbridled pointers are as bad as jumps. Pointers should be used as references with suitable semantics so that programs can be checked and there should be no null pointers.
- Static checking especially with types. As much checking as possible should be done statically by a compiler. This is not restrictive or limiting programmer freedom, but is a practical concern to keep run-time checks as few as possible so programs perform better. However, run-time checks are still needed for many cases - not only for correctness, but for security. Many bugs in C programs that are also exploited by viruses are due to C's sloppiness in this area. Some languages such as Smalltalk, Python, and Ruby are known as untyped, but actually they leave the type checking until runtime which incurs significant overhead (over and above being interpreted languages in the case of Ruby and Python). Systems should be "fail fast" - that is bugs should be caught as early as possible before wreaking havoc. Compilers catching errors are very fail fast (although not as fast as a master programmer avoiding those errors in the first place - but even master programmers make mistakes, and the best programmers realise how difficult programming is and are glad of compiler help).
- You should not rely on testing - this also applies to the latest fad of Test-Driven Design (TDD). Your tests should be implemented in the code itself as described above with preconditions, postconditions, and invariants. This is known as design by contract (DbC). About the only language where DbC is built in elegantly is Eiffel. Again DbC ensures systems are fail fast making sure problems are detected before they go into production. https://www.eiffel.org
Tony Hoare gave a wonderful talk at QCon London 2009 outlining many of these principles. This is well worth watching and taking notes.
1) Fundamentals: Control structures, variables, IO, etc.
Computers can be thought of as having three basic components: input/output, memory and computation/number-crunch
2) Abstraction and automation
If you're to graduate beyond the simplest of programs, you need to be able to manage complexity. This can be achieved through abstraction and automation. The first means looking for patterns, cases where you repeat something very similar to something you or your team-mate have already done, and extracting one piece of code that can handle both situations. E.g., you can re-use the same function to validate the from, to, CC and BCC addresses of an email. There's a handy mnemonic for this concept: Don't Repeat Yourself (DRY). The second, automation, means to try to avoid relying on human effort when you can get the machine to do a task for you. If you do it right, the task gets done much more cheaply and with less risk of error. These two concepts are the key to creating value through programming. The first time a distinct piece of work comes through, just get it done (KISS/YAGNI); the second or especially the third time you need to start abstracting and automating--you'll be seeing yet more of that kind of work. Here's a table of the trade-offs: Is It Worth the Time?
3) Input is evil
If you have the first two, you can write fairly sophisticated programs to solve your own non-trivial problems. If you want your program to be useful to others, it needs to be able to deal with imperfect, not-always-rational and sometimes even malicious users from the real world. When you write a small piece of code, try to imagine all of the ways that it can be started incorrectly and then write some guards to sound alarms when it actually does happen. This isn't entirely about information security, the sooner you can identify mistakes made by your bedraggled users, the sooner they can correct themselves and reduce the cost of the errors.
4) Analysis of Algorithms and Data Structures (Big O notation)
Performance matters. If you have a robust, sophisticated program that solves real problems but it takes a year and costs trillions of dollars to run, that will significantly diminish it's utility. In one sense that's an exaggeration, there are lots of computing problems that don't require formal training or extensive reasoning to solve. In another sense, most of those solutions would benefit from some rigor. Moreover, a certain amount of rigor is a prerequisite for many more interesting problems where good solutions could have a significant impact.
5) Don't forget to have fun
"If you love what you do, you'll never have to work for a living". That's not quite true (you'll still have to track your billable time and keep up with your email), but it's close enough :) . If programming doesn't tickle your fancy, there's probably something else that does and that industry is probably pining for someone with your talents. That's not meant to disqualify anyone from learning more about computers but it is to say that there's already a lot and always more to learn--enjoying that time is the best way to make progress.
- First you need to know the way a computer works. Its vocabulary and abstractions consist entirely of arithmetic operations, I/O, branching, looping, and modularity. Once you understand that, then you can quickly use any programming imperative or procedural language.
- Then you need to know how to break large problems into smaller problems. That is what the modularity aspect of program coding is. Making functions out of code segments is making the programming more compatible with how humans think. The away to do this most efficiently for humans, is to use an outline. That way you can easily go back and forth between large scale overviews and zooming down into details.
- Planning is far more important than people realize. People like to program so they want to do it right away. Don’t do that. You have to stop yourself, in order to force yourself to imagine the flow first in your head, then put it into an outline, and only then start to actually program.
- Documentation can not be over stressed. Humans have terrible memories, so you need to write a header for each file, reminding you what the file is for and contains. Then each function needs a header to explain the inputs, outputs, general algorithm, external dependencies and impacts, etc. One should be able to follow the program from the comments alone, without reading the code.
- Mimimize complexity. Keep everything dirt simple, if possible. If you are proud of some special chunk of code, throw it away. The last thing a programmer should do is fall for the sin of arrogance or pride. You are not coding to impress someone else, but in order that someone else can understand and maintain it. Follow the rules of complexity. Make easy function bullet proof, with the fewest depth and complexities possible. Which means only 1 return per function, and things like break and continue should only be used a as quick fix for a mistake. Anything that does not show its path complexity with indentation, such as goto, multiple returns, break, or continue, should not really be used at all.
- Organization - make your code easily readable. this will change based on the language, who you're working with, and other factors. this is not hard to do if you make it a constant practice.
- Documentation - if your code is worth anything at all to you, your employer, or whomever, it's extremely likely that down the line (when you retire, leave for another job, get fired, etc) someone else will have to work with your code. Do them a favor and document your code well, and learn how to document effectively (there are bad styles to this, too!). In addition to helping the poor saps who inherit your code, this will be extremely useful to you when you do updates, forks, and so on.
- Function Composition - learning to write functions is absolutely essential.
- Debugging - every programmer needs to be able to debug what goes wrong with their work. additionally, you need to be able to do this for other's work.
- Design - by this I mean being able to take spec from your employer, or a group you're working with, and turn it into functioning code that achieves the goals desired, in addition to being organized and well-documented.
- Primitive vs Abstraction: There is a reason why SICP starts with those 2. Ever since the beginning, all we have been doing is to build abstraction and redefine primitive. What's your primitives?
- States: I personally believe that the first, most major, and most fundamental difference between lambda calculus and real world is "the state."
- Data & Algorithm: I know, I cheat, it's 2, but I still remember Wirth beautiful equation: Program = Data + Algorithm.
- Closure vs function vs method vs procedure vs subroutine: Quiz: what's the difference between closure and function? (or, how's C 2nd class function different from Lisp and Haskell first class?) Another quiz: why the hell do different languages name their "function" differently?
- Recursion: Can't live with it (serious, just can't), can't live without it (serious, also can't). What's the best way to solve about 60% of the problems? Yay recursion. What's the best way to bend your mind the wrong way and bring tears to your eyes? Yay recursion. What's the best way introduce the most number of bugs per line of code? Yay recursion.
In 1988, when L Peter Deutsch was on my technical Board, I asked what the single most import programming concept was. He said "indirection". Since he wrote one of the first Lisp implementations (in 1963 when he was 17), I assumed he was referring to that. "No", he said "the idea is that instead of doing something, go look somewhere else and do what is there".
A successful software engineer knows and uses design patterns, actively refactors code, writes unit tests and religiously seeks simplicity. Beyond the basic methods, there are concepts that good software engineers know about. These transcend programming languages and projects – they are not design patterns, but rather broad areas that you need to be familiar with. The top 5 concept are:-
- Interfaces
- Conventions and Templates.
- Layering.
- Algorithmic Complexity.
- Security.
- You can write a recursive function (say constructor), that can generate an list of (countably?) infinite objects (say file or folders in another folder).
What they can represent ranges from abstract number fields, operators to tangible physical phenomenon . - You can to order or link or relate as you store them in a structure or database or delete* as you free the memory, these many finite (or not*) :
recursively (at once) with a function or
one by one (iteratively) with a loop .As per the given scope & order ,
or call a flat function recursively. - In the last method, it's not wise to pass by value, but you can pass by reference (a.k.a.Pointers).
- Computations of stateless functions in circuits aren't programs, Proofs are (CH correspondence).Also computer just is one of the many many things you write programs/controls for.
- Most of your work is not done by you and you rarely know how.
Plus, most of what you know or follow is some system design rationals advocated as language standards ,as implemented by the compiler or some sales pitch at some point of time or other .
*One way to delete infinite objects would be to delete their container or kill the process that is generating them at some level.
Disclaimer : I don't practice programming as a profession.
Just for fun, i'm going to choose my own that I think are most important in programming
- Algorithm - This is the foundation that all programming is based on, which without it, would cease to exist.
- Iteration - The ability to do things over and over again without mistake is what gives programming its power.
- Abstraction - Hiding of of unnecessary complexity so that the focus can be on only the core of the problem.
- Branching - Executing a part of an algorithm based on a condition.
- I'll leave that to your imagination ...
Comments
Post a Comment
Comment here.