Computational thinking = thinking about how a problem can be solved (i.e. what efficient algorithm can be constructed).
Abstraction = the removing of unnecessary details from a problem to make it simpler and separate the physical reality of the problem from the logical view.
Input = the information provided to solve a problem.
Output = the solution to a problem.
Preconditions = requirements that must be met before a subroutine is executed, to avoid crashing during runtime.
Caching = temporarily storing frequently used program instructions or data.
Examples of abstraction:
The London Tube Map 🔗: the lengths of the edges between stations are not to scale, but this is not necessary to figure out routes for a journey.
Data abstraction: programmers can use abstract data structures in high level languages (e.g. Python or Javascript) without understanding how the computer implements the structure.
Variable assignment: the programmer does not need to worry exactly where or how values are stored in memory by the computer.
This page of notes: explains the concepts of computational thinking with a reduced waffle content 🧇.
The London Tube Map
Data abstraction
Variable assignment
This page of notes
Clear documentation:
It is helpful to clearly document any preconditions, inputs and outputs of a subroutine. This ensures programmers know if any checks must be performed before calling the subroutine, for example checking if an array length is greater than 0 before applying a function. Clear documentation makes a subroutine reusable, so it can be added to a library. This means other programmers do not need to write, thoroughly test and debug new code to perform the same operation, saving time and effort.
More on caching:
Caching is done automatically by the operating system.
Web caching (the storing of recently looked at HTML pages) can be used to produce fast access to these pages, saving time and bandwidth the next time they are accessed.
Top-down design and hierachy charts:
Top-down design involves breaking down a problem into major tasks, and then further breaking down these tasks into separate subtasks. This is repeated until each subtask is simple enough to be written as a single self-contained subroutine. This makes a program easier to maintain and test, especially when accompagnied by clear documentation 🌚.
Hierarchy charts can be used to represent the structure of a program, showing how individual subroutines and modules relate to each other. Hierarchy charts have an upside-down tree structure, where modules are broken down into smaller modules until they are only a few lines of code.
Figure 1: Hierarchy chart about google games and tools (abstracted)
