diff options
| author | Kumar Damani <me@kumardamani.net> | 2026-07-24 04:25:00 +0000 |
|---|---|---|
| committer | Kumar Damani <me@kumardamani.net> | 2026-07-24 04:25:40 +0000 |
| commit | a6a3f943063ce04fd0fd3030c6f67711a7943bd4 (patch) | |
| tree | f3a6c8b97f61031641c4c0e613c76e9a60a1910b /content/post/programming-as-art | |
| parent | 3a2dd35f4b6b6414ec3ba4af4e0984598ff9aa35 (diff) | |
preparing for switch to typst
Diffstat (limited to 'content/post/programming-as-art')
| -rw-r--r-- | content/post/programming-as-art/code.png | bin | 530926 -> 0 bytes | |||
| -rw-r--r-- | content/post/programming-as-art/index.md | 94 | ||||
| -rw-r--r-- | content/post/programming-as-art/math.png | bin | 398307 -> 0 bytes | |||
| -rw-r--r-- | content/post/programming-as-art/teaching.png | bin | 410632 -> 0 bytes | |||
| -rw-r--r-- | content/post/programming-as-art/wand.png | bin | 356173 -> 0 bytes |
5 files changed, 0 insertions, 94 deletions
diff --git a/content/post/programming-as-art/code.png b/content/post/programming-as-art/code.png Binary files differdeleted file mode 100644 index 30c3522..0000000 --- a/content/post/programming-as-art/code.png +++ /dev/null diff --git a/content/post/programming-as-art/index.md b/content/post/programming-as-art/index.md deleted file mode 100644 index c724e68..0000000 --- a/content/post/programming-as-art/index.md +++ /dev/null @@ -1,94 +0,0 @@ -+++ -author = "Kumar Damani" -title = "Romanticism in Programming" -date = "2022-11-29" -draft = false -description = "How programming is romantic." -tags = [ - "personal" -] -math = true -+++ - -Why there is art in programming. -<!--more--> - -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. - -```python -for _ in range(1, 1001): - print("Hello World!") -``` - -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 what we had just done earlier: - -```python -sum = 0 -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**. -In other words, the computer needs to do one-hundred ADD instructions in order to make this computation happen. - -What if the number was a million? How well would our method scale? - -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. - - - -$\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. -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 $\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 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. - -*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, 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`. - - -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 differdeleted file mode 100644 index bbdc372..0000000 --- a/content/post/programming-as-art/math.png +++ /dev/null diff --git a/content/post/programming-as-art/teaching.png b/content/post/programming-as-art/teaching.png Binary files differdeleted file mode 100644 index 9bf5dce..0000000 --- a/content/post/programming-as-art/teaching.png +++ /dev/null diff --git a/content/post/programming-as-art/wand.png b/content/post/programming-as-art/wand.png Binary files differdeleted file mode 100644 index 5eefc9c..0000000 --- a/content/post/programming-as-art/wand.png +++ /dev/null |
