It is a well-known engineering principle, that you should always use the weakest technology capable of solving your problem - the weakest technology is likely the cheapest, easiest to maintain, extend or replace and there are no sane arguments for using anything else.
The main problem with this principle is marketing - few people would sell you a 10$ product that can solve your problem for ever, when they can sell you a 1000$ product, with 10$ per month maintenance cost, that will become obsolete after 10 years. If you listen to the “experts” you would likely end up not with the simplest, but with the most advanced technology.
And with software the situation is particularly bad, because the simplest technologies often cost zero, and so they have zero marketing budget. And since nobody would be benefiting from convincing you to use something that does not cost anything, nobody is actively selling those. In this post, I will try to fill that gap by reviewing some technologies for web publishing that are based on plain text and putting forward their benefits. Read on to understand why and how you should write everything you write in plain text files and self-publish them on your own website.
Read More
The if statement (or if expression) is the cornerstone of every modern programming language - it is so pervasive that we rarely think about how exactly should we use it, or how it is meant to be used. But despite its popularity, if wasn’t always there, and it wasn’t as pervasive as nowadays, so its role is, I’d argue, still somewhat misunderstood. So in this article, I will examine some mistakes that we can easily avoid in order to improve on our code.
Read More
I really am not the best person to author such an article (I am not that into programming anymore, and I never was a real expert in it), however I am doing it, because I have been waiting for someone else to write it for years and kept noticing the following phenomena:
- People who understand functional programming, cannot make themselves understood by the general (programming) public.
- Many of the people who are able to make themselves understood by the public, don’t understand enough for them to be worth listening (all functional programming articles that are understandable don’t go much farther than “You should use pure functions, man!”.
Roughly the same thing has been called “the curse of the monad” by some people: “Once you understand it, you lose the ability to explain it”. It is clear now that monads are not something you get in an afternoon, but I think you can get some idea of what FP (functional programming) is. Or, you know, in a year or so. But in order to spend that time you need some motivation. You probably need someone to tell you why exactly do you need to know about FP? Why is it awesome, so to say. And so my article begins.
Read More
The title of this post sounds like a school essay and this is because I like it like that. This is, after all yet another post from yet another vim evangelist. But everything I say is true.
At times when software tools come and go faster than we can get used to them, vim is here for us to admire and to learn from. It is elegant and polished in a way that few software tools are. And oh, it can do so much. But let’s not get ahead of ourselves.
Read More
“Oh, in Haskell this app is just a one-liner!”
The one-liner:
app a b c d e= runMonadT <(@)> ( (LiftValue a b c) *!* stop) . \a -> d(a) $ e
I think that bash is so popular because it is so terrible language and hard to work with, that every time you make something work you feel like a wizard and your dopamine is to the roof
Searching for a good way to say it, but basically, those who don’t understand Unix indeed are doomed to reinvent it. However, those who don’t understand Lambda are doomed to just always remain half-blind when it comes to programming, just roaming and not knowing what they are missing.
“May you become an expert in time zones!”
Ancient programmers curse
Companies’ pages:
“We love open source!”
Companies’ Github profiles:
“5 followers”
People like to be reminded:
“data never speak for themselves”
But of course it doesn’t, after all, the objects of the dataset, the phenomena being investigated etc. are all defined using some theory, never forget that i.e. you have the theories even before you have the data (how can it speak of itself then?)
I arranged my desktops, inspired by the workspace organization method in “Deep Work”: to entryway, preparation area and core workspace.
The idea: have 3 virtual desktops, or three computers each of which corresponds to a level of focus in your work.
Desktop 1 - Entryway - can serve as an area for transitioning from the outside world to your work environment. Here we should store all distracting windows (social media, porn etc.), as well as administrative stuff, like issue trackers.
Desktop 2 - Preparation Area: Should be arranged to prepare your mind for deep work. It might include some relevant resources (books, specialized message boards, inspirational galleries), as well as some experimental projects.
Desktop 3 - Core Workspace: This space should be dedicated solely to deep work. It should be free from any potential distractions and have just the tools you use (consoles, IDE’s drawing Software, you know what you use)
The idea is to only go from one desktop to the one next to it, without fast context switches.
Most people, after owning a laptop, or another piece of tech for more than 2 years:
“Yeah, this things is getting outdated, doesn’t support XYZ, I guess it’s time for a replacement…”
Me, after my 10-year laptop fails:
“THIS IS BULLSHIT!”
Engineering protip: Know the difference between critical and non-critical functionalities of your product, e. g. between why your product MUST do and why it SHOULD e.g. for cars engines are critical, stereos are non-critical.
Critical parts of the product should be designed to be simple and durable. Non-critical parts should be cheap and easy to replace and remove. The failure of non-critical stuff should never affect critical stuff.
Critical parts are your “core business”, as business people say — they give you competitive advantage.
Dependent types are super confusing, but at the same time they feel easier than normal ones.
I guess that makes sense for every advanced concept - as a concept wouldn’t exist if it isn’t making things easier when you finally get it.
I think that they are hard to learn because we consider them as something fancy, but they actually are the simpler thing, and it’s normal, first-order types that are weird.
With first-order types, you have two things — types and values, dependent types there is only one thing, type e.g. “Number” is a type of “Set” in the same way that 1 is a type of “Number”.
If done right, a federated network like Mastodon would be much more reliable and cheap to run than a centralized one: when the scale is big, the network has to be federated under the hood anyways (i.e. you have to have several caches in different locations, several database nodes that copy data from one to the other, several moderation teams etc.) and so the network that is federated by design has many advantages over the one that pretends to be centralized.
You can understand a log about different programming paradigms from the way in which they implement 1 + 1:
- In imperative languages, such as C, it is just
1 + 1 - arithmetics is build in.
- In object-oriented languages like Smalltalk and Ruby, it is
1.+(1) - plus is a method of the object 1.
- In functional languages, like Haskell, it is actually
+(1, 1) - plus is an inflix operator, which is actually a function.
In Lisp you just cannot write (+ 1 1) directly.
Finally got the final list of the three hard things in computer science:
- Naming artifacts
-
-
- Concurrent
- Off by one errors.
data processing
