I found this abstract way of thinking about problems clear, & organised. "Mathematical Logic" is diffrent from the kind of Math I was taught, which was a top down approach to solving problems.
"Mathematical Logic" seems to be able to derive solutions to problems in a ground up fashion where a solution can somtimes elegantly present its self as long as you apply correct mathematical properties.
What other techniques do you hackers use to improve your abstract thinking?
[0]: https://en.wikipedia.org/wiki/Mathematical_logic
1 - Read lots of things unrelated to your field of study. Read about flowers, or art history, or music theory.
2 - Take long walks, get away from the screens and distractions. Walk some place that stimulates thought, like in nature, or in a city, or by a river. Skip the treadmill or places like malls that demand your attention. You need a place to allow your mind to wonder and to process/organize the info you read about.
3 - Dream, in a very literal sense. Do you ever remember those moments right before you fell asleep where your mind gets a bit too creative. Harness that. It has been said that Edison would take naps in a chair with heavy ball bearings in his hand. Right when he was just about to be asleep his hands naturally relaxed and dropped the bearings on the floor waking him. Quickly, he would pop up and recollect on dreams/ideas he just had. Use a similar technique to your advantage, see what randomness your mind designs.
Abstract Algebra and Linear Algebra are adjacent fields with a lot of clean abstractions that I believe exercise the same muscles as programming (even if a lot of it isn't directly applicable)
Related comment: https://news.ycombinator.com/item?id=23152152
i.e. basically linear algebra for engineers is not abstract. Linear algebra for mathematicians is quite abstract, e.g. a 400+ page textbook that doesn't refer to any matrices.
----
On the flip side, I think mixing abstract thinking with testing/debugging is the ideal combo for programming.
It is a skill to write useful test cases. To explore the state space efficiently.
If your code isn't grounded in real examples, then it may become overly general and not RUN run very well. It's a big danger to abstract before you have enough examples.
And probably the hardest thing that programmers do is debug OTHER people's code, as opposed to your own code.
(I guess you didn't ask about programming, but I'm sort of assuming you are programming by asking on this site :) )
So-called mathematical maturity lets you think about many domains without considering concrete reality, and this lets you solve a different class of problems. Many foundational computer scientists are or were mathematicians for good reason. Think von Neumann, Knuth, and Turing.
There is a magnitude of difference in abstract thinking between a mathematically mature scientist and a mathematically immature one. Mathematical maturity seems to allow an easy transition from abstract theory to empirical experimentation. The converse does not appear to be as true.
My advice would be to study math directly.
I think abstraction is about recognizing patterns, but also about recognizing what elements are more likely to change - you don't want to abstract away the changing aspects. In that sense, it becomes similar to creating a model that depends on parameters.
Also, generally, when you are implementing a solution, that solution exists within a context of a problem. If we are simply told to implement a solution, there is a temptation to just trust that the solution will solve the problem - and sometimes we are told to trust that. But if we take a step back in abstraction and fully understand the problem ourselves, we can derive our way to the correct solution, freeing us from having to "trust" that the solution is correct.
Abstraction is just continuing from there. Understand the larger context of the problem, why it is a problem. Maybe you'll discover it isn't, and that the solution isn't actually needed. And so on, if you ask another Why you can discover that maybe another problem is more important to solve, which would make this problem irrelevant.
You've got some abstract concepts of relationships. How do you go around thinking about relationships? You make them concrete. You do so by first representing them as perhaps, two points on a piece of paper and then drawing an arrow between them. This act of representation is an act of concretizing an abstract thought.
Now you start adding rules to your concrete representation. If you are rigorous about following your rules you almost inevitably end up when Saunders MacLane ended up with Category Theory.
Another example:
Think about computers and what they do. Now try to represent them on paper. Depending on how your mind works, you might end up with something that looks like a Turing Machine or cellular automata. I've not come across anyone who thought long enough and came up with something like lambda calculus, so I suppose Church was an alien.
I didn't use any mathematical logic examples because those examples typically involve historical battles over symbols.
It teaches you how to solve [math] problems, but not the kind you've seen in school. The author was a coach for the Mathematical Olympiad, and the kinds of problems he presents are creative, often requiring creative abstract lateral thinking to solve.
> Paul Zeitz studied history at Harvard and received a Ph.D. in mathematics from the University of California, Berkeley. He currently is an associate professor at the University of San Francisco. He won the USA Mathematical Olympiad (USAMO) and was a member of the first American team to participate in the International Mathematical Olympiad (IMO) in 1974. Since 1985, he has composed and edited problems for several national math contests, including the USAMO and helped train several American IMO teams, most notably the 1994 "Dream Team" which, for the first time in history, achieved a perfect score. In 2003, he received the Deborah Tepper Haimo award, a national teaching award for college and university math, given by the Math Association of America.
If you follow along carefully with the arguments in most classical philosophy in great detail, you notice this more and more: everything has a logical error or assumption eventually and the author typically does not catch their own error.
The simple answer, is practice. I know this is absurd sounding, but it really is the goal here.
While I agree that you should continue down the path of Math, there's other ways to practice abstracted thinking. Pick up some kind of artistic hobby. Painting, music, poetry, story telling, etc. These are all just things that force you to think creatively. Whatever you find interesting. It probably isn't a coincidence that a vast number of high level practitioners in science were also artists in some form or another (Einstein, Newton, Feynman, etc). Abstract thinking is often associated with connecting ideas from different subjects (abstract: disassociated from any specific instance ).
Additionally, focus a lot on creating analogies for things you are studying. This has 2 major benefits (to you). #1, it helps you remember. #2, you have to abstract a concept to create an analogy. Remember that the point of an analogy isn't to be precise, but rather to create an elegant means to abstract a concept (this also is why they are good for communication). An analogy primes you to remember a concept, it doesn't describe it exactly. After all, that high precision is difficult to express and comes with a lot of assumptions.
Lastly, another pure math method: study abstract algebra.
I can really see a difference here with my peers in the sense that it takes them a lot more to understand each other's lines of reasoning both in verbal and written speech, and it takes them a bit more to string together complex ideas when they are too far away from what they were taught (this last bit even affects the way code is written).
I guess any discipline that cares for truthfulness or sound reasoning is useful for this. The most important thing is you enjoy studying it and it conveys complex thoughts. Some other areas besides maths and history I can think of are philosophy, political science, economy and even architecture.
Of course this is N=1, so I'd take this with a grain of salt.
Good luck.
As someone who was for many years enamored with theory and mathematical elegance (I drank from the wells of lambda calculus and category theory in hopes of discovering something that would set me apart), I had to unlearn much of it to actually make progress in my work. When faced with new problems, I found myself trying too hard to find an elegant solution, and when I couldn't, I was paralyzed. My more resourceful colleagues on the other hand managed to ship yucky but working solutions -- which eventually got less yucky.
I learned that sometimes you have to let go of the ground-up mathematical-derivation type of thinking, and just release practical yet inelegant solutions into the wild, collect data, and then iterate. As one iterates, some solutions will tend toward elegance and others will not -- some problem spaces are just naturally messy and the solution needs to reflect that. If you've ever worked with an ERP, you'll understand how hard it is to unify competing concepts, yet that's what an ERP does with varying degrees of success. (everybody hates ERPs, but different people hate it for different reasons, and on the whole they kind of work)
Take something like Category Theory for instance: it seems like it should lead to amazing elegant solutions, but in practice it's rarely used -- and Haskellers might disagree with me here -- to design solutions (except in rare cases like LINQ). Instead, it's often deployed as a post-hoc gloss to explain solutions that have emerged by trial and error (like SQL perhaps). Its utility is often usually retrospective, i.e. either to verify correctness or to add rigor to existing solutions.
p.s. don't underestimate the value of experience + good taste in producing good thinking. People who design good abstractions are not always deeply mathematical people, but instead are people who have good intuition, like Anders Hejlsberg (architect of Turbo Pascal, Delphi, C# and Typescript), Rich Hickey of Clojure fame (who actually trained as a musician), etc. Guido van Rossum (Python) once said he probably couldn't have designed Python when he was 17 because at that age he didn't have enough experience and good taste in programming languages -- which is why most programming language designers tend to be over 35.
Otherwise, I recommend learning and using "extreme" programming languages, languages that go very far off your standard language. Examples:
* Lisp: everything is a list
* TCL: everything is a string
* Haskell: everything is pure and strongly types, and you use monads and other crazy stuff
* Rust: on the extreme end of safety through zero-cost (at runtime) abstractions
* Regexes: Just how much you can do with a powerful regex engine (declarative programming)
* Prolog
Finally: studying philosophy. Philosophers have honed their abstract thinking skills to the max :-)
I was a CS major with a Creative Writing minor. I picked the minor as an escape from CS but over the course of my career as a developer it has been some of my most useful time spent. When I was trying to write about a thing in terms of another thing (or reading other people's much better attempts) I would look at the lower level similarities and mess around trying to make the metaphor as tight as possible. Along with that, both writing code and creatively are mostly about constant revision. So both interests kind of played off each other reinforcing that process.
It was a painful journey, but in the end I found that it comes through the following:
Practice, a lot. I don't believe that anyone pulls solutions out of thin air. When tackling an abstract problem, people draw on the similar things that they do understand and then leap to the solution they're chasing.
Study the field you're trying to understand. Read over as many examples of solutions to abstract problems, and really analyze why they work. Try to solve your own problems, using what you've observed in those ones. Hop between these two until you start to close the gap more.
In reality, you're always going to make lots of mistakes and the practicing is never going to end. Its all part of the learning, and that's a journey that shouldn't stop.
If you're interested in this field of Mathematical Logic, I suggest you listen and read about it as much as possible, that you try to pursue problems you are interested in, and that you collaborate and discuss things with others. This constant doing, in small quantities but without getting up, will eventually help you see the abstract problems for something that is much more relateable.
Abstractions require a solid foundation, be it a floor below, or concrete. So, when I struggle with an abstraction, I look at its base parts, identifying what is required to understand the abstraction. What I find is I often do not understand a prerequisite as well as I think I do. Sometimes I have to go multiple levels down to hash something out, but once the abstraction clicks, it becomes effortless and as difficult to think about as any other word I use in English to talk and think.
Getting a solid foundation can be a time consuming process. If you go slow and relax, you'll find the missing pieces and everything will come together.
It really helps your brain to form pathways to seeing connections that may not be obvious on the surface.
Above will get you started ... engaging in abstract thought takes time and focused attention ... coding software can provide a medium to express yourself so can expository long form writing ... before bedtime bring to mind an unsolved question then upon awakening harvest solutions ... that habit can provide feedstock for ongoing evolutionary jumps
over time increase the complexity of these long form projects ... grow them so their course may stretch for days to weeks to months to ...
nurture friendships with interesting folks ... travel wide ... gain inspiration give guidance cherish the moment
I'd suggest something like linear algebra or analysis (in the mathematical sense of formal proofs in calculus). Those are both a bit higher level than logic, but still very abstract.
I used the book "Language, Proof, and Logic" which was also excellent.
These courses will formalize concepts and allow you to apply them much better than random anecdotes.
P.S. challenge yourself to solve problems with as few lines as possible, that way you're forced to find better (combinations of) abstractions
Puzzles can help introduce very powerful ideas without any baggage like mathematical notation. Smullyan's "Knights and Knave" style puzzles often touch very deep ideas in mathematical logic.[1] To Mock a Mockingbird[2] is probably his most famous book.
Godel, Escher, Bach has very clear, fun, and memorable descriptions of formal systems and their fascinating properties. After reading that it will be easier to view real world systems as formal systems and to understand the implications of that.[3]
Most of object-oriented programming and entity-attribute-value models can be found in the writings of Plato and Aristotle. For the purposes of abstract thinking, Plato's theory of forms[4] and Aristole's Organon[5], especially its Prior and Posterior Analytics which describe syllogistic reasoning, are probably the most important. For roughly 2000 years, this was logic. The Theaetetus[6] is also a very good introduction to epistemology and the deductive method of philosophy. In a practical sense, there is very little that programmers do in terms of modeling data or systems that does not derive more or sense directly from these two thinkers.
It's only been in the last two centuries that we've improved on Greek logic. Boole and De Morgan for propositional calculus[7], Frege and Pierce for quantification[8], which combine to create first order predicate logic[9]. From their you can either go to second-order logic or to set theory in order to begin talking about collections of things. Naive Set Theory[10] is a good introductory book, although you can jump straight in to ZFC set theory[11] for an axiomatic approach.
Relational algebra, which will be familiar in a loose sense to anyone who has ever worked with a relational database, is a formal theory that can be studied in the abstract[12]. I find the terminology (like "theta join") to be useful for thinking about advanced SQL statements. It's also very interesting to contrast relational algebra with ZFC set theory - many of the axioms are similar, but there are also crucial differences.
Lately, in the last century or so, abstract algebra[13] has proven very useful in modelling all kinds of real-world phenomena. For example, Lie groups in physics, or finite fields in cryptography. Abstract algebra basically strips down numbers to their most basic axioms and generalizes them. In group theory we study structures that have a single operation (say addition) then "rings" allow a second operation (say multiplication) and "fields" allow this second operation to be inverted. It is incredibly fruitful to model your real-world system as an abstract algebra and then to add axioms that fit your system (do your operations commute? Are the associative? Can they be reversed?) because you can then leverage a huge number of appropriate theorems.
The mother of all "abstract thinking" has to be category theory[14] which is so abstract I can hardly even describe it. Nevertheless many people find it a useful framework, with commutative diagrams[15] showing up all kinds of papers.
[1]: https://en.wikipedia.org/wiki/Raymond_Smullyan
[2]: https://en.wikipedia.org/wiki/To_Mock_a_Mockingbird
[3]: https://en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach
[4]: https://en.wikipedia.org/wiki/Theory_of_forms
[5]: https://en.wikipedia.org/wiki/Organon
[6]: https://plato.stanford.edu/entries/plato-theaetetus/
[7]: https://en.wikipedia.org/wiki/Propositional_calculus
[8]: https://en.wikipedia.org/wiki/Quantifier_(logic)
[9]: https://en.wikipedia.org/wiki/First-order_logic
[10]: https://en.wikipedia.org/wiki/Naive_Set_Theory_(book)
[11]: https://en.wikipedia.org/wiki/Zermelo%E2%80%93Fraenkel_set_t...
[12]: https://en.wikipedia.org/wiki/Relational_algebra
[13]: https://en.wikipedia.org/wiki/Abstract_algebra
And psychedelics tbh. There is a propensity of science that says that among other things, psychedelics improve your ability to connect what you know. https://www.sciencedirect.com/science/article/pii/S105381192...
[0]: https://www.whitman.edu/mathematics/higher_math_online/
A great test of how well you understand a (mathematical) concept, is if you can visualise and reason about it when you are away from a desk and doing something else. That said- you can never know all the stuff you want to know, so dont stress about it :)
But what is your goal? Is this just as a form of exercise?
If so, I recommend going through (really understanding) Godel's Incompleteness Theorem(s). In my opinion, it's very hard but it is something that's doable without an insane level of prerequisites depending on how you approach it. It's also quite interesting and one of capstones of the 20th century, but don't bring it up at cocktail parties.
Bonus: it will really help you to go to sleep.
Anyway.
To me, it really taught how to tackle Hard Problems, where you do just sit there making seemingly no process for hours/days/weeks. When you first start tackling such problems it can feel really frustrating, but actually with experience you realise that progress is being made when you slowly manage to map out the problem space and get a better intuitive understanding what's going on. I kinda do imagine it as stumbling round in the dark in an unfamiliar place, slowing groping around, hitting dead ends, then slowly but surely getting a mental model of what's around you and how it all interconnects. Once you have that understanding and intuition the problem is often, kinda, easy? Or obviously impossible and you'll need to make some trade offs.
Changing the way you think about progress to be less goal oriented and more about expanding your understanding is really quite crucial to tackling such problems I think. Both just to keep you motivated through the process and stop you from getting discouraged, but also helps you realise when you've stopped making any progress and should take a bit of a break and come back with a fresh mind.
Most of the time this skill is entirely useless, but sometimes it really is quite powerful. I guess working on Matrix is a bit of a special case, but I would never have been able to sit down and spend weeks trying to come up with a new state resolution algorithm, to pick one example, without that sort of experience. I just wouldn't know where to start, and I'd become demotivated by the end of the first day and likely give up (knowing me).
All of this rambling is to say: I think Maths is really something you have to do. Reading books about it is interesting and great and all, but if you really want a deeper understanding you have to get stuck, get your hands dirty and try to solve problems. I don't mean problems where you take that cool theorem you just learnt and apply it or figure out how to apply, but problems where you actually have to come with ideas and theories on your own. (Now, I have no idea how feasible that is outside a formal setting and without supervisors, but that's really the dream).
I hope that in some ways helps, even if its probably entirely devoid of practical advice :)
Any advice for that?