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.

It can be nice when you successfully do a rebase (after resolving conflicts), but change your mind about the resolution and want to redo it.

Doesn’t come up that much, but it’s been handy once or twice, for me. It’s also just nice security: no matter how I edit commits, I can always go back if I need to.

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.

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.

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.

A language is not functional just because it supports higher order functions. Technically C even supports them (even though the ergonomics and safety of them are terrible). Would you call C a functional programming language? Obviously not. Rust is also not a functional language, even though it comes closer than most OO/imperative languages.

Kotlin and plenty of other OO languages have borrowed some ideas from functional languages in recent years because those ideas are useful. That doesn’t make them functional languages. If Kotlin were a functional language, then it wouldn’t need libraries like arrow to try to make doing FP in Kotlin even (kind of) possible.

Hallmarks of FP (beyond higher-order functions), in no particular order:

• Organization around functions as the fundamental unit of code
• Code primarily defined in terms of expressions and data transformations rather than statements manipulating object state (so languages that have big blocks of imperative statements like Kotlin don’t count)
• A general orientation around pure functions, even if they vary on the degree to which they enforce purity
• Explicit parameter passing being the standard and preferred way of providing data to functions, rather than methods operating on implicit state
• First class support for function composition (method chaining doesn’t count)
• Pattern matching and destructuring as a first-class and ubiquitous concept (what Kotlin does have is a joke comparatively and no one would actually call it that)
• For statically-typed functional languages, first class support for algebraic data types (Kotlin has sealed classes which can kind of be used to try to emulate it, but it’s pretty awkward in comparison and requires you to write very OO-ish code to use)

There are some minor exceptions, such as Clojure lacking pattern matching, but on the whole functional languages generally fit these descriptions.

That list also counts Java and C# as “functional languages”. I wouldn’t take it too seriously. Ocaml, Scala, F#, etc. are impure functional languages. Kotlin absolutely is not. Having a couple of features you might find in functional languages does not make a language functional. Kotlin is still very much an OOP-based language. It’s basically a somewhat nicer Java.

Minor nit: Kotlin is decidedly not a functional language.

Design patterns in OOP exist purely to solve the problems created by OOP itself. If you have a language with proper ADTs and higher order functions, the need for traditional design patterns disappear since the problems they solve are first-class features baked into the language.

The first-class replacement for the Strategy pattern (and many other patterns such as the Visitor pattern) is sum types (called enums in Rust).

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.

Any examples of the claim that he’s embraced FP more?

Last I saw, he was making wild, baseless assertions about FP concepts like monoids and monads on Twitter.

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.

Yeah. Anduril has tried to hire me multiple times as well as well as a number of people I know (their software is written in Haskell, which is a somewhat niche skill set).

Every time I’ve told them absolutely not.