For Of.. or was it For In?
We learned a variety of new things this week in class. Things like more higher order functions and sorting algorithms. The thing I feel that I found a better grasp of was the use of For Of and For In loops. These loops are fairly simple in their syntax, but seem to be constantly mixed up. Even by seasoned developers. So let me break them down a little. The For..Of loop is designed to loop through an array and perform some task on each indexed item. This is really helpful when each item needs to have the same task done to it. But it isn’t helpful when you need the specific index number. Although there are ways to get that index, a standard for loop could be more helpful. The For..In loop, on the other hand, loops through an object to before some task. I can take a variable for the key/value pairs and search through the object to find what you need. And an array of objects can use both loops nested together. These two loops are very similar in syntax but are not interchangeable. And they are very often mixed up in regards to which one does what. I’ve been trying to use a mental mantra to help me remember whenever I need use one or both. An array is made up OF items. While an object has keys IN it. An array OF items. Keys IN objects. Of. In. This helps me remember, hopefully it helps you too.
Mutability and Immutability are interesting things with JavaScript. Often made by the difference of using Let or Const when naming a variable. But what does that even mean? Well, mutability means that the value or contents of a variable is able to be changed by another function or declaration. If const x = 6; then it stays that way. Const stands for constant and the value of x can’t be changed later. If you later say that x=7 it will thrown an error since you can’t change x. But let x = 6; is another story. It basically says “Let the variable equal this value, for now.” Immutability has it’s advantages in several ways. One way is that when a variable or function is declared, it stays that way. And it can be called over and over without changing. Even though a const function can have mutable variables within, the function itself will stay the same. One drawback to this is the fact that these values can’t be changed. Even though I just said that was a pro of them, it can also be a con in some cases. Perhaps over the course of writing your code, that variable needs to change. At that point, you must declare a new variable with the same value that you can mutate. Now you have two variables where one could have worked. This is mostly semantic. If done right, the code could be refactored into using only one. But depending on the length and complexity of the code, and the complexity of the variable, this could take some work.
The divide and conquer algorithm is a new concept to me as I write this. And algorithms in general are somewhere I still need more work to wrap my head around. But I have a general idea of how the divide and conquer works. Simply put, it breaks a problem down into smaller, easier to solve parts. Then once it solves those, it combines those results into a final solution. In theory, it’s a simple idea. But in execution, I will need to work with it for a bit to find a better understanding.
The sort algorithms are not as complex of ideas as the divide and conquer. But like I said, I’m still trying to figure them out. But they do all work to arrange a set of data into ascending or descending order. Insertion sort, to the best of my knowledge will take a value out of a list, and reinsert it where it fits best, then do the same with the next number, and so on until the list is sorted.
Recursive algorithms have 3 laws. This is right up Iasac Asimov’s alley, sort of. The three laws state that (1) the algorithm must have a base case. Or a case where the algorithm will stop being recursive. (2) It must change its state and move towards the base case. It needs something to happen that allows the code to move towards completion. And (3) it must call itself recursively. The algorithm must call upon itself to keep running until in can reach the base case that ends it. As long as these three laws are followed, it will allow for algorithms that avoid infinite loops. An algorithm needs an end. It needs a point that it can say “finished”. But if any of these laws are skipped, it won’t find that point.
