! is supported

Vim’s command line, i.e, commands starting with :. The vanishingly few it does support are, again, only the most basic, surface-level commands (and some commands aren’t even related to their vim counterparts, like :cwindow, which doesn’t open the quick fix list since the extension doesn’t support that feature).

Your experience is out of date.

The last commit to the supported features doc was 5 years ago, so no, it isn’t. Seriously, you can’t possibly look at that doc and tell me that encompasses even 20% of vim’s features. Where’s the quick fix list? The location list? The args list? The change list? The jump list? Buffers? Vim-style window management (including vim’s tabs)? Tags? Autocommands (no, what it has does not count)? Ftplugins? ins-completion? The undo tree? Where’s :edit, :find, :read [!], and :write !? :cdo, :argdo, :bufdo, :windo?

Compared to what vim can do, it is absolutely a joke.

I use a different tool, visidata. It’s especially nice when used as a psql pager.

A text editor isn’t the right tool for editing tabular data, imo.

As for KaTeX, what I would do is have a preview process running outside of vim that watches for changes in source files and re-renders. That’s the Unix way of doing things.

There’s many very basic features of vim that VsVim does not have (like… almost all command line commands), basic features which regular vim users use all the time.

You seem to think that people using vim emulation is the norm and using vim itself is the exception and unusual… Which is very much not the case. The opposite is true, with VsVim users being a minority. It’s relatively novel among vscode users (most just use a mouse and maybe a small handful of built-in shortcuts), whereas vim itself is quite ubiquitous in the Unix world, with many Linux machines even providing it as the default editor. I know many vim and emacs users (including lots that I work with), and maybe 1 VsVim user (honestly not even sure if they do).

And I was expanding on my original comment, which was not replying to you, so there you have it.

It’s speed, but it’s also flow and a continuous stream of thought. If all your editing is being done with muscle memory and minimal thought, you can continue thinking about the problem at hand rather than interrupting your thoughts process to fumble through some context menu to make a change.

Yeah it sounds like you’re trying to mock me but it mostly just comes across as confusing. Maybe it’s just sarcasm? Hard to tell.

Anyway, it’s pretty well-known in the vim community that VSVim is pretty lackluster vim emulation. There are much better examples of vim emulation out there, such as evil for emacs.

It honestly has nothing to do with being a “power user”. It’s simply false to claim that vscode has more features than vim (which is what the parent comment was claiming), and this should be evident to anyone with more than the most basic, surface-level understanding of vim (more than vimtutor, basically). Vim is a lot more than HJKL and ciw.

I’m not annoyed with VsVim really since I honestly don’t really think about it as it’s not all that relevant. I do find it a bit irksome when people make false or misleading claims about vim from a place of ignorance about what it actually is.

It’s a strange phenomenon with vim in particular, where many people are exposed to it at their periphery, read some reductive claim about it online, and parrot said claim all over the place as though it were fact. Perhaps the nature of being a tool that most are exposed to but few actually learn.

I made this mistake for ages because Haskell is so popular and it’s functional and pure, but it’s not actually a requirement for functional languages to be pure. OCaml isn’t.

I didn’t say that FP languages have to necessarily be pure, just that FP languages tackle the problem of mutation by arranging programs such that most things are typically pure and side effects typically happen at the periphery (logging is probably the one exception, though). This is true even in FP languages that allow arbitrary side effects in functions, it’s just not enforced by a compiler.

I agree Rust code has a different feel to OCaml code but that’s because it makes some things easier (e.g. mutation, vectors). You still could write Rust as if it was OCaml (except for the lack of currying), it’s just that nobody does that because it sucks.

That’s the entire point, though. It’s all about what the language emphasizes and makes easy to do. If it’s unnatural to write a functional program in Rust and no one does it, then it’s not really reasonable to call it a functional language. Writing functional programs is not idiomatic Rust, and that’s okay.

Fundamentally it’s a language oriented around blocks of statements rather than composition of expressions. Additionally, it takes a different approach to the mutation problem than FP languages: where FP seeks to make most things pure and push mutation and side effects to the edges of the program, Rust uses its type system to make such mutation and side effects more sane. It’s an entirely different philosophy when it comes to programming. I don’t think either approach is necessarily better, mind you, just a different set of tradeoffs.

