I would recommend the 2021 three-part Acquired podcast series on Berkshire. Episodes are long, though there are transcripts if you prefer reading over listening.
>“I'm somewhat embarrassed to say that Tim Cook has made Berkshire a lot more money than I've ever made,” Buffett told the audience, referencing the remarkable 680% surge in Apple's stock since Berkshire first began acquiring shares in early 2016.
but it pretty much only works for JavaScript programmers and their friends (or folks interested in learning JavaScript).
Other tools which I'd like to put forward as meriting discussion in this context include:
- LyX --- making new layout files allows a user to create a customized tool for pretty much any sort of document they might wish to work on --- a front-end for LaTeX
- pyspread --- every cell being either a Python program or the output of a program, and the possibility of cells being an image allows one to do pretty much anything without the overhead of making or reading a file
- Ipe https://ipe.otfried.org/ --- an extensible drawing program, this really needs a simpler mechanism for that and I'd love to see a tool in the vector drawing space which addressed that --- perhaps the nascent https://graphite.rs/ ?
"Can a demoscene program with a very limited program size visualize (or codegolf program output) something specific?" - asking for nontrivial properties like this usually requires actually running each program, and there are unfathomably many short programs (https://www.dwitter.net/ is a good example of this)
"In cookie-clicker games, is it possible to go above a certain score within a certain number of game ticks using some sequence of actions?" - in all but the simplest and shortest games (like https://qewasd.com), this is at least not efficiently (optimally) solvable using MILP and the like, as the number of possible action sequences increases exponentially
And yet, despite these being really hard (or in the general case, impossible) problems, humans use some heuristics to achieve progress
This is really good. Thank you for this blog post.
Asynchronous code, coroutines, async/await, parallelising problems is my deep interest and I blog about it everyday.
I think the easiest way to parallelise is to shard your data per thread and treat your multithreaded (or multimachine) architecture as a tree - not a graph - where dataflow doesn't need to pass between tree branches. This is similar to the Rust's "no interior mutabiliy" and Rust data structures pattern.
My machine can lock and unlock 61570760 times a second. But it can count to 2 billion in 1 second. So locks are expensive.
I recently worked at parallelising the A* graph search algorithm that I'm using for code generation/program synthesis.
For 16 processes it takes 35 seconds to synthesise a program but with 3 processes it takes 21 seconds. I think my approach to parallelising A* needs a redesign.
We hit Amdahl's law when it comes to parallelising. I need to split up my problem into spaces that don't require synchronization/serialisation.
EDIT: I've mentioned this whitepaper before ("Scalability! But at what COST?") but this whitepaper would be useful reading of anybody working on multithreaded or distributed systems. In summary: single threaded programs can easily be faster and more performant (wall clock time) than multithreaded/multimachine distributed machines, but they don't scale.
I have a rail line right under my apartment, so I built a small computer vision app running on a Rasperry Pi which records each train passing, and tries to stitch an image of it.
This is the best resource I've found on make to get a low friction build system up and running. Some parts are a bit dense if you're relatively new to make or used to someone else setting it up for you, but if you have the gnu make manual side-by-side for reference you should be good to go:
If you've ever been frustrated with how time consuming it is to manually write make rules then the above method will probably be a night-and-day difference from what you're used to.
I'd also strongly suggest either disabling builtin implicit rules with -r or reading up on all of them here:
Well, for these particular challenges, we're all on a Discord server (https://discord.gg/createwithclint), and these are semi-regular community challenges. There are also smaller weekly competitions, but these are the big community collabs:
If you're looking for a "menu" of papers from various subfields, I've been collecting a list of all best paper awards from a set of 30 computer science conferences for the past 25 years. This is just a personal interest of mine, and is a long page with no ads or upsell.
These are papers that were deemed "best papers" in that year, though obviously may not have turned out to be as influential in retrospect, i.e. they're likely not the papers we consider "best" when looking back today.
Evan Chen is a very valuable person in the Math Olympiad scene.
The Geometry book [1] he wrote in high school is required reading for any serious competitor and I believe he is the main responsible for some bringing some techniques into the olympic meta, such as Barycentric Coordinates.
Also, his blog post [2] about writing is one of the best ones I've ever read.
Nicky's work is a joy and a blessing - one of a small number of great artists and creators online playing with systems and simulations in attempt to educate people through experimentation and play.
If anyone else can recommend other writers or makers in this area, I'd love to hear about them! It's an area that I really enjoy and I hope to contribute to when I have a bit more free time.
[edit] also I'm happy about the fact that Nicky's work often has to do with systems theory, which is one of the biggest remaining frontiers of human understanding in the universe.
Exactly. (Fixed objective time) -> (current subjective time) is a problem with enough nuances that you probably don't want your format making assumptions for you.
So yes, hundreds of people can edit a string and produce a coherent result at the end. Contiguous runs of characters will stick together and interleave with concurrent edits.
The repo includes a DESIGN.md file that describes the design motivations for the library, and it's definitely worth reading. It goes through a few really powerful techniques for writing misuse-resistant APIs, and I think some of its advice is applicable to good software engineering in general.
In particular, their use of the type system to expose opaque types that only allow meaningful operations on them is something that I've seen used to great effect in other statically typed languages, like Haskell.
This is reminiscent (in scope for errors, not mechanism) as the problem from a few years back with the Xerox machines that would alter the text of copies:
If you want a great experience and have 15 minutes to spare, http://www.firstmenonthemoon.com/ has synced up the key radio channels, the video, and the transcripts of the radio traffic (with explainers for acronyms) in real time. I tense up every time as they hit the various go/no go calls.
https://www.acquired.fm/episodes/berkshire-hathaway-part-i
https://www.acquired.fm/episodes/berkshire-hathaway-part-ii
https://www.acquired.fm/episodes/berkshire-hathaway-part-iii
That said, I'll note this quote from Buffett:
>“I'm somewhat embarrassed to say that Tim Cook has made Berkshire a lot more money than I've ever made,” Buffett told the audience, referencing the remarkable 680% surge in Apple's stock since Berkshire first began acquiring shares in early 2016.
https://finance.yahoo.com/news/warren-buffett-says-embarrass...