2026-03-25 06:32:00
Some weeks back there was a popular post on the Discovery page recommending another blog (I don’t want to call anybody in particular out, because this is just an example of a society-wide trend!). This was an authentic human saying “I love this blog, the writing is beautiful and it really speaks to me”. Wanting to feel inspired myself, I checked out this other blog and every single post was AI-generated. Specifically, it was very obviously ChatGPT. It was generated last year so before so many people were wise to the tells, and did have the em dashes edited out, but otherwise every paragraph was packed do the absolute gills with doing things "quietly" and introducing thoughts with "And honestly?" and if you're familiar with LLM writing you get the idea.
If you aren't — I've noticed people can get a little defensive and uncomfortable when a so-called "LLM tell" is a word or phrase they use in their own writing, but I really don't think this is necessary! Despite people's fears that they'll be mistaken for AI I've yet to meet anybody who's natural writing sounds anything like AI. You might have one tell but not all of them at once.
Anyway.
One one level it shouldn't matter if one person found a robot thought-provoking. Or when people rely to a ChapGPT slop post on Reddit with "oh my gosh this was so well written" or a ChapGPT quip with "hilarious!!!!!" We can find meaning wherever we want! But whenever I encounter somebody who likes this stuff I feel this growing sense of dread and it's even worse when they clearly don't know it's AI they're responding to.
I guess it's scary to think maybe I'm getting tricked somewhere, by more subtle LLM product, and I have no idea.
And those of us who want to write, it's distressing if some people think a robot does it better.
But I also just get mad. This is what people want?! This is crap! Most of this kind of writing doesn't build to anything, doesn't say anything. It doesn't even try to make its paragraph different lengths.
Ultimately I just get worried that I'm going to spend the rest of my life running from my least favorite author of all time. I checked out a physical book from the literal library that had ChatGPT-generated text in it! Who will stop this bastard?!
--
This post was last edited 16 hours, 31 minutes ago.
You can reply by email.
2026-03-25 04:00:00
Cash is universally accepted within the boundaries of your country, predictable and anonymous. Transactions require no intermediary, nor a processing fee. It is tangible and has no cybersecurity vulnerabilities.
We might only realize what we had once it is gone. If you can, use it more often.
2026-03-25 02:53:37
This website is for me. I’ll probably do a future post about what that means. For now though, I want to share how I avoid seeing any the site’s metics.
What gets measured, gets done.
I host this site on Bear Blog, which measures a few thing by default:
Here’s how I turn them off.
On your Dashboard, go to Settings
and then Advanced settings
. Uncheck Collect analytics
and hit Save
.
Add this to your theme’s CSS:
#upvote-form .upvote-button .upvote-count {
display: none;
}
Click Save
. Boom! Gone!
You can hide any blog from your Discover feed. I hide my own. It’s not like I need to discover it.
If you really want to make your presence known, get in touch.
5-a-side was cancelled, so I'm having a chill evening at home.
2026-03-25 00:59:35
Just got back from the gym. Phew!
Not quite the same as twenty years ago. I’m over 50, and trust me, it’s hard to ignore. I can’t lift the same weights, have the same intensity, or get the same body as those half my age.
If that were my motivation, I would have given up a long time ago.
But it’s not about that, and it’s not really about staying strong and in shape either. That’s a nice bonus, but it’s not what drives me the most.
My main motivation is the discipline. It feels good to stick to the routine. It leaves a nice feeling of accomplishment, even if I’m the weakest guy in the gym.
I feel the same way about blogging. It’s a nice feeling when a post gets noticed, and it’s wonderful getting readers’ feedback, but that’s not what motivates me.
If that had been my goal, I would have quit a long time ago. Some posts get attention, most posts don’t, often the ones I personally like the most. That’s fine.
My main motivation for blogging is the discipline. It feels good to write a blog post, no matter what happens after I hit publish.
It’s a personal accomplishment, and that reward is what matters the most.
2026-03-24 23:43:00
I run a finance web app built with Quart, the async-native counterpart to Flask. I chose Python for a practical reason: finance is my main domain, and most of the people around me understand Python. Very few of them work comfortably at the systems level, so in many cases I still need to stay grounded in Python.
At the same time, I have been building tools that let me push more of the heavy finance data work down into C. One of those projects is a Pandas-compatible replacement aimed at keeping more of the pipeline at the C level, so I can avoid climbing back up the stack unless I actually need Python. But that's a story for a different article.
In this post I will provide a map layout of how I built a Quart accelerator: Zigguart, where it enables a Python web framework to have massive throughput capacity.
I think the easiest way to misunderstand Zigguart is to treat it as one more attempt to make a Python web stack a little faster. That description catches the surface of the project, but it misses the real point.
Zigguart is interesting because it changes where the work happens. Instead of assuming that every request has to become a normal Quart request, it asks a more useful question: which requests actually need Quart (and Python) at all?
That question matters because ordinary performance tuning has a pretty low ceiling. You can make JSON a bit faster, reduce copies, improve pooling, and clean up middleware ordering, all of which helps. Even after all that, the basic shape of the request is still the same. The server accepts the connection, Python owns the request lifecycle, the framework builds its abstractions, and the application runs. A better version of the usual path is still the usual path.
Zigguart is trying to break that assumption. In a standard Quart deployment, the picture is straightforward:
Internet -> Granian -> Quart
With Zigguart Mode B, it becomes:
Internet -> Zigguart -> Quart
That is the single change at the architectural level: Zigguart moves in front of Quart and becomes the server that sees the request first. Inside Zigguart, the flow is more detailed. A request can be rejected early, served from the Zig cache, or passed through the embedded Python bridge into Quart. The important point here is simpler than the internal mechanics. Quart stops being the thing that has to own every request from the beginning.
The most accurate short description: Zigguart moves Quart off the hot path without giving up Quart. That is the real ambition: it keeps Quart where Quart is useful and tries to erase Quart where Quart has become repetitive overhead, while not forcing a rewrite to another framework.
This is what makes the project more interesting than generic "Python, but faster" marketing. A lot of performance work in web applications still lives inside the assumption that every request must become an application request. In practice, many high-traffic routes are stable enough that rebuilding the whole framework path on every hit is simply wasteful. If a response can be replayed safely, the fastest place to do that is in front of the framework, not inside it.
That is the real design move. Zigguart puts a native layer in the only place where order-of-magnitude wins are even available: before the Python framework wakes up. Once you do that, repeated requests stop being opportunities for micro-optimization and start becoming candidates for elimination.
The big headline numbers only make sense if you interpret them correctly. When Zigguart produces a large warm-route speedup, that does not mean template rendering became magically cheap or that database access suddenly improved by two orders of magnitude. It means the route is no longer taking the normal application path on repeated hits.
That is an important difference. On a real cache hit, Zigguart can skip the parts of the stack that usually dominate Python web serving:
At that point the unit of work changes. The system is no longer "running the web app again." It is replaying a cached response from native memory. The server looks up the bytes, assigns the headers and body, and writes them to the socket. That is why the warm-path numbers can become so dramatic without being dishonest.
The project is not claiming that Python itself has become absurdly fast. It is showing that repeated traffic can often avoid Python entirely.
This is also why Zigguart feels more like an accelerator than a typical server. A normal high-performance ASGI server is still excellent at serving Python requests. Zigguart is strongest when it can prevent a request from needing to become a Python request at all ~ avoiding any processes at Python level if possible.
If you pay attention, I keep on repeating the point on avoiding any processes / operation. This is a simple design decision where people often forget: don't process if it's not needed, don't try to be "sophisticated" by adding unnecessary complexity to your design. Return to the first principles of design.
The first major strength is obvious once you look at the control flow. Zigguart gives the earliest decision to Zig. That matters more than any isolated micro-optimization, because the earlier you decide, the more work you can avoid. If Zig were still sitting behind Quart, the ceiling would stay modest. Moving the native layer in front of Quart is what gives the design its headroom.
The second strength is the cache itself. cache.zig is not just a storage mechanism. It is part of the execution model. The cache is in-process, Zig-owned, and consulted before the Python fallback path. A hot hit is served from the native server path, not from a Python callback that happens to fetch something cached. That distinction is easy to miss, and it is the reason the project cannot be reduced to "the app has caching now."
The third strength is that Zigguart is not transport-only. It has app-facing acceleration concepts because the goal is not merely to parse HTTP quickly. It tries to understand when an application route can be short-circuited safely. That is why route classification, @simple_json, @cached_route, and the promotion rules matter. They are attempts to define where application semantics can be preserved while the framework cost is avoided.
The fourth strength is narrower but still important: the project is very clearly Quart-first. That focus gives the work a real identity. Zigguart is not trying to be the universal answer for every Python async framework on day one. It is trying to make an existing Quart app fast without forcing a rewrite. That is a practical goal, and it is one reason the project feels more grounded than many performance experiments.
The fifth strength is easier to overlook because it does not show up in a flashy benchmark graph. Zigguart has spent real effort on correctness. Trusted proxy handling, cache-safety restrictions, request bounds, overload shedding, and shutdown behavior are all part of the story. Once Zig sits in front of the app, the server becomes part of the trust boundary. At that point, sloppiness turns a fast-path demo into a liability. Zigguart has mostly taken the harder route and treated the front layer like real infrastructure.
One reason the project holds together conceptually is that the Mode B pieces have clear jobs. server.zig owns process startup, worker lifecycle, shutdown, and the main runtime. httpz gives the project a Zig-native HTTP/1.1 substrate without burying it in a full framework. cache.zig provides the warm-path engine. python_embed.zig keeps CPython and the fallback event loop alive inside the process. asgi_bridge.zig turns a miss into a real ASGI call and extracts the response back into the native side.
That last file is where the tradeoff becomes visible. It is the compatibility layer, and it is also the place where cold traffic still pays a lot. The bridge has to build request state, cross into Python, wait for the framework to run, and then bring the result back out. That is why the project is strongest when it can keep traffic away from this path.
I think the most elegant part of the design lives in python_embed.zig.
The code literally inverts the usual relationship between Python and the server. Python stops being the server and becomes a service living inside the server. That is more than an implementation detail. It is the architectural statement that makes the rest of Zigguart coherent.
The benchmark numbers only become meaningful once they are separated into warm and cold behavior. Warm traffic is where Zigguart proves the architecture. Repeated routes that can be cached and replayed are where the project becomes convincing. That is why the review numbers can show strong gains on routes like summary, market_page, commodity_specific_oil, and, on some paths, much larger wins still.
The clearest data point is the latest warm Quart_FA comparison:
Latest results — zigguart-httpz vs zigguart-granian (warm traffic)
benchmark/results/20260321-105626 · wrk 4 threads · 64 connections · 10 s · Linux x86-64
These are real Quart_FA production routes: HTML pages, DB-backed stock summaries, commodity pages, and earnings tables. Those are not JSON response where usually is used by most web framework benchmarks. The only JSON response from the bench was the health endpoint where it consists of 10 lines of nested JSON. The rest are full HTML pages.
The key point is that both sides of this benchmark already use the same Zigguart cache:
zigguart-httpz: Zigguart cache + http.zig server pathzigguart-granian: Zigguart cache + Granian server pathThis is not "cached Zigguart" versus "uncached Granian", both above combo received the same zig-cache benefit. Warm means the Zig cache is already populated, Python has already run once for that URL, and subsequent requests are served from cached responses. The remaining difference comes from the server path itself. Even after both sides get the same Zig-cache benefit, the standalone Zig server still serves those cached responses orders of magnitudes faster than the Granian-backed path.
While those results are real, they also need to be described honestly: a 100x result does not mean Quart became 100x faster. It means the repeated request no longer travels through Quart in the ordinary way. The server has moved the work to a different place, and on the hot path that change dominates everything else.
The spread in the numbers is also informative. Smaller warm-route multipliers usually correspond to heavier bodies or routes that still have meaningful transport and replay cost even after caching. Very large multipliers show up when the old stack keeps paying Python costs for a route that Zigguart has reduced to a native cache hit. The numbers vary because the route shapes vary. That is exactly what you would expect from this design.
This is also the right place to mention the part that can sound like magic if it is not explained properly. The "Zig-cache magic" is not some mysterious extra optimization layer. It is simply the consequence of where the cache lives and who owns it. cache.zig sits in front of the fallback path, inside the server, and stores replayable responses as native server data.
On a warm hit, Zigguart is not "using Python more efficiently." It is skipping Python and replaying the response from Zig. That is the mechanism behind the benchmark table above.
Cold traffic tells a different story. A cold miss is expensive as it still has to pay for the bridge, for Python scheduling, for response extraction, and for whatever work the application itself does on that miss. On Quart_FA, that application-side cost is not small. Startup warmers, CSV loading, SQL fan-out, pandas transformations, and template rendering all pile on top of the server’s own fallback work. That is why the project looks much less dominant on cold misses than on warm hits. It is not a contradiction. It is the natural limit of the current architecture.
Zigguart is closest in spirit to Granian. That is the most useful comparison, because Granian also moves serving work out of the traditional Python stack and tries to make the transport layer efficient enough that the framework stops dominating every request. Uvicorn and Hypercorn are still useful reference points, but they occupy a different role. They are broader, more mature, general-purpose ASGI servers.
The distinction matters because Zigguart is not trying to win by breadth. It is trying to win by changing the hot path.
Uvicorn and Hypercorn want to be reliable servers for Python apps in general. Granian wants to be a very fast server for Python apps. Zigguart is trying to become a server where the hot path often stops being a Python application request at all.
That gives it a narrower identity, but also a more distinctive one. The fairest way to describe Zigguart at this stage is probably this: it is an early-stage, Quart-first, Granian-like server with an additional application-acceleration layer. That is a better description than calling it a drop-in general-purpose replacement for every mature ASGI server, because it tells you what the project is actually optimizing for.
The Quart focus is more than branding. It shapes the whole project. In a lot of performance conversations, the implicit answer is that if you care enough, you should move to a different framework. Sometimes that is the right answer. In other cases, the app already exists, the framework fits the product, and the real problem sits lower in the stack.
Zigguart comes from that second situation. It assumes the Quart app is worth keeping and that the serving model is the part that should change. That is why the project feels more practical than a full framework rewrite. It also explains why it has app-facing concepts instead of staying purely transport-shaped. The project is not chasing abstract server speed in a vacuum. It is trying to keep Quart where Quart is valuable and remove Quart where it has become repetitive machinery.
The obvious objection is that this all sounds like a more complicated way of describing a cache, and that Redis already exists. Redis is excellent at shared storage, cross-worker reuse, persistence across restarts, and centralized invalidation. A Quart app can absolutely benefit from Redis.
What Redis does not do is change who serves the request. A Redis-backed Quart app still moves through the normal Python server path before the cached value becomes useful. Zigguart solves a different problem. Its cache sits directly in the serving path, in native memory, in front of Python. A hot hit can be served before the framework is involved at all.
That is why Redis is better understood as a possible complement, not a replacement. If Zigguart ever wanted a second-level shared cache, Redis would be a sensible L2. Replacing cache.zig with Redis entirely would weaken the most valuable part of the project, because the hot path would stop being a pure in-process native response path.
If you ask "why not just use Redis?", you're asking the wrong question. The useful question is whether it is valuable to move repeated traffic off the Python request path completely. Zigguart is built around the idea that the answer is yes ~ avoiding any processes in the Python level.
The weak spot is cold traffic, and that needs to be stated plainly. The architecture shines when it can avoid the fallback path. It is much less impressive when it has to take the fallback path and the application itself is heavy on a miss.
That does not mean the architecture is wrong. It means the project is still living with the cost of compatibility. The fallback bridge is real work. The app behind it is also real work. In Quart_FA, that means cold summary requests are carrying startup contention, data loading, SQL work, dataframe processing, and template rendering on top of the bridge cost.
So the honest reading is simple. Warm traffic already proves the core idea. Cold traffic shows where the unfinished engineering remains. That is not a bad place for the project to be, but it does make the next priorities clear.
Even with the cold-path weakness, I still think the architecture is worth pursuing because it is pointed at the right problem. The biggest wins in serving usually come from moving responsibility to the right place in the stack. Zigguart has done that. By putting the native layer in front of the framework, it has given itself a chance at very large wins that would simply never appear inside the ordinary Python request path.
It also avoids the ridiculousness of "rewrite the app in X language" as the only way forward. The project keeps Quart for the complex path and strips Quart out of the repetitive path. That is a much more attractive migration story than telling a working application to change its framework for the sake of the server.
At this stage I would not describe Zigguart as the final form of a general purpose Python async server. I would describe it as a serious Quart-first server and accelerator that has already proved one very important point: moving the serving decision in front of the Python framework changes the economics of a real web app in a meaningful way.
Zigguart core components are written in Zig, a low level systems program language aiming to be "a better C". If you follow my posts then you'd know I love writing C programs, so much that I modified my C version to use safe_c.h and then built cgrep and cforge with it.
Plenty of projects use a faster language around Python, but I feel Zig is special as it has 1:1 structure to C and it's easier to get to a lower level than C. What makes Zigguart unique is that it gives Quart a different serving model while still letting the application remain a Quart application.
I think this is the real architectural contribution: it changes how repeated traffic is served, it explains the warm-path benchmark numbers cleanly, and it points to a alternative method where the framework is used where it adds value instead of where habit placed it. By habit I mean: the default old pattern where every request automatically goes through the Python framework.
The project is not finished. The cold path still needs real work. The maturity gap with broader servers is still there. Even so, the central idea has already proved itself. Zigguart shows that a Quart app does not have to live forever inside the full Python request path, and that is a strong enough result to make the project worth continuing.
If you enjoyed this post, click the little up arrow chevron on the bottom left of the page to help it rank in Bear's Discovery feed and if you got any questions or anything, please use the comments section.
2026-03-24 23:36:00
After my previous post dunking on the self-help genre 1, I made a point about putting more emphasis on fiction/history/biography/philosophy books. That last one can raise a few eyebrows from people.
I think people tend to get the wrong idea about philosophy, largely because of how it's introduced in school and what we learn through the proxy of others. Schools will give you barely a shaving off the iceberg. I think the only thing I learned about philosophy in school was Socrates, Plato, Aristotle, and a handful of enlightenment thinkers like Descartes. This obviously became more in-depth in college, but most of us aren't taking PHIL-1010.
From our peers it can often be worse. Stoicism tends to get conflated with emotional distancing, and is often appropriated by ligma male grindset dorks. These people are called "Broics" by modern Stoics, or people in the philosophy space. We often hear about philosophical ideas from other people in an almost game-of-telephone like way. You have the idea, then someone's interpretation of that idea (accurate or not), then someone's interpretation of the interpretation, and so on.
You might get an account of the usual suspects. Descartes, Marx, Aurelius, Plato, Aristotle, etc. and think that's all there is to philosophy. You might think philosophy is pointless (which ironically is a philosophical stance). I want to illustrate why engagement with philosophy is important if not completely universally necessary.
This is gonna be a long one, so buckle up.
Philosophy comes from the ancient Greek word philosophia, meaning "love of wisdom". It basically entails trying to answer fundamental questions about life. These range from trying to find the meaning of life to contemplating on if what we are seeing is or if what we are seeing is an abstraction of what is. It ranges from immediate importance as a fundamental basis for how one lives their life to asking yourself stoner shower thoughts.
There are basically 4 major disciplines in philosophy: metaphysics (what is reality?), ethics (aka moral philosophy), epistemology (understanding the matter of and nature of knowledge), and logic (the study of correct reasoning).
I feel like logic is a trigger word for people who had one too many encounters with Ben "I can't get my wife wet" Shapiro wannabes. Let me tell you that understanding how logical reasoning works is incredibly important. It basically underpins everything.
There's basically 2 branches of logic, formal and informal. Formal logic is basically math in the sense that it follows a set structure. Math is essentially applied logic. You take an argument and apply it through a sort of frame work to logically justify said argument. For example, "If all spiders have 8 legs, and a tarantula is a spider. Then all tarantulas have 8 legs". We have premise and conclusion. However we can fall into formal fallacies, in which the very structure of the argument is flawed. For example: "If it is a dog, then it is an animal. It is an animal. Therefore it is a dog." The structure falls apart completely.
With informal logic we encounter arguments in our natural language (i.e. debates, discussions, and rhetoric), applications of critical thinking, etc. This is what we are most familiar with and what we mostly think of when we think of logic. It's less about following a strict framework and instead is about the application of logic in the real world. This is where we encounter logical fallacies like Ad Hominem, slippery slope, strawman arguments, etc.
We can also run into sound vs. unsound reasoning. Example: "If all mammals give birth then a platypus is a mammal". It comes to a correct conclusion, but the reasoning fails because platypuses don't give birth, they lay eggs, it is therefore unsound reasoning.
Applications of logic are how we either become convinced by an argument or use it to justify our own. Debates and discussions about veganism, anarchism, anti-natalism, etc. are all employing logical reasoning.
Ethics is about figuring out right and wrong, and why something is right or wrong. The most important branch of ethics in my opinion is applied ethics. This is where we get into subjects like "is abortion morally right?", "Is it wrong to kill animals for food?", "is killing another person justifiable?", and so on. In this we seek to understand real moral dilemmas that cause us to question our actions and motivations. This is where logic comes in to make for convincing arguments for and against a certain position.
Normative ethics is basically the theories for how people should act. Examples include deontology, consequentialism, and virtue ethics. Virtue ethics is about proposing virtues like courage and compassion as the grounds for morality. Deontology places the importance on if an action itself is moral or not, and that we should do/avoid moral actions on that premise. Whereas a consequentialist will act morally based on if the end result is morally right.
All of these you might see within yourself and those around you, and your moral framework might shift on given subjects. Lets use the premise of "should you be compassionate to fascists". Virtue ethics would say yes, as it is imperative to be compassionate to all people. A consequentialist might say yes or no depending on if the end result leads to that fascist changing their outlook on life or if it would put more people in harms way (a focus on the end result). A deontologist might say yes because the act of compassion itself is morally righteous and thus should be applied. I'm hoping you get the point I'm trying to make here.
Metaphysics often gets seen as what that one dorky wannabe-intellectual touts they are studying (despite having no clue what the fuck it actually is besides it sounds challenging to study). Metaphysics itself is about the study of reality. What is real. When you think of someone getting high as a god damn satellite and asking really stupid questions, it's basically metaphysics. Seriously, you'd be surprised how many stoners I've been around that have accidentally parroted Plato's theory of Forms.
"Dude, like, what if what we are seeing isn't REALLY the thing, but like an abstraction of the REAL thing?"
Riveting stuff.
This is probably what people would consider pointless philosophy as there isn't really any real applications. Things like questioning what is the self, do we have free will, what is existence, etc. You can get to some important stuff, the concept of gender as a social construct falls into the camp of metaphysics.
If you want a fun plan, get stoned with some friends and then start debating on if we have free will.
This explores different types of knowledge as well as the limitations of knowledge. This is where we get "book smart" vs "street smart". I.e. propositional knowledge and practical knowledge.
Epistemology is probably another crucial aspect that everyone should be more learned in. As epistemology encompasses skepticism (questioning if knowledge is ever truly obtainable with certainty), empiricism (knowledge being obtained through the senses), justification, truth, and belief.
An example of epistemology in practice is questioning the knowledge of a colorblind person if a stoplight is red. Another example is affirming or denying the existence of a god.
Epistemology takes into account if one person finds enough justification that God exists using epistemic sources like testimony, perception, etc. to back the claim. Same thing with the aforementioned colorblind stoplight observer, using their sense of sight to conclude the green light is red or vice versa.
Basically, dealing with beliefs, reasoning, truth, and evidence all are what are contained in epistemology.
Epistemology is what allows us to call into question our reasonings and beliefs. We may ask ourselves "well why do I believe that?" and then start down a path that either further justifies our belief or our truths or then seek to dismantle them. This is how people deconstruct from religion.
Above is the kinda core 4 that you would see in most academic circles and online discourse. Here are some other ones that are worth looking into.
Existentialism is a sort of a mix between multiple branches. As it understands the metaphysical point of the lack of objective meaning in the universe. And then will go into the ethics side of things, what people ought to do about it. Camus, Beauvoir, Kierkegaard, and so on all fall into this camp.
Aesthetics is basically the philosophy of art. What is beauty? What does it mean to have good taste? When you engage with art and ask questions about it, you're essentially engaging with aesthetic philosophy.
Education philosophy dives into theories and frameworks for education. Things like Montessori education are examples of applications of educational philosophy. Applications of critical thinking and avoidance of indoctrination are also part of this branch of philosophy.
Political philosophy talks about concepts for political foundations. Conservatism, anarchism, fascism, communism, liberalism, libertarianism, etc. all are all forms of political philosophy. The main crux is to examine the foundations of politics and questioning the legitimacy of institutions. I think that last one is incredibly important as so much of our lives are dictated by institutions that insist upon their own legitimacy.
I wanna give you a list of some philosophers or ideas that I would recommend looking into. I'm not saying you have to read the entire works, as they can be a bit dense and definitely not for everyone, but I do encourage you at least look into the ideas they propose and maybe some commentary books on them.
Alternatively, you can engage with "pop" philosophy channels which tend to be more palatable. The two channels I recommend starting with are Sisyphus 55 and Unsolicited Advice
This was a long-winded article that took me a couple hours to write. So, I appreciate you if you read it. I hope you've learned something from it.
Really at the end of the day, I wanted to illustrate how massive philosophy is and how it connects to our lived experience. Everyone engages with it usually subconsciously, but I hope that by illustrating what philosophy encompasses you can become more aware.
My life has changed so much through engagement with philosophy. Exercising in epistemology in my transition of going from a neoliberal sympathizer, to socialist, to now sympathizing with anarchist ideas. Using ethical frameworks for justifying actions. Pulling myself out of an existentialist hole after really understanding the meaninglessness of the universe and then subsequently finding liberation therein.
Philosophy is a beautiful subject. I don't expect everyone to start reading Thus Spoke Zarathustra tonight, but I hope that I've at least illustrated well enough the subject's importance.
Previous |
Reply via email: [email protected]
I woke up about 30 minutes early today. You ever get those dreams where your dream self has to pee and then you wake up and you, in-fact, have to pee? Yeah me neither. Been doing a bit of work on my shrine to classic Halo on my main site, it's been slow, but I've been making progress. I've managed to rip some assets from the Internet Archive to give it a more 1:1 look to Bungie.net from 2007.
I want to clarify that I don't think all self-help books are bad. My main issue is that they tend to be highly exploitative of people's insecurities and often these books come across as a cash grab from people who don't actually care to see you improve. If you get enjoyment out of it, by all means, just be mindful and don't fall into the consumerist trap these books often put people into. Some good books that I consider to be self-help that I recommend would be Maybe You Should Talk to Someone by Lori Gottlieb and Lost Connections by Johann Hari.↩