;; Getting rid of explicit indexing was just step one.
-- After a few days/months/years, I now realize that it is more important and less buggy if I think only of the function to call (and whether I want to end up with a new (maybe pruned) collection, a single thing, or "both" (that's how I think of scans))
I do know that maps/folds/etc. can be generalized to anything belonging to the functor class in #haskell; so things like trees and other "container" type things beyond just lists. However, I didn't want to introduce special terminology in what was otherwise free of such jargon.
As for the rest of what you said, I don't know enough category theory to understand what you meant, although I can recognize them as being category theory terms.
Thanks for pointing out the connections. Hopefully, one day I'll get to a level of understanding where I can grok what you said.
@aksharvarma I was just yes-and-ing your post with what I think is the next step.
There's definitely categorical jargon, but that's how you fit the idea into 500 characters.
Basically every "container" type is recursive: some trivially [e.g. (a,a)] and some in much more interesting ways. Each of the "layers" is a (categorical) functor, the container is just a fixed-point (recursive self-call) of that functor.
The right solution is using the type-system to prevent obviously wrong code from compiling:
✅ join(AbsolutePath, RelativePath)
✅ join(RelativePath, RelativePath)
❌ join(RelativePath, AbsolutePath)
❌ join(AbsolutePath, AbsolutePath)
Another benefit is that AbsolutePath is not restricted to the root of the filesystem, but could express things like "the user's cache directory", increasing portability of paths saved to config files.
🧏 People who code have a tendency to spend a lot of time in various IDEs (Integrated Development Environments). They can be as simple as a text editor or as complex as a full-blown development environment. In this post, I'll go through my two go-to IDE's, RStudio and VScode, and why I switch between them rather than sticking to a single one. ---
@Drmowinckels I realised I had all but turned VSCode into vim anyway due to the extensions I am using. And (neo)vim is much more free in terms of how you can create your own tools and automations. For VSCode (and RStudio actually) you’re expected to write and publish a package that contains your extension. It slows things down somewhat. In Vim you just source some code and now things work differently.
I also have some frustration with VSCode’s design - you can’t avoid a mouse completely.
@Drmowinckels Nice post! For me the other "killer app" of VS Code (besides git support) is running instances within docker containers (which could be on a server). Feels identical to working locally.
Personally I've switched 100% to VS Code for my own work. I only use RStudio for teaching. The combination of RStudio plugins in VS Code and my own shortcuts make it fine for package development in my experience.
The CPU intensive part of the job finishes in less than two minutes. It then takes 6-12 additional minutes back on the main thread to handle all the data that those other threads produced.
• Forgetting to pass a custom class that’s persisted in your database in your JSDB.open() call now throws instead of corrupting your database by falling back to using an untyped object.
• Added JSDF ver. 2 to 3 database migration script (i.e., JSDB version 2-4 to 5)²
Come and help us maintain and enhance a fully open-source operating system and cloud stack that has been battle-tested in very large production environments.
There are plenty of interesting problems to solve, all the way from writing device drivers and debugging early boot issues, to writing new UIs in Rust.
I think we're a pretty friendly team to work alongside too ;)