Comments by "" (@jboss1073) on "Haskell Is Faster Than C | Prime Reacts" video.

  1. 28:00 - "anything you can write in Haskell, you can write in C" So wrong. That is only true for Von Neumann tapes. In the real-world, and as you admitted in the end of your video, C cannot even make trees - only "trees with fixed internal types" which are "concrete trees" also known as "not trees" because they're not containers.
    1
  2.  @AllanSavolainen  In that sense, we could also make a tree data structure out of grains of sand and holes on the ground. Clearly C does not have facilities to allow for an abstract tree, and you know it. Those facilities could be as little as lambda calculus.
    1
  3.  @AllanSavolainen  All the facilities that an algebraic language would give you in this instance; for example, in C you could very easily accidentally point one of those tree pointers to something that isn't part of a tree; in other words, C doesn't understand what you're doing. Whereas an algebraic language will understand the simple functional math behind your definition of Tree and know from the algebraic type signature that only certain things can be there. Nothing in nominal languages fixes this. Algebra is needed.
    1
  4.  @AllanSavolainen  I am talking about the same algebraic type checker that Rust uses, for example. No matter the library, in C, it will never understand what a tree is. Whereas in any language like Rust, the compiler will actually understand it algebraically and track all errors quite easily and without further complications. C requires you to do all that machinery yourself. If only it understood algebra of lambda calculus, but it doesn't.
    1
  5.  @AllanSavolainen  No one is disputing you couldn't do the same computation. But in C, your problem domain is the entirety of the implementation of the tree and the teaching to the compiler of what goes and doesn't go in trees. Whereas in Rust your problem domain is from algebra up, so it already understands algebraic operations and you c an simply build a tree out of those algebraic operations combined. In C, there is no such vocabulary to talk about abstract types. If you truly do not understand this, you should read up on Functional Programming, because you're missing a huge part of Computer Science.
    1
  6.  @AllanSavolainen  I had already said before that every computation could be done with grains of sand and holes on the ground. But C can never be taught what a Tree type is, unlike any algebraic language, like Rust.
    1
  7.  @AllanSavolainen  "so if I have a tree in C made of struct nodes, it isn't typed?" Correct, it is not typed. C does not have Computer Science Types, it has Computer Science Tags. Types are the elements of Type Theory in Computer Science, where Functions are Paths between the Types. "Could you give a concrete example of something tree-like that C cannot do?" Yes, C cannot inherently understand algebraic types such as a variant tree that might have different branches and leaves with varying structures. For example, in languages that support algebraic data types, like OCaml or Haskell, you can define a tree where each node can be either a Leaf with some value or a Branch that connects two subtrees, and the compiler will enforce those distinctions across the entire program. The compiler understands the structure and can infer or enforce the proper type usage without additional effort on your part. In C, you would need to use structs and manually manage the interpretation of the tree. C doesn’t understand the tree as a singular type—it only sees the individual fields within the structs. You would have to implement all the logic yourself, handling pointers and manually verifying which type of node you're dealing with. There's no automatic pattern matching or type safety for these variant-like structures. Hence, a concrete example of something tree-like that C cannot do is an algebraic tree where nodes can hold different types of data, such as a variant tree with different node types like Leaf Int, Leaf String, or Branch (Tree, Tree). In a language with algebraic data types, the compiler can enforce that only valid branches and leaves are combined in accordance with the defined type. It will also automatically handle different operations depending on the specific form of the node. C, on the other hand, has no concept of enforcing this; you would need to implement all validation, type checking, and interpretation manually, with no built-in language support for pattern matching or managing the tree in a type-safe manner. So in C you can never truly get a Tree, which is a well-defined Type in Type Theory within Computer Science - it is defined abstractly solely by its operations. In a language that understands true types, the tree's behavior and structure are inherently tied to the rules of the type system. Operations like traversals, insertions, or transformations are governed by the formal type system, ensuring that the operations remain valid and consistent within the type's definition. C, however, lacks the mechanisms to define such abstract types. It relies on tags (e.g., struct, enum, int, double), but those are just labels for data or groups of data; they don’t carry the semantic weight of a true type. A "tree" in C is just a collection of pointers and structs with no deeper understanding by the language of what makes a tree a tree. The compiler doesn’t know about the invariants or rules that are essential to the abstract concept of a tree; those are left entirely to the programmer to enforce manually. This is a fundamental difference between a language like C, which deals with memory layout and tagging, and languages with algebraic types that embody the abstract, rule-based nature of true types.
    1
  8. A linked-list is not a tree.
    1