diff options
Diffstat (limited to 'content/post')
| -rw-r--r-- | content/post/programming-as-art/code.png | bin | 0 -> 530926 bytes | |||
| -rw-r--r-- | content/post/programming-as-art/index.md | 89 | ||||
| -rw-r--r-- | content/post/programming-as-art/math.png | bin | 0 -> 398307 bytes | |||
| -rw-r--r-- | content/post/programming-as-art/teaching.png | bin | 0 -> 410632 bytes | |||
| -rw-r--r-- | content/post/programming-as-art/wand.png | bin | 0 -> 356173 bytes |
5 files changed, 58 insertions, 31 deletions
diff --git a/content/post/programming-as-art/code.png b/content/post/programming-as-art/code.png Binary files differnew file mode 100644 index 0000000..30c3522 --- /dev/null +++ b/content/post/programming-as-art/code.png diff --git a/content/post/programming-as-art/index.md b/content/post/programming-as-art/index.md index 1be9cb5..96b1267 100644 --- a/content/post/programming-as-art/index.md +++ b/content/post/programming-as-art/index.md @@ -2,66 +2,93 @@ author = "Kumar Damani" title = "Romanticism in Programming" date = "2022-11-29" -draft = true +draft = false description = "How programming is romantic." tags = [ "personal" ] +math = true +++ Why there is art in programming. <!--more--> -During the early days as a CS student we were learning about loops, -and saw "Hello World!" getting printed out to the console N-thousands of times -in just 3 functional lines of code. +During my early days as a CS student, one of the first mind-blowing moments was +watching `Hello World!` getting printed out to the console thousands of times +in just two functional lines of code. -for 1 to 1000: - print "Hello World!" +```python +for _ in range(1, 1001): + print("Hello World!") +``` -This felt like having the Elder Wand at the time. +At the time it felt like having the [Elder Wand](https://harry-potter-compendium.fandom.com/wiki/Elder_Wand). + -But there was more to our lesson. -The TA then asks us to put our newly found power to use by computing the -sum of 1 to 100. Of course, it was a natural application of our topic: +But there was more to our lesson. +The TA then asks us to put our newly found power to use by computing the +sum of 1 to 100. Of course, it was a natural application of what we had just done earlier: +```python sum = 0 -for i in 1 to 100: +for i in range(1, 100+1): sum = sum + i +``` -Sure enough we saw the answer 5050 in the console. -But then the TA reminds us that we are making our computers work too hard. -It needs to do 100 basic ADD instructions in order to make this computation happen. +Sure enough we saw the answer `5050` in the console. +But then the TA reminds us that we are making our computers **work too hard**. +In other words, the computer needs to do one-hundred ADD instructions in order to make this computation happen. What if it the number was a million? How well would our method scale? -Well then it would take a million basic ADD instructions. -Seems like this scales with "linearly" with the input size. -Later we would formalize this to O(n). + +Well then it would take a million ADD instructions. +We call this scaling *linearly* with the input size. +Later we would formalize this to $\mathcal{O}(n)$ (pronounced: *Big Oh of N*). The TA hinted that there is a better way, and that we already know of the better way in math. -sum = n(n+1)/2 + + +$\displaystyle S_n = \sum\limits_{i=1}^n i = 1 + 2 + ... + n = \frac{n (n + 1)}{2}$ With this we are no longer using loops, but a known mathematical fact about sequences. -This one-liner solves our problem with 3 basic (ADD, MULTIPLY, DIVIDE) instructions. -It does not depend on the size of the input like our previous solution, thus -no matter the input, it always takes 3 instructions to compute! +If you don't belive me, see the [proof](https://letstalkscience.ca/educational-resources/backgrounders/gauss-summation). + +Written as code: +```python +sum = n (n + 1) / 2 +``` +This one-liner solves our problem with just 3 (ADD, MULTIPLY, DIVIDE) instructions. +Crucially, it does not depend on the size of the input like our previous solution, thus +**no matter the input, it always takes 3 instructions to compute!** This is a HUGE win! -Later we would formalize this to O(1), or "constant" scaling. -> IRL the complier would optimize the loop solution such that it does not take N instructions -but for the purposes of learning we were not allowed to depend on that. + + +Later we would formalize this to $\mathcal{O}(1)$, or *constant* scaling. + +> Yes, yes I know IRL the complier would optimize the loop solution +such that it does not take N instructions but for the purposes of +learning we were not allowed to depend on that. Looking back at it now, -Both solutions are equally correct, and modern compilers would optimize the first solution -in the final instructions such that any performance differences would be negligible. +both solutions are equally correct, and modern compilers would optimize the first solution +in the final instructions sent to the cpu, such that any performance differences would be negligible. +In other words, the computer wouldn't acutally be *working so hard*. + Objectively, the first solution is more readable, and friendly to a new observer than the second. -Yet I am still so drawn to the second solution. + +*Why then am I still so drawn to the second solution?* The first solution reminds me of the saying "to a hammer, eveything looks like a nail". Its a brute force approach. -In comparison, with the second solution, using the exact tool for our particular problem -somehow feels personalized and even "romantic". +In comparison, the second solution is using the exact tool for our particular problem. +It somehow feels personalized and dare I say *romantic*. + +When I reflect on moments like this, it reminds me that there is emergent elegance and beauty +even in the seemingly arbitrary sequence of symbols that is `code`. + -Most often in programming, we don't have such clear optimizations. It often comes down to -using the correct data-structures for the correct situation, and elegance emerges as a result. +Programming is not quite as *objective* as people would have you believe. +There are trade-offs to each solution, and which solution you prefer relect on the trade-offs +you are willing to accept, which varies by the observer: much like *art*. diff --git a/content/post/programming-as-art/math.png b/content/post/programming-as-art/math.png Binary files differnew file mode 100644 index 0000000..bbdc372 --- /dev/null +++ b/content/post/programming-as-art/math.png diff --git a/content/post/programming-as-art/teaching.png b/content/post/programming-as-art/teaching.png Binary files differnew file mode 100644 index 0000000..9bf5dce --- /dev/null +++ b/content/post/programming-as-art/teaching.png diff --git a/content/post/programming-as-art/wand.png b/content/post/programming-as-art/wand.png Binary files differnew file mode 100644 index 0000000..5eefc9c --- /dev/null +++ b/content/post/programming-as-art/wand.png |
