Since I have covered the basic clojure concepts in the previous book, this is acting as a nice revision of the concepts I have read about.
Some notes from the reading:
- A function is said to be “referentially transparent” if it fits in the
pure substitution model of evaluation that we have discussed.
- That is, a call to a function can always be replaced with the value to
which it evaluates without having any other effect.
After reading through all the chapters of this book, I have a fair understanding of what constitutes a Clojure program. I understand the basic data-types, what writing a macro entails, the syntax in various contexts (like de-referencing an atom, unquoting a binding, etc.).
Topics that will require more work:
- Collections: seq, lazy seq, etc.
- Standard library functions: I understand some basic functions but knowing what else is part of the core library will make a big difference
- Just writing programs in clojure will also help gain some confidence. To this end, this video suggested writing a 2d game. The rationale is most of us have played some kind of 2d games in the past and already know how they operate, so we are clear on the requirement. This means all that we have to do is concentrate on how to do it in clojure.
- More clojurescript? I primarily write web-apps for a living and this might give me something to compare.
- Solve some exercises on 4clojure and exercism
- Read another book?
I think of abstractions as named collections of operations. If you can perform all of an abstraction’s operations on an object, then that object is an instance of the abstraction. I think this way even outside of programming. For example, the battery abstraction includes the operation “connect a conducting medium to its anode and cathode,” and the operation’s output is electrical current. It doesn’t matter if the battery is made out of lithium or out of potatoes. It’s a battery as long as it responds to the set of operations that define battery.https://www.braveclojure.com/core-functions-in-depth/
Day 3 of reading the book.
In programming, indirection is a generic term for the mechanisms a language employs so that one name can have multiple, related meanings.
Polymorphism is one way that Clojure provides indirection. I don’t want to get lost in the details, but basically, polymorphic functions dispatch to different function bodies based on the type of the argument supplied. (It’s not so different from how multiple-arity functions dispatch to different function bodies based on the number of arguments you provide.)
Came across an aspect I didn’t think about before.
Consider a computer system which gives users control over an action. Action could be:
- trivial changing background color of a webpage (low-risk action)
- dropping databases or VMs (high-risk action).
The point of view I have been aware of until now is: password breach to a low-risk system isn’t particularly dangerous. But it’s not dangerous for the application. There is another POV to consider — that of the user himself.
Say we’re storing order history of the logged in user (a low risk data), which might contain his address (a medium risk data). What if the person who got this information was the abusive ex? It becomes a targeted attack for the user, which makes low or medium risk application impact a high risk breach for the user.
So consider the impact of an access breach from both perspectives — the application and the user when making such categorizations.