rkallos
His books, in order of publication:
- How Not to Die (2k citations) - How Not to Diet (5k citations) - How Not to Age (13k citations)
Boolean arithmetic sometimes uses + for OR and * for AND. When considering only zero and non-zero values, the semantics are the same. 1 + 1 + 0 is non-zero, 1 * 1 * 0 is zero. Substitute + for OR and * for AND, and you wind up with the "same" result.
From the linked article:
> one is „and data“, the other is „or data“.
Structs/records/product types fit the description of "and data", because it's a compound value comprised of this type AND that type AND that other type, etc.
Unions/sum types fit the description of "or data" because it's either this type OR that type OR that other type.
Neither of these are really the places I look at when examining flame graphs. I tend to look at the bottom, and work my way up.
The key thing (imo) to look for are wide pieces that are not a core part of what the code you're profiling is supposed to do.
In the first example of your first link, you have a flame graph of code that seems to draw an image. There are a bunch of functions like 'CopyPixels' and 'RasterizeEdges'. Those seem to be a core part of drawing an image. In contrast, there's a 'KiPageFault' function that's pretty wide that does not seem to be important to the code's overall goal. I think a bit more context is needed to arrive at the author's conclusion, though.
I think flame graphs, like all graphs, are more helpful when the reader has a lot of context about what's supposed to happen, or some intuition about how the chart is supposed to look.
Reading about these with accompanying images of spaces or objects demonstrating the presence or absence of these properties is what made it stick for me.
However, to read only Meditations and go on to make claims about the philosophy as a whole is a bad idea that ignores hundreds of years worth of philosophers who also contributed to Stoicism.
For those interested in a more broad treatment of Stoicism, a wonderful follow-up to Meditations is Donald J. Robertson's Stoicism and the Art of Happiness
Are you sure? My understanding is that people who live in dense cities rely less on automobiles, have their waste treated more efficiently, and consume less energy per capita in order to enjoy clean air and water. Those factors are more important than the land mass required to feed someone.
I'm no expert, but my understanding is that more denser of paper (80 g/m^2 and up) take much better to fountain pen inks.
I swear by Clairefontaine and Rhodia notebooks and paper.
Meanwhile, I find it ironic that the same state enacting this "intellectual diversity" law has specifically banned teaching critical race theory in public schools.
A voluntary survey invites participation bias; respondents will likely skew heavily toward the "I feel I am being indoctrinated/I feel uncomfortable voicing my beliefs". The spirit of the law aside, this law looks like a lever to pull funding from universities where the median Floridian, who votes Republican, would feel like their views are being challenged.
> The notion that to learn a language you also need to learn a second one is not great. [...] It's just bizarre.
I disagree. I don't think it's bizarre. I expect to sometimes have to poke around in C code when writing Erlang or Python. It's also fairly common for C/C++ developers to look at the assembly output of some piece of code using https://godbolt.org/.
> Reading the code is NOT an answer.
Again, I disagree, and I think this perspective is harmful to career development. Knowing how things work on a deep(er) level is a superpower. When you're writing Elixir, do you never open up a .ex file in the standard library to see how something is implemented? Are you not at all interested in what powers things like Phoenix.PubSub?
> I don't know what a solution is, but perhaps a concerted effort to create a documentation and library ecosystem that never links back to Erlang would help.
I suspect that a library ecosystem that doesn't require Erlang would be a huge effort to implement and test, and would wind up pulling in all of the ideas from Erlang that you haven't learned/mastered yet. A better alternative would be to accept the fact that Elixir builds on top of Erlang, and understand that a deeper knowledge of Erlang is going to help you improve as an Elixir developer.
> And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order?
I'm definitely biased, but I would be much less trusting of an Elixir copy of a 'critical' Erlang library. Many of the selling points of Elixir that lead to very concise code (read: macros, 'using', and others) are things that make it difficult for me to develop a deep understanding of a library. It's cool to use DSLs like Ecto and Plug, but I have a much harder time understanding those libraries as a result. Erlang's unambiguous syntax and its basic text-substitution-based macro system are much easier for me to understand, and while it takes more effort to write APIs and code that are as concise as what's available in Elixir, I know that I can open up an Erlang file and trust that much less is hidden from me.
> What the WSJ describes would not be possible with our privacy practices today, practices we proactively implemented two years ago
> Grindr takes the privacy of its users extremely seriously, and we have put privacy before profit
> Grindr does not share users’ precise location, we do not share user profile information, and we do not share even industry standard data like age or gender
My solution for garbage collection was pretty boring. Occasionally, a JSON file was rsynced to each service node with the 'true' state of the system at some time in the past, and the CRDT maintained the new state on top of that JSON file, until the next file got rsynced.
I hope that there are existing implementations of OpSets that perform well. I find the solution laid out in that paper to be really elegant and beautiful.
Reference types are probably the trickiest bit to learn, especially in how they relate to Pony's generics. Everyone is different, but I found learning the 6 reference capabilities to be a lot easier than trying to understand borrowing and lifetimes in Rust.
I readily accept other reasons not to pursue Pony; it's library ecosystem is budding, the runtime is still a bit unstable, and there is limited support for non-x86_64 architectures. However, I invite anyone reading this comment to form their own opinion of the language. I feel I've benefited greatly from learning it.
Also, Pony has a pretty active community on Zulip, where you will find people who will jump at the chance to help you get unstuck while you're writing Pony. https://ponylang.zulipchat.com/
Now I'm experimenting with TiddlyWiki, and I've been having a lot of fun with it. With a small modification, I made it so that tiddlers/pages displayed a list of all other tiddlers/pages that backlink to them. This made it very easy to start connecting ideas together, which is something I never succeeded at with my notes in Org files.
The article is about the latest prototype for a device that accumulates plastic for disposal. The idea behind it is to create U-shaped artificial coastlines that slowly glide through the Great Pacific Garbage Patch and accumulate plastic for easier collection and disposal. Their first prototype had some defects, but this iteration seems to be off to a better start, and appears to be successfully capturing plastic.
This isn't a large scale operation (yet). It's a promising prototype. I'm excited to read about it, though!