In my previous job, I've worked on a project that requires disassembling large amounts of x86/amd64 instructions (several billion instructions each running is very common). I've found also that Zydis is much faster than Capstone.
I will get down-vote for sure but it's trivial this book and also the series "category theory for programmers". It's actually not very far from the content of several first pages of any book on set theory or logics.
I find the ubiquitous idea is that "category theory" is more prestigous than "set theory", and some programmers, instead of seriously learning mathematics, think that learning category theory would fill up their lack of knowledge (in mathematics). It's quite contrary since category theory alone (i.e. without context) is trivial.
Let's be honest: read this book and the series of the author, and try to use the acquired knowledge to prove some (even simple) mathematical theorems.
> and some programmers, instead of seriously learning mathematics, think that learning category theory would fill up their lack of knowledge (in mathematics). It's quite contrary since category theory alone (i.e. without context) is trivial.
High applauds for this part.
Category Theory, by design, attempts to be more general, more basic and more abstract.
1. You cannot learn the more abstract stuff first. You have to learn the special cases first- i.e. Calculus, Set Theory, Analysis, etc. You do not start studying Physics with General Relaitivity or Quantum Mechanics because they are more general. You learn them after long years of studuying special Physics of fluid motion, Newton's Law. One should not think that one can simply get a "shortcut" to the most general thing there is, without learning the special cases.
2. A lot of more general sciences are indeed special cases. When you are asked to find the set of points in a certain domain where the derivative of a function cannot be found, you are not actually doing Set Theory. You are doing Calculus.
I believe that the notion one can learn the abstract cases just by studying the abstract science is laughably wrong. They better study Theology. Shouting out "Monad is a monoid in a category of endofunctors" doesn’t teach you Math.
However, let me end this comment and rant with a book suggestion.
Please read "Seven Sketches of Composionality" if are looking for books to learn Category Theory.
The author’s objective is to teach the category theoretical concepts that get used in FP. This is particularly important in Haskell since it uses some of these concepts (functors, applicatives, monads, etc.) as design patterns.
He’s objective has never been for the reader to learn this and apply it to prove math theorems.
Both set and category theory are foundational systems for mathematics (or attempting to be). Category theory being newer is trending and probably why you get the sense that it’s considered more prestigious. But I’ve never heard anyone claim it is more prestigious.
I actually criticise the illusion (that the book and the series bring) that the category theory is "the ultimate source" of motivation in FP languages.
On one hand, it's direct (and very natural) to reproduce some categorical structures in a FP language (e.g. Haskell, ML) since such a language is around functions and values. I doubt that such categorical structures should be considered patterns.
On other hand, Haskell or ML does not come from the category theory, it comes from PCF as a language which is created to make program correctness proving is "easy".
I dont want to mean someone using this book to prove mathematical theorems, I just want to say that it's superficial (about both category theory and computer science), and does not bring sufficient knowledge upon that we can build nontrivial results.
Agree. It's difficult to guess the definition of "exist" while reading it. The phrase
> ...accepting the existence of the reals means that there are numbers that exist but can never be described ...we can never interact with these numbers even conceptually
is also full of vagueness: what is "be described"/"interact"?
Yes, I think metaphors are used to put the formal definition of computation monads into some concrete situations (for getting intuition). But "too many bad metaphors" will make monads something mysterious, incomprehensible.
The definition of computation monads (in sense of Moggy) is simple, but not trivial. It's deep since it generalizes many computation "phenomena": side effects, exceptions, etc.
Conceptually, a "pure" function is something as `A -> B`, so all information about its internal (e.g. side effects) lost: we put something of type A but we can only observe a result of type B.
The idea of computation monads is to attach the result type of the function with a "constructor" T, then the type T B is used to "restore" (or to reason about) the lost information.
In composing such functions, T X (for some result type X) is all information we need, then this explains naturally the third rule of the Kleisli triple `f: A -> T B; g: B -> T C`: A -> T C
I fairly agree with this. I still wonder how the author visualizes irrational numbers, exponential functions, etc. and more importantly, proves some (even simple) theorems with this kind of visualization.
I have a similar impression when reading posts elsewhere about categorical structures in programming: they are repetitive and mostly trivial (actually, the category theory without context is trivial).
After my experience, it run smoothly on Linux. I followed the guide at http://www.monodevelop.com/ to install mono, then F#; monodevelop is also a good IDE but personally I use spacemacs with F# layer.
