Tweets

You blocked @TimSweeneyEpic

Are you sure you want to view these Tweets? Viewing Tweets won't unblock @TimSweeneyEpic

  1. Congrats to Godot for showing that a pemissively licensed open source 3D engine can succeed at scale!

    Undo
  2. Feb 1

    The goal of a high level programming language is to be something that we and these alien civilizations could agree on as universal and principled, and free of quirks and arbitrarity.

    Show this thread
    Undo
  3. Feb 1

    We’d have transactions as a way of running concurrent operations atomically. We’d have most of Knuth’s algorithms in common (maybe they’d have some major breakthroughs we lack!)

    Show this thread
    Undo
  4. Feb 1

    So, let’s ask: what parts of programming would we have in common? We’d share the mathematical integers, and data structures analogous to Cartesian products (structs) and sums (unions), and functions with side effects, and pure functions as a special case.

    Show this thread
    Undo
  5. Feb 1

    Now we compare programming languages. We’d find some low level constructs have developed very differently. Maybe they’d have balanced tertiary numbers instead of twos-complement and u-law fractional numbers instead of floating point. Our bitwise ops may have no analog.

    Show this thread
    Undo
  6. Feb 1

    But mathematics would be shared. After translating syntax and symbols, we’d find we had exactly the same constructive axioms, and agree that other axioms are controversial. We’d have the same theorems and the same proofs. They’d rever a Pythagoras and a Leibniz.

    Show this thread
    Undo
  7. Feb 1

    Spoken language would be inscrutable. Different physiologies would lead to an inability to speak or even hear each others’ phonemes. Written language would be inscruible, though we might find analogs of nouns, adjectives, and verbs.

    Show this thread
    Undo
  8. Feb 1

    Here’s an exercise in separating fundamentals from conventions: if we held a technical summit with all of the galaxy’s advanced alien civilizations, what would we find we had in common, and what would we find inscrutable?

    Show this thread
    Undo
  9. Feb 1

    Programming languages should be built on principles first and foremost, and avoid conveniences that violate principles. So much of what’s wrong today is the result of design by “wouldn’t it be nice if” without an earnest enumeration of guiding principles.

    Show this thread
    Undo
  10. Feb 1

    If we support floating point, then the float 1.0f can’t be equal to integer 1, because there exist functions f where f(1.0f) is unequal to f(1), and a==b implies that for all f, f(a)==f(b). We must either say 1 is not equal to 1.0f, or that we aren’t allowed to compare them.

    Show this thread
    Undo
  11. Feb 1

    Finally, types should obey the mathematical properties expected of them. This means we must adopt mathematical integers, and if we support smaller integer storage formats, they are still just for storage. The byte 255 plus the byte 1 is not the byte 0, it’s the integer 256.

    Show this thread
    Undo
  12. Feb 1

    Next, we have to abandon manually synchronized memory concurrency. The combinatorial complexity here isn’t in performance but in programmer reasoning. We must either stay single-threaded or adopt purely functional programming or transactions.

    Show this thread
    Undo
  13. Feb 1

    The other is we should never copy a non-constant-sized data structure, but ensure it can be used in all contexts as-is or with the help of a constant sized adapter.

    Show this thread
    Undo
  14. Feb 1

    One is that containers should be designed to minimize asymptotic complexity of operations. If concatenating strings is O(m+n), we’re doing it wrong. This means we can’t expect nice linear arrays in memory, but must pay some sort of dynamic control flow cost for accessing them.

    Show this thread
    Undo
  15. Feb 1

    The ideal performance property we should ask of a high-level programming language and library is that it minimizes runtime and compile-time combinatorial complexity. We can accept constant overheads, but not higher-order overheads. This has many implications.

    Show this thread
    Undo
  16. Feb 1

    Unfortunately, most languages missed this opportunity. The C family including C# and Java are overly imperative and lost variance due to wrongly-scoped mutability. And functional languages have generally chosen type systems lacking subtypes, covariance, and contravariance.

    Show this thread
    Undo
  17. Feb 1

    But if we have garbage collection, we can store our large data structures once with whatever type is required, then dynamically create wrappers that reinterpret it as any subtype that’s required. We pay the cost of GC and indirect control flow for accessors but that’s all.

    Show this thread
    Undo
  18. Feb 1

    Or we can create a very clunky wrapper like array_of_anything that is used wherever generic types are required, which manually casts and converts values among types dynamically each time it’s accessed. Java generics did this and they were awful.

    Show this thread
    Undo
  19. Feb 1

    So now when we want to recover performance, we need to write all containers and their operations using an increasingly elaborate set of templates or generic functions, which the compiler must specialize for each type at significant cost. This is what C++ and Rust do.

    Show this thread
    Undo
  20. Feb 1

    Without garbage collection, offering an array of bytes where an array of integers is required requires stack-allocating an array of integers and converting each byte to an integer every time a subtype is used in place of an actual type. This is so absurd that it’s not done.

    Show this thread
    Undo

Loading seems to be taking a while.

Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.

    You may also like

    ·