From e23b4d32ad13ad1ba6fa6476edd73414fe2be2b6 Mon Sep 17 00:00:00 2001 From: Syndamia Date: Tue, 13 Dec 2022 13:18:57 +0200 Subject: [favicon] Updated favicon to new brace logo --- src/_header.html | 4 +- .../index.md | 66 +++++++++++++++++++++ src/img/favicon.jpeg | Bin 22866 -> 0 bytes src/img/favicon.png | Bin 0 -> 3078 bytes 4 files changed, 68 insertions(+), 2 deletions(-) create mode 100644 src/blog/when-a-language-forces-simple-thinking/index.md delete mode 100644 src/img/favicon.jpeg create mode 100644 src/img/favicon.png (limited to 'src') diff --git a/src/_header.html b/src/_header.html index 2554bfc..cba7fc0 100644 --- a/src/_header.html +++ b/src/_header.html @@ -5,8 +5,8 @@ - - + + diff --git a/src/blog/when-a-language-forces-simple-thinking/index.md b/src/blog/when-a-language-forces-simple-thinking/index.md new file mode 100644 index 0000000..457ce82 --- /dev/null +++ b/src/blog/when-a-language-forces-simple-thinking/index.md @@ -0,0 +1,66 @@ +# When a language forces simpler thinking + +[Article Source]() + +**Created: 11 December 2022** || **Edited: 11 December 2022** + +
+ +Recently I was reminded of the idea that a programming language can force you to think of a simpler solution to a problem by making your initial idea unecessarely difficult to implement. +This has happened a couple of times to me, so I decided to share those experiences. +By the way, all code examples are most probably incredibly unoptimal to a highly skilled programmer. I'm not, so don't get too heated! + +
+ +This year I decided to join the [2022 Advent of Code](https://adventofcode.com/2022) event. +The exercise [on the 7th day](https://adventofcode.com/2022/day/7) involved storage of a folder structure: each folder would have a name, files, and other folders in itself. +For the task itself, you don't actually need to store the files, just sum their size and the size of all files in subfolders, so a name, a number and multiple other folders. + +My solutions are written purely in [Common Lisp](TODO): a programming language where everything is represented as a list of values, where a value might be another list or a non-list value, like a number. +So I thought I could represent each folder as a list, where the first item is it's name, second is file size sum and everything else are subfolders, something like this: + +``` +Name File size sum Subfolder "e" in "a" + | | | + v v v +("/" 48381165 ("a" 94853 ("e" 584)) ("d" 24933642)) + ^ ^ + | | + Subfolder "a" in "/" Subfolder "d" in "/" +``` + +Now, after getting a file, you'll need to update the file size sum in the current folder and in the **parent** folder. +To do such a thing, you would either need to + +- iterate from "/" to that folder, find/store all folders in between, and update them, or +- store some way to access the parent folder, and just travel upwards + +I decided to go with the second option, since it seemed more elegant and potentially more efficient. +It is important to note that, for the past year and a half, I've extensively studied C++ in university, so my first though was for each folder to store some sort of pointer or reference to the memory address of the parent folder. + +Here is where Common Lisp slaps me on the wrist: you cannot do such a thing. +I mean, you can kinda store a reference to the parent folder object, but that will include the subfolder itself, resulting in an endless self-referncing loop, making the list unuseable. + +After thinking for a long long time, trying to force this idea to work, I had a revalation: what if, instead of trying to have lists in lists in ..., I just flatten everything and store indecies to parents? + +``` +Index of parent folder name (doesn't exist) + | +Name | File size sum + | | | + v v v +("/" -1 48381165 "a" 0 94853 "e" 3 584 "d" 0 24933642) + ^ ^ ^ ^ ^ ^ + | | | | | | + Name | Name | Name | + | | | +At index 0 is parent "/" Parent is "a" Parent is "/" +``` + +Now this solution worked great! With this I was able to [solve](https://gitlab.com/Syndamia/advent-of-code/-/tree/main/2022/Day07) both tasks![^day7] + +
+ + + +[^day7]: A potential improvement would be to use CLOS to store each folder as it's own object, but this worked fine and I really wanted to try a structure without CLOS. diff --git a/src/img/favicon.jpeg b/src/img/favicon.jpeg deleted file mode 100644 index 283c97f..0000000 Binary files a/src/img/favicon.jpeg and /dev/null differ diff --git a/src/img/favicon.png b/src/img/favicon.png new file mode 100644 index 0000000..01863d8 Binary files /dev/null and b/src/img/favicon.png differ -- cgit v1.3.1-23-gd82d