1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
Title: Hiding the complexity
Date: 2019-10-27
Category:
Tags:
Slug: hiding-the-complexity
Lang: en
Summary:
Inspired by scheme share my thoughts about the complexity and how it's
being hidden by our tools and how does that affect us as creators and
engineers.
I've been recently playing with Scheme, reading R⁷RS and so on and I found
something really interesting: Even with its high level of abstraction, it
doesn't hide the complexity and makes you pay attention to it.
That's extremely powerful and interesting.
It's even more interesting if you think about the fact that Scheme can be
implemented from scratch in an acceptable amount of time by a couple of hands.
You don't need to be a big corporation or a big group of developers coding for
years to implement it.
It's **simple** but it doesn't hide the complexity of the implementation.
That's a really powerful balance.
But both points are too much to leave them here without playing with them
separately so let's try to understand why both of the points are[^1]
fundamental.
[^1]: In my opinion, of course. This is *my* blog.
## <del>Hidden</del> Latent complexity
You can create the best programming language in the world but the
complexity of the programming can't be eliminated because the user of the
language will be, actually, programming. So, you can take two approaches here:
- Expose the **intrinsic** complexity of programming.
- Make it look as complexity doesn't exist. Which means hiding the complexity
as much as you can under layers of abstraction.
Most of modern programming languages go for the second option. But not only
programming languages, also operating systems, computers themselves and many
areas more. Which is not specially bad in general, but it's dangerous when you
need control.
Most of the times where complexity is hidden by design, it's just *latent
complexity*. It's harder to reach by the user, so the user scope of things they
can do is reduced (and with it the their ability to decide with a high level
of detail) but the complexity is still there, happening without being noticed,
under the surface and being impossible to correct if something goes wrong.
Think about your cellphone. You can't open it, change the battery, change it's
software, change... *anything*. Because it's hard to do and "*people don't need
to know about that*". But finally, what you have is a phone that is impossible
to repair if something goes wrong or impossible to change if you want it to do
something that is not the default behaviour.
It is a problem (some people is fixing trying to fix, by the way) but it's not
a problem for *everyone* because *everyone* doesn't need to have that level of
complexity exposed. But they should have the right to see it if they wanted to.
## Exposed complexity
As engineers working on technology, we should be demanding for the complexity
of things being exposed, more than running away from it.
As engineers we are supposed to want to know how stuff works!
In the case of programming languages, I want to control what the program does
and I be aware of what I'm doing and which decisions I'm taking.
When complexity is exposed you are reminded of the importance of every choice
you make. It's not something that happens: you have to think about it.
> In Scheme: List vs Vectors. Which one is better? Why have both? Why not use
> use one all the time?
It's reminding you what do you have under the hood, even if you aren't
implementing it yourself. That way you don't forget about *your job*.
## Simplicity
Simplicity means that there's no unneeded complexity. It doesn't mean that
complexity is hidden. We tend to confuse both terms too often.
Scheme is simple, because its core is small and it's based in few concepts.
Being simple means that concepts are clear and consistent and have few or none
exceptions.
Other programming languages use the same concepts that scheme does but they are
not clearly stated so you can't rely on them for your understanding of a
language. Scope in JavaScript (for instance) is often explained as a thing
related with curly brackets' position while hiding the fact that it's a lexical
scope. Watching engineers prefer a silly trick than an academical fact is
unsatisfying[^2].
[^2]: And insulting, I'd say.
In many platforms abstraction layers are added until the internals are hidden
or blurred. In this case, complexity is directly hidden by implementation, more
than by users themselves running away from it.
Some would ask: "Who cares about the details?" [^3] And it's perfectly fine to
think that at some point but when it comes to choosing the right tool to the
right problem, performance and fine tunning, you'd really like to know how they
are implemented because implementation is what makes some operations be faster
or more accurate than others. And, probably more important than that, being
aware about how stuff is implemented make us independent enough to change the
implementation if we want, **which is the base of free software**.
[^3]: TLDR: *You, as an engineer, should*.
When your tools hide reality from you for long enough, you start to forget that
the reality still exists even if you are not watching it and you start
acting like it wasn't there.
## Assembly then... Right?
Don't get me wrong. I'm not against simplification or making our job easier.
Scheme, is a really high-level language. **Abstraction is good**.
Accidental self-lobotomy is not that good.
> NOTE:
> This blogpost was triggered by this talk where a musician talks about
> chiptune music and says how making chiptune music made him a better
> guitarist. It has some good points about constraints and complexity.
>
> <https://youtu.be/_7k25pwNbj8>
|
