aboutsummaryrefslogtreecommitdiff
path: root/content/post/programming-as-art
diff options
context:
space:
mode:
authorKumar Damani <me@kumardamani.net>2026-07-24 04:25:00 +0000
committerKumar Damani <me@kumardamani.net>2026-07-24 04:25:40 +0000
commita6a3f943063ce04fd0fd3030c6f67711a7943bd4 (patch)
treef3a6c8b97f61031641c4c0e613c76e9a60a1910b /content/post/programming-as-art
parent3a2dd35f4b6b6414ec3ba4af4e0984598ff9aa35 (diff)
preparing for switch to typst
Diffstat (limited to 'content/post/programming-as-art')
-rw-r--r--content/post/programming-as-art/code.pngbin530926 -> 0 bytes
-rw-r--r--content/post/programming-as-art/index.md94
-rw-r--r--content/post/programming-as-art/math.pngbin398307 -> 0 bytes
-rw-r--r--content/post/programming-as-art/teaching.pngbin410632 -> 0 bytes
-rw-r--r--content/post/programming-as-art/wand.pngbin356173 -> 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
deleted file mode 100644
index 30c3522..0000000
--- a/content/post/programming-as-art/code.png
+++ /dev/null
Binary files differ
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).
-![Dumbledore with Elder Wand pic](wand.png)
-
-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.
-
-![Teaching meme](teaching.png)
-
-$\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!
-
-![Math meme](math.png)
-
-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`.
-![The Matrix code going by image](code.png)
-
-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
deleted file mode 100644
index bbdc372..0000000
--- a/content/post/programming-as-art/math.png
+++ /dev/null
Binary files differ
diff --git a/content/post/programming-as-art/teaching.png b/content/post/programming-as-art/teaching.png
deleted file mode 100644
index 9bf5dce..0000000
--- a/content/post/programming-as-art/teaching.png
+++ /dev/null
Binary files differ
diff --git a/content/post/programming-as-art/wand.png b/content/post/programming-as-art/wand.png
deleted file mode 100644
index 5eefc9c..0000000
--- a/content/post/programming-as-art/wand.png
+++ /dev/null
Binary files differ