Deploy bendiksolheim/bendik.dev to bendiksolheim/bendik.dev:gh-pages

bendiksolheim · Oct 19, 2023 · 5fb1f59 · 5fb1f59
commit 5fb1f59
Show file tree

Hide file tree

Showing 19 changed files with 1,480 additions and 0 deletions.
diff --git a/404.html b/404.html
@@ -0,0 +1 @@
+<!doctype html><title>404 Not Found</title><h1>404 Not Found</h1>
diff --git a/CNAME b/CNAME
@@ -0,0 +1 @@
+www.bendik.dev
diff --git a/atom.xml b/atom.xml
diff --git a/elasticlunr.min.js b/elasticlunr.min.js
diff --git a/index.html b/index.html
@@ -0,0 +1,3 @@
+<!doctype html><html><head><title>
+bendik.dev
+</title><meta charset=utf-8><meta content="width=device-width,initial-scale=1" name=viewport><link href=https://www.bendik.dev/tufte-dark.css rel=stylesheet><script data-domain=bendik.dev defer src=https://plausible.io/js/script.pageview-props.js></script><script>plausible('pageview',{props:{language:navigator.language}})</script><body><article><h1>Bendik Solheim</h1><p class=subtitle>Predictable thoughts about software development<section><h2><a href=https://www.bendik.dev/posts/react-et-hjertesukk/>React – et hjertesukk</a></h2><span>December 19, 2022 – 3 minute read time</span><p><em>(This blog post is in norwegian, sorry about that)</em><p>Ahh, React. Min gode venn gjennom mange år. Jeg skal være ærlig: forholdet vårt starta litt turbulent. Jeg var usikker på om det å blande HTML inn i Javascripten egentlig var noen god idé. Det tok faktisk et par år før du klarte å overbevise meg! Men du var heldigvis tålmodig. For det som starta som en skepsis viste seg å etter hvert til å bli til en aldri så liten forelskelse! Ohh boy!</section><section><h2><a href=https://www.bendik.dev/posts/honest-functions/>(Dis)Honest Functions</a></h2><span>March 3, 2021 – 8 minute read time</span><p>After a recent debugging session, discovering I had once again been the victim of a dishonest function signature, I was... Well, let’s just say I was unimpressed. Two thoughts popped up in my head – the first one was «ahh.. this thing again..», and the second was «wait, why is this still even a thing?». It left me in a state of frustration.</section><section><h2><a href=https://www.bendik.dev/posts/java-version-management-on-macos/>Java Version Management on macOS</a></h2><span>January 30, 2021 – 5 minute read time</span><p>With the increased frequency of Java releases handling multiple versions on a single machine is more and more relevant. Solutions already exists, such as the widely used <a href=https://www.jenv.be>jenv</a> – my goto tool for a long time. For a number of reasons, I recently decided to throw it out of my system and build a solution myself. The result is a few small functions which handles most of my needs.</section><section><h2><a href=https://www.bendik.dev/posts/functional-ts-with-fp-ts/>Functional TypeScript with fp-ts</a></h2><span>December 12, 2020 – 10 minute read time</span><p>I have a confession to make.<p>I actually enjoy JavaScript.</section><section><h2><a href=https://www.bendik.dev/posts/characteristics-of-the-perfect-programming-language/>Characteristics of the Perfect Programming Language</a></h2><span>December 2, 2020 – 4 minute read time</span><p>This is an opinionated post. Consider yourself warned. You will probably disagree with at least some of it, and that is completely fine. The important part is the thought process – don’t just read through it and agree or disagree, think about what you agree or disagree with and why. Becoming aware of these things is valuable: once you become aware of why you dislike something, you can start doing something about it.</section><section><h2><a href=https://www.bendik.dev/posts/immutable-by-default/>Immutable by Default</a></h2><span>December 3, 2019 – 5 minute read time</span><p>You should always strive to make, and make use of, immutable data structures. Even if your domain is inherently mutable (like most domains, really), there are quite a few pitfalls that can give you headaches later on if you also use mutable data structures. Many of them are avoidable simply by making it harder to accidentally modify data.</section></article>
diff --git a/posts/characteristics-of-the-perfect-programming-language/index.html b/posts/characteristics-of-the-perfect-programming-language/index.html
@@ -0,0 +1,3 @@
+<!doctype html><html><head><title>
+Characteristics of the Perfect Programming Language | www.bendik.dev
+</title><meta charset=utf-8><meta content="width=device-width,initial-scale=1" name=viewport><link href=https://www.bendik.dev/tufte-dark.css rel=stylesheet><script data-domain=bendik.dev defer src=https://plausible.io/js/script.pageview-props.js></script><script>plausible('pageview',{props:{language:navigator.language}})</script><body><article><div class=page-back><a href=/>← Back</a></div><h1>Characteristics of the Perfect Programming Language</h1><p class=subtitle>December 2, 2020 – 4 minute read<section><p>This is an opinionated post. Consider yourself warned. You will probably disagree with at least some of it, and that is completely fine. The important part is the thought process – don’t just read through it and agree or disagree, think about what you agree or disagree with and why. Becoming aware of these things is valuable: once you become aware of why you dislike something, you can start doing something about it.</p><span id=continue-reading></span><p>Over the years, I have noticed there is a small set of features I value more than others in programming languages. These features allow me to express myself in a concise and clear manner, makes my code more readable, and minimizes the amounts of errors I make. They are not "magical" in any way. Far from it. Rather, they are more.. fundamental aspects of the progamming language itself. Let’s dive in!<h2 id=expressive-type-system>Expressive type system</h2><p>Types help me reason. Explicitly typed code communicates intent better, and is easier to navigate without losing context completely. Type systems comes in a variety of flavors, ranging from the most simple ones to more advanced systems with gradual typing, dependent types, type classes, and so on. Although I personally prefer more advanced ones, I believe this is more of a subjective topic. And of less importance, really. The main benefit of type systems exists in even the simplest ones: increased safety and readability. Remember: the compiler is your friend – the more it can verify, the better!<h2 id=type-inference>Type inference</h2><p>I was a bit unsure if this point had its place in this blog post. On one hand, I feel its more of a convenience feature than strictly neccessary. On the other, an overly chatty and boilerplaty type system can cause more harm than good – if your business logic drowns in types, it’s too far in the wrong direction. Java, around the 1.5 era, is an example of this. In addition, type inference itself is a a double-egded sword. If the compiler inferes a different type than what you would have thought, it can be quite hard to spot where the actual error is. This is the reason some languages and communities define best practices around type inference, like being explicit in function signatures. Anyway. When I find that perfect spot between explicit types and inferred types, it just makes me really happy.<h2 id=algebraic-data-types>Algebraic data types</h2><p>I remember the first time I enountered sum types. My first response was «but.. Isn’t this just some kind of enums?». I can kind of see why I thought that, but I feel this is a limiting way of approaching them. Where enums helps me limit valid values, algebraic data types is so much more. It enables me to model my domain and state in a precise and correct manner, and makes illegal states «impossible». This didn’t really become clear to me until I went back to Java. I find modelling without them cumbersome and hard, and sometimes even end up in situations where I can’t avoid impossible states. Few things are more confusing than finding the comment «this can’t happen» in a branch of someones code.<h2 id=first-class-functions>First class functions</h2><p>I don’t even understand why this is subject to discussion anymore, but functions should be treated just like any other value <sup class=footnote-reference><a href=#1>1</a></sup> in a programming language. Returning functions and accepting functions as parameters is a fundamental feature to create abstractions and solve problems with composition. This just isn’t up for debate – I would take first class functions over any other feature any day of the week!<h2 id=functional-programming>Functional programming</h2><p>Functional programming taught me to value these features. Sure, you will find imperative languages with these features as well, but they never feel like a core feature of the language. Even Java comes with some sort of primitive type inference these days, but it mostly feels tacked onto the language.<p>With some notable exceptions (looking at you, LISP), these are core features in all functional programming languages I use. They make my day better, so I would think hard before adopting a language without them these days.<p>Which feature do you miss or disagree with the most?<hr><p><sup class=footnote-reference><a href=#1>1</a></sup> <em>I use the term "value" loosely here. I don’t mean to debate value types, reference types, and pass by value or reference. Those are implementation details. The point is to see what advantages you get when a language treats simple values and functions the same.</em></section></article>