It’s definitely not faster than vim, fwiw.

What do you mean “build our dev environments around vim”? If you mean they write dev tooling in vimscript and explicitly require everyone to use it, I actually agree with you. I don’t believe employers should really ever force any particular editor or IDE if the work is getting done. I would be equally annoyed by a workplace forcing me to use vscode instead of vim. It would slow me down way too much.

If you are just complaining that they build dev tooling as a CLI, hard disagree. That is absolutely what dev tooling should use because it’s actually universal and can be used regardless of your editor choice.

At my workplace, our dev tooling is done via CLI and our developers use vim, emacs, and vscode. Because it’s all CLI, it’s easy for individual developers to add their own scripts to automate parts of their workflow as they see fit (and if such automations are deemed useful by the group at large, it will get merged into our shared devtools repo). We even have some editor-specific stuff in there people have written that they find useful, but it’s entirely optional.

Vscode definitely can’t handle large files like vim can. I can open files that are multiple GBs in vim without issue. Vscode definitely cannot.

xattr -d com.apple.quarantine path/to/file will remove that shit.

Though personally, I get as much software as possible on my work MacBook through Nix, and only use .dmg files if absolutely required.

So… Rust?

Not sure if serious or not, but yeah I use interactive rebases every day, many times a day (it’s nice for keeping a clean, logical history of atomic changes).

It’s very simple to recover if you accidentally do something you don’t intend (git rebase --abort if the rebase is still active, git reflog to find the commit before the rebase if it’s finished).

Never understood why this is such a trope. There’s very little you can’t recover in git (basically, only changes you never committed in the first place).

Unless you’re writing Scala or something (which is probably the one exception to the rule), if you are using a language that supports OOP, you’re not really doing functional programming. Functional-esque features that have made their way into imperative languages like map are only a tiny fraction of the functional toolbox.

There’s a bunch of features you want in a language to do functional programming, and imperative languages don’t really have them, like purity by default (and consequently, an orientation towards values rather than references) ergonomic function composition, algebraic data types, pattern matching, support for treating everything as first class expressions/values, etc.

Perhaps this is presumptious (and I apologize in advance if so), but I’d wager you haven’t truly programmed in the functional paradigm. What imperative programmers tend to think of functional programming is very surface-level and not really reflective of what it actually is. It’s an entirely different beast from imperative programming. It requires a shift of your mindset and how you think about programs as a whole.

Source: Senior software engineer writing Haskell full time for the last 4 years. Will avoid OOP until my dying breath.

It basically does. It pretends to court functional programming while actually being really antithetical to it in basically every way. Guido Van Rossum has vocally expressed his dislike for functional programming (though I’d argue he actually doesn’t really know much about it).

For Haskell:

1. I’d say this is definitely a wtf. Tuples should have never been given Foldable instances and I’d immediately reject any code that uses it in code review.

2. I actually didn’t know, so TIL. Not surprising since common wisdom is that a lot of the type class instances for Doubles are pretty weird/don’t make a lot of sense. Just like in any language, floating point needs special care.

3. This is jjust expected syntax and not really a wtf at all. It’s very common for languages to require whitespace around operators.

4. Agreed as wtf, the NegativeLiterals should be on by default. Just would be a pretty significant breaking change, unfortunately

5. Not a wtf… What would you expect to happen? That operation is not well-defined in any language

Mutating function arguments is pretty wtf to begin with.

Nah, neovim made too many breaking changes and prioritizes the wrong things. I’d much rather the spirit of vim continue, albeit with a better organizational structure.

Reviewers are not infallible and are largely focused on the meat of the MR rather than every single detail.

It reflects much more poorly on you than it does on them.

Don’t need the Ord instance for equality, just Eq is sufficient. Ord is for inequalities.

The point of the post is that most mainstream languages don’t provide a way to automatically derive point-wise equality by value, even though it’s pervasively used everywhere. They instead need IDEs to generate the boilerplate rather than the compiler handling 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.

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.

Common Lisp isn’t a functional programming language. Guile being based on Scheme is closer, but I’d still argue that opting into OOP is diverging from the essence of FP.

Just remember that if you aren’t actually concatenating files, cat is always unnecessary.

https://porkmail.org/era/unix/award#cat

jq < file.json

cat is for concatenating multiple files, not redirecting single files.

Meanwhile, I can open a 1GB file in (stock) vim without any trouble at all.

Formatting is what xmllint is for.