It's how recruiters find me, so unfortunately I can't. I almost never open it, though.
Vim is extremely feature-rich, and people that think otherwise don't really know how to use vim. Saying vim doesn't have a lot of features is just a meme that isn't true.
Also, the vim plugin for vscode is kind of a joke compared to what vim can do. It's very "surface-level" with minor emulation of some of the common keybinds.
I'm not saying we go high. By all means, rip into them. The Harris campaign is doing a great job of that, using the truth. There's so much ammunition that the lies are just a drop in the bucket and serve no real purpose other than distortion. It's just pretty pointless.
No, the legacy of HJKL in modern tools comes from vi, which itself uses them because the original ADM-3A terminal that Bill Joy used when developing it used HJKL in lieu of arrow keys.
vi was hugely influential and its legacy can be found in many tools beloved by software engineers and other tech-minded folks (and vi's successor, vim, is still widely used to this day).
It's not a terrible name, since it's derived from the mathematical construct of vectors as n-tuples. In the case of vectors in programming, n relates to the size of the underlying array, and the tuple consists of the elements of the vector.
The tooling has improved dramatically since then. There's now a full-fledged language server (https://haskell-language-server.readthedocs.io/en/stable/), ghcup (https://www.haskell.org/ghcup/) is now a thing for installing/managing different versions of GHC/cabal/HLS, there's now formatters (https://github.com/tweag/ormolu) and cabal has modernized significantly and supports multi-package projects much more comfortably now. Nix-based Haskell infrastructure is also now pretty nice. There's even stuff like https://github.com/srid/haskell-template/blob/master/flake.nix to very quickly get spun up on a new project using Haskell and nix, including vscode, formatter, HLS, and a full development shell with a bunch of useful commands.
Another great modern thing (which powers HLS) is that GHC can now emit .hie files for each file it compiled, which is basically a standardized representation of the AST for that module that can be consumed/manipulated programatically. Lots of tools can use this. One such tool that's particularly useful is https://github.com/wz1000/HieDb, which constructs an sqlite database from the information in these files, so you basically can have an index of every symbol definition, reference, export, etc. all readily available to use however you want.
Yeah it's pretty great, especially when so many people are so quick to assume that OOP is essential for managing complexity.
OOP is the poster child for solving the problems that it creates itself.
I know nothing about this topic, but a quick Google did give me this https://crates.io/crates/mfcc, which looks like it might do what you're after?
Those are definitely all HSA things, and something I use mine for all the time. Dunno how it worked for you but I basically just have a debit card I can use that has my HSA balance on it. Functions like any other card.
Yeah, this penny pinching on licenses is pretty absurd. I promise you that it hardly affects the bottom line.
That's not a monad, that's just typeclasses (also known as traits/interfaces/etc.).
If you're familiar with flat_map or and_then in Rust, you already get the basic idea of monads. Just imagine that instead of the ad-hoc implementations that Rust has to do (since it doesn't support higher-kinded data types), you could express it in a single trait. Then you can write code that generically works with any types that support flat_mapoperations (along with a couple of other requirements, like needing a From<T> impl, as well as abiding by some laws that are really only a concern for library authors).
If that sounds simple, it's because it is. It's mostly just that it just so happens that being able to write code in this fashion has some pretty significant implications. It essentially allows you to very strictly control the semantics of sequencing operations, while still giving you enough flexibility to enable many of the things you typically do in imperative programs. In a language like Haskell which is built on monads, it's a very powerful reasoning tool, much in the same way that purity in functions is a powerful reasoning tool. It allows us to do things like, say, represent async code blocks as first-class concepts requiring no special syntax (no async/await, etc.), because the monad interface allows us to dictate what it means to sequence async actions together (if you're curious to see what this looks like, here's a link to Haskell's Async type from the async library: https://hackage.haskell.org/package/async-2.2.4/docs/Control-Concurrent-Async.html#t:Async).
expr
joined 1 year ago
Interactive rebase? There's no GUI that actually does that well, if at all. And it's a massive part of my daily workflow.
The CLI is far, far more powerful and has many features that GUIs do not.
It's also scriptable. For example, I often like to see just the commits I've made that diverge from master, along with the files changed in each. This can be accomplished with
git log --oneline --stat --name-status origin/master..HEAD. What's more, since this is just a CLI command, I can very easily make a keybind in vim to execute the command and stick it's output into a split window. This lets me use git as a navigation tool as I can then very quickly jump to files that I've changed in some recent commit.This is all using a standard, uniform interface without mucking around with IDE plugin settings (if they even can do such a thing). I have many, many other examples of scripting with it, such as loading side-by-side diffs for all files in the worktree against some particular commit (defaulting to master) in vim in a tabpage-per-file, which I often use to review all of my changes before making a commit.