Publish a blog at https://orlp.net/blog/.
Other socials:
http://github.com/orlp/
https://stackoverflow.com/users/565635/orlp
https://linkedin.com/in/orson-peters/- The person you replied to stated:
> how productive power users in different [fields] can be with their tools
There are a lot more tools in programming than your text editor. Linters, debuggers, AI assistants, version control, continuous integration, etc.
I personally know I'm terrible at using debuggers. Is this a shortcoming of mine? Probably. But I also feel debuggers could be a lot, lot better than they are right now.
I think for a lot of us reflecting at our workflow and seeing things we do that could be done more efficiently with better (usage of) tooling could pay off.
- When "everybody is better", you can still increase your relative rank to other people if you benefit even more.
For example if I were to give $1 to every person on earth, but $100 million to you, everyone would be richer but you would be a lot richer still.
- > Do you have any particular pieces in mind when you wrote this?
(not me, but...)
Bach - Passacaglia & Fugue in C minor, BWV 582
> But one wonders what he could have made without those constraints.
Bach-Busoni - Chaconne from Partita No. 2 in D minor, BWV 1004
- Rust works this way, yes. There are escape hatches though, which allow interior mutability.
- Passive voice deflects responsibility and agency.
Loss happens, firings are a decision.
- No, OSRS is 100 ticks per minute which gives 0.6 second ticks, which rounds to 1.667 ticks per second.
- I'm working on implementing extension types in Polars. Stay tuned.
- Aarch64 does indeed have a proper atomic max, but even on x86-64 you can get a wait-free atomic max as long as you only need to support integers up to 64. In that case you can simply do a `lock or` with 1 << i as your maximum. You can even support larger sizes by using multiple registers, e.g. four 64-bit registers for a u8 maximum.
In most cases it's even better to just store a maximum per thread separately and loop over all threads once to compute the current maximum if you really need it.
- I take it you never wrote code involving atomic pointers. Regardless of memory usage, a lot of platforms only provide single-word atomics (efficiently), making bitpacking crucial for lockfree algorithms.
- > Reliable pointer tagging is not trivial.
It is if you use alignment bits. Not always possible if you don't control the data though.
- Yes. But there is no decider for n-state Turing machines that works regardless of n.
- Well, years back I released an unstable sort called pdqsort in C++. Then stjepang ported it to the Rust standard library. So at first... nothing. Someone else did it.
A couple years later I was doing my PhD and I spent a lot of time optimizing a stable sort called glidesort. Around the same time Lukas Bergdoll started work on their own and started providing candidate PRs to improve the standard library sort. I reached out to him and we agreed to collaborate instead of compete, and it ended up working out nicely I'd say.
Ultimately I like tinkering with things and making them fast. I actually really like reinventing the wheel, find out why it has the shape that it does, and see if there's anything left to improve.
But it feels a bit sad to do all that work only for it to disappear into the void. It makes me the happiest if people actually use the things I build, and there's no broader path to getting things in people's hands than if it powers the standard library.
- I (Orson Peters) am also here if anyone has any questions :)
- As I mentioned in my other comment:
> I'd just like to clarify that I'm not saying this is necessarily the solution the problem writers were looking for, or that it will run within the allocated time. Just that it's a feasible solution.
I don't doubt there's a clever dedicated flow algorithm the problem writers intended instead of the blunt tool which is LP.
- Every developer I've talked to has had the same experience with compilation caches as me: they're great. Until one day you waste a couple hours of your time chasing a bug caused by a stale cache. From that point on your trust is shattered, and there's always a little voice in the back of your head when debugging something which says "could this be caused by a stale cache?". And you turn it off again for peace of mind.
- The team manual I referred to when I was in university does in fact contain such a basic simplex LP solver: https://github.com/ludopulles/tcr/blob/master/tcr.pdf (page 22).
I'd just like to clarify that I'm not saying this is necessarily the solution the problem writers were looking for, or that it will run within the allocated time. Just that it's a feasible solution.
- With all due respect, have you actually used the Polars expression API? We actually strive for composability of simple functions over dedicated methods with tons of options, where possible.
The original comment I responded to was confusing Pandas with Polars, and now your blog post refers to Numpy, but Polars takes a completely different approach to dataframes/data processing than either of these tools.
- It doesn't seem that hard to solve to me either. It's solvable with basic linear programming.
1. Add a variable for each node, and a variable for each output edge from stations. 2. For each reservoir add equality constraints to the sum of incoming edges with the coefficients given in the problem. 3. For each station add equality constraints between the weighted sum of its inputs (which is 1 for the root station) and its outputs (which are the variables we added). 4. Add an out_edge >= 0 constraint for each output edge on stations to forbid illegal negative flows. 5. Add a variable m which is constrained to be less than all the output station variables. 6. Maximize m. - > The creator of duckdb argues that people using pandas are missing out of the 50 years of progress in database research, in the first 5 minutes of his talk here.
That's pandas. Polars builds on much of the same 50 years of progress in database research by offering a lazy DataFrame API which does query optimization, morsel-based columnar execution, predicate pushdown into file I/O, etc, etc.
Disclaimer: I work for Polars on said query execution.
I almost never even think about the borrow checker. If you have a long-lived shared reference you just Arc it. If it's a circular ownership structure like a graph you use a SlotMap. It by no means is any harder for this codebase than for small ones.