• 0 Posts
  • 231 Comments
Joined 1 year ago
Cake day: July 3rd, 2023
  • expr@programming.devtoLefty Memes@lemmy.dbzer0.com•DiscussionEnglish
    457·
    25 days ago

    Exactly, heavy taxation on the ultra wealthy and wealth caps are incredibly popular topics in liberal circles. I swear some people have never actually talked to a liberal and just attack some strawman they’ve lumped in together with conservatives.

    I’m leftist and anti-capitalist, but I also recognize that most liberals are people who want the same things leftists do, but simply haven’t thought deeply enough about what the true root causes of society’s issues are. It’s an issue of tactics rather than a fundamental disconnect in core principles and values. Ultimately they want a more equitable, less stratified society where society helps and supports the disenfranchised. The same thing leftists want. They just don’t understand that capitalism has to go in order to achieve it.

    Liberals, unlike conservatives, are actually generally quite reasonable people since they aren’t motivated by hatred. As leftists, we should be doing everything we can to educate them and bring them into the fold, rather than tearing them down.

  • expr@programming.devtoRust@programming.dev•Strategy Pattern in Rust
    2·
    3 months ago

    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.

  • expr@programming.devtoRust@programming.dev•Strategy Pattern in Rust
    3·
    3 months ago

    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.

  • expr@programming.devtoRust@programming.dev•Strategy Pattern in Rust
    32·
    3 months ago

    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).

  • expr@programming.devtoProgramming@programming.dev•[self post] Extensible TypeScript with Object Algebras
    1·
    3 months ago

    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)
  • expr@programming.devtoProgramming@programming.dev•[self post] Extensible TypeScript with Object Algebras
    2·
    3 months ago

    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.