I’m a professional Haskell developer and am very much immersed in FP. When I read Rust code, I have to completely shift my thinking to something much more imperative. Whereas if I read, say, Ocaml, the difference is mostly syntactic. This isn’t a slight, mind you. I quite like Rust. But it’s a very different paradigm.

It’s not a functional language at all, even if it borrows ideas from FP languages. It’s an imperative language through and through.

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.

This is completely different from electron. Nix dependencies will be shared if they share the same hash. Electron just blindly copies everything over every time.

Your post only showed adding functionality over the algebra, not new types on which the algebra operates (or “sorts”, as they are otherwise known). In other words, you can’t easily extend Expr to support Boolean logic in addition to addition itself. For a concrete example, how could you represent ternary operators like in the expression 2 + 2 == 4 ? 1 : 2, such that it’s well typed and will never result in an exception? With GADTs, this is very simple to do:

data Expr a where
  Lit :: Int -> Expr Int
  Add :: Expr Int -> Expr Int -> Expr Int
  Eq :: Expr Int -> Expr Int -> Expr Bool
  If :: Expr Bool -> Expr Int -> Expr Int ->  Expr Int

eval :: Expr a -> a
eval expr = case expr of
  Lit n -> n
  Add a b -> eval a + eval b
  Eq a b -> eval a == eval b
  If p a b -> if eval p then eval a else eval b

-- >> eval example == 1 => true
example :: Expr Int
example =
  If ((Lit 2 `Add` Lit 2)  `Eq` Lit 4) (Lit 1) (Lit 2)

This is a very common toy example we use in Haskell, though honestly this OOP version leaves a lot to be desired, comparatively

The issue is that it tries to shoehorn separation of data and functions on data into a paradigm that’s fundamentally about fusing those two things together.

Here’s the Haskell version. Note how much simpler it is because data and functions are separate:

data Expr
  = Lit Int
  | Add Expr Expr

eval :: Expr -> Int
eval expr = case expr of
  Lit n -> n
  Add a b -> eval a + eval b

print :: Expr -> String
print expr = case expr of
  Lit n -> show n
  Add a b -> "(" ++ print a ++ " + " ++ print b ++ ")"

Typescript can do something similar:

type Expr = {
  kind: 'Lit',
  value: number
} | {
  kind: 'Add',
  left: Expr,
  right: Expr
}

function eval(expr: Expr): number {
  switch(expr.kind){
    case 'Lit': return expr.value;
    case 'Add': return eval(expr.left) + eval(expr.right);
    default:
      const _impossible: never = expr;
      return _impossible;
}

function print(expr: Expr): string {
  switch(expr.kind){
    case 'Lit': return `${expr.value}`;
    case 'Add': return `(${print(expr.left)} + ${print(expr.right)})`;
    default:
      const _impossible: never = expr;
      return _impossible;
}

Both the OOP approach and Typescript itself struggle with additions to the algebra composed of different types, however. For example, imagine extending it to handle booleans as well, supporting equality operations. It’s difficult to make that well-typed using the techniques discussed thus far. In Haskell, we can handle that by making Expr a GADT, or Generalized Algebraic Data Type. That article actually already provides the code for this, so you can look there if you’re curious how it works.

The negative impact a lot of screen time has on kids is very well documented. Basically, even educational shows do basically nothing for young kids. It’s passive and doesn’t help development in any way. Kids benefit a lot more from active exploration, play, and socialization.

“Moral panic” is a phrase reserved for complaints that have no basis in reality.

It’s still grossly negligent from a security perspective.

This is really terrible advice.

I definitely write pseudocode like this, albeit perhaps with some more shorthand. It’s commonly taught this way too.

Last 3 years has been working on large backend web services in Haskell and Postgres, with some shell scripting thrown in here and there.

Before that, it was a mix of Python, Typescript (React), Rust, and C++.

Been using vim+tmux for the last 8 years and still going strong. Wouldn’t ever give it up. Vscode’s pretty lackluster in comparison.

Oh, if you worked at a company that uses them (which is a lot of companies), you’d definitely be familiar with them as they hog up a ton of fucking CPU/disk. I basically had an entire CPU core dedicated to running their bullshit.