[–] 21 points 5 days ago (9 children)

Baldur's Gate 3 and Expedition 33

First one is a great game, but combat is not the most important feature of the game IMHO.

The other is very good, and the combat is more relevant.

I think that the engagement is being able to build a strategy on how to win, instead of rely more on reaction.

  • source
  • [–] 57 points 2 weeks ago* (6 children)

    The idea itself is good... But his defense strategy is even better: they are denying that he even had the duress code configured. The accusation must be able to prove he had, and I think proving it will be very hard to do.

  • source
  • parent
  • context
  •  

    I think most of my comments and error messages are written in Portuguese, but this is only a prototype, so please ignore that.

    Kata manages memory with per-fiber bump arenas backed by structured concurrency — no garbage collector, no borrow checker, no reference counting; escape analysis decides at compile time whether each value stays local or escapes to the caller's arena, and ; in actions distinguishes "local computation" from "value that escapes." Refined types (data (Int, > _ 0) as PositiveInt) carry logical predicates validated at compile time, participate in multiple dispatch, and can delegate interface implementations to their base type through refines — a fallback mechanism with no equivalent in Rust or Haskell. The pure/impure boundary is not a monad you thread through your code — functions (lambda) and actions (action) are separate syntactic domains with their own structural rules, enforced at compile time; where Haskell tracks purity through IO as a type-level effect, Kata makes it a property of the syntax you write.


    Memory

    • Kata: Per-fiber bump arenas + escape analysis; no GC, no borrow checker

    • Python: Refcounting + cycle GC

    • Haskell: Tracing GC

    • Rust: Ownership + borrow checker


    Refined types

    • Kata: data (Int, > _ 0) as PositiveInt — predicates validated at compile time, participate in dispatch, refines delegates interfaces to base

    • Python: Not available

    • Haskell: Liquid Haskell (external plugin, not core)

    • Rust: Not available


    Purity

    • Kata: Physical barrier: separate syntax, operators, structural rules

    • Python: Not enforced

    • Haskell: Monadic IO (type-level effect)

    • Rust: Not enforced


    Conditionals

    • Kata: Pattern matching + guards (exhaustiveness enforced)

    • Python: if/elif/else

    • Haskell: if + pattern matching

    • Rust: if + match


    Backend • Kata: Cranelift JIT/AOT (native, no VM)

    • Python: CPython interpreter

    • Haskell: GHC (LLVM/native)

    • Rust: LLVM (native)

    The repo is at github.com/ArthurJ/Kata — build with cargo build, then try kata repl, kata run examples/, or kata test. I'd love feedback on the language design: what feels right, what feels wrong, what you'd do differently.

    action greet (name::Text) => Unit
        echo!(+ "Hello, " (+ name "!"))
    
    action main
        greet!("World")
        greet!("Kata")
    
    main!()
    
    enum BMI
        Underweight(< _ 18.5)
        Normal(<= _ 25.0)
        Overweight(<= _ 30.0)
        Obese
    
    action main
        echo!(BMI 17.0)
        echo!(BMI 22.0)
        echo!(BMI 27.0)
        echo!(BMI 35.0)
    main!()
    
    fizzbuzz :: Int => Text
    lambda x:
        both: "FizzBuzz"
        fizz: "Fizz"
        buzz: "Buzz"
        otherwise: show x
        with
            fizz := divisible x 3
            buzz := divisible x 5
            both := and fizz buzz
    
    
    divisible :: Int Int => Boolean
    lambda x n:
        match div x n
            Ok q: = x (* n q)
            Err _: Boolean::False
    
    
    action main
        for i in [1..16]
            echo!(fizzbuzz i)
    
    
    main!()
    
     

    I think most of my comments and error messages are written in Portuguese, but this is only a prototype, so please ignore that.

    Kata manages memory with per-fiber bump arenas backed by structured concurrency — no garbage collector, no borrow checker, no reference counting; escape analysis decides at compile time whether each value stays local or escapes to the caller's arena, and ; in actions distinguishes "local computation" from "value that escapes." Refined types (data (Int, > _ 0) as PositiveInt) carry logical predicates validated at compile time, participate in multiple dispatch, and can delegate interface implementations to their base type through refines — a fallback mechanism with no equivalent in Rust or Haskell. The pure/impure boundary is not a monad you thread through your code — functions (lambda) and actions (action) are separate syntactic domains with their own structural rules, enforced at compile time; where Haskell tracks purity through IO as a type-level effect, Kata makes it a property of the syntax you write.


    Memory

    • Kata: Per-fiber bump arenas + escape analysis; no GC, no borrow checker

    • Python: Refcounting + cycle GC

    • Haskell: Tracing GC

    • Rust: Ownership + borrow checker


    Refined types

    • Kata: data (Int, > _ 0) as PositiveInt — predicates validated at compile time, participate in dispatch, refines delegates interfaces to base

    • Python: Not available

    • Haskell: Liquid Haskell (external plugin, not core)

    • Rust: Not available


    Purity

    • Kata: Physical barrier: separate syntax, operators, structural rules

    • Python: Not enforced

    • Haskell: Monadic IO (type-level effect)

    • Rust: Not enforced


    Conditionals

    • Kata: Pattern matching + guards (exhaustiveness enforced)

    • Python: if/elif/else

    • Haskell: if + pattern matching

    • Rust: if + match


    Backend • Kata: Cranelift JIT/AOT (native, no VM)

    • Python: CPython interpreter

    • Haskell: GHC (LLVM/native)

    • Rust: LLVM (native)

    The repo is at github.com/ArthurJ/Kata — build with cargo build, then try kata repl, kata run examples/, or kata test. I'd love feedback on the language design: what feels right, what feels wrong, what you'd do differently.

    action greet (name::Text) => Unit
        echo!(+ "Hello, " (+ name "!"))
    
    action main
        greet!("World")
        greet!("Kata")
    
    main!()
    
    enum BMI
        Underweight(< _ 18.5)
        Normal(<= _ 25.0)
        Overweight(<= _ 30.0)
        Obese
    
    action main
        echo!(BMI 17.0)
        echo!(BMI 22.0)
        echo!(BMI 27.0)
        echo!(BMI 35.0)
    main!()
    
    fizzbuzz :: Int => Text
    lambda x:
        both: "FizzBuzz"
        fizz: "Fizz"
        buzz: "Buzz"
        otherwise: show x
        with
            fizz := divisible x 3
            buzz := divisible x 5
            both := and fizz buzz
    
    
    divisible :: Int Int => Boolean
    lambda x n:
        match div x n
            Ok q: = x (* n q)
            Err _: Boolean::False
    
    
    action main
        for i in [1..16]
            echo!(fizzbuzz i)
    
    
    main!()
    
     

    I think most of my comments and error messages are written in Portuguese, but this is only a prototype, so please ignore that.

    Kata manages memory with per-fiber bump arenas backed by structured concurrency — no garbage collector, no borrow checker, no reference counting; escape analysis decides at compile time whether each value stays local or escapes to the caller's arena, and ; in actions distinguishes "local computation" from "value that escapes." Refined types (data (Int, > _ 0) as PositiveInt) carry logical predicates validated at compile time, participate in multiple dispatch, and can delegate interface implementations to their base type through refines — a fallback mechanism with no equivalent in Rust or Haskell. The pure/impure boundary is not a monad you thread through your code — functions (lambda) and actions (action) are separate syntactic domains with their own structural rules, enforced at compile time; where Haskell tracks purity through IO as a type-level effect, Kata makes it a property of the syntax you write.


    Memory

    • Kata: Per-fiber bump arenas + escape analysis; no GC, no borrow checker

    • Python: Refcounting + cycle GC

    • Haskell: Tracing GC

    • Rust: Ownership + borrow checker


    Refined types

    • Kata: data (Int, > _ 0) as PositiveInt — predicates validated at compile time, participate in dispatch, refines delegates interfaces to base

    • Python: Not available

    • Haskell: Liquid Haskell (external plugin, not core)

    • Rust: Not available


    Purity

    • Kata: Physical barrier: separate syntax, operators, structural rules

    • Python: Not enforced

    • Haskell: Monadic IO (type-level effect)

    • Rust: Not enforced


    Conditionals

    • Kata: Pattern matching + guards (exhaustiveness enforced)

    • Python: if/elif/else

    • Haskell: if + pattern matching

    • Rust: if + match


    Backend • Kata: Cranelift JIT/AOT (native, no VM)

    • Python: CPython interpreter

    • Haskell: GHC (LLVM/native)

    • Rust: LLVM (native)

    The repo is at github.com/ArthurJ/Kata — build with cargo build, then try kata repl, kata run examples/, or kata test. I'd love feedback on the language design: what feels right, what feels wrong, what you'd do differently.

    action greet (name::Text) => Unit
        echo!(+ "Hello, " (+ name "!"))
    
    action main
        greet!("World")
        greet!("Kata")
    
    main!()
    
    enum BMI
        Underweight(< _ 18.5)
        Normal(<= _ 25.0)
        Overweight(<= _ 30.0)
        Obese
    
    action main
        echo!(BMI 17.0)
        echo!(BMI 22.0)
        echo!(BMI 27.0)
        echo!(BMI 35.0)
    main!()
    
    fizzbuzz :: Int => Text
    lambda x:
        both: "FizzBuzz"
        fizz: "Fizz"
        buzz: "Buzz"
        otherwise: show x
        with
            fizz := divisible x 3
            buzz := divisible x 5
            both := and fizz buzz
    
    
    divisible :: Int Int => Boolean
    lambda x n:
        match div x n
            Ok q: = x (* n q)
            Err _: Boolean::False
    
    
    action main
        for i in [1..16]
            echo!(fizzbuzz i)
    
    
    main!()
    
    [–] 2 points 2 months ago

    The main contribution of the Wright brothers is the controls used on aviation (pitch, yaw and roll). About being the first, Santos-Dumont is recognized by Fédération Aéronautique Internationale as the first flight with witnesses. Splitting hairs here, the english word "airplane" is less specific than the french word "avion". All avion are airplanes, but to be an avion the machine needs to be able to take off and land by its own means, and that's the point where the first flight of the Wright brothers are missing. And as they kept secrecy on what they were doing, we don't know exactly when they introduced each innovation on their machines. But to me, that doesn't matter much actually. Heavier-than-air flights are more like a collective effort IMHO with the Wright brothers, Santos-Dumont and many others contributing to create the aviation.

  • source
  • parent
  • context
  • [–] 4 points 6 months ago

    I'm using (Gemini 3.1 pro in) Gemini cli to build a complex (personal) project to explore how to use these tools. My impression is that the code produced by LLMs is disposable/throwaway. We need to babysit the model and be very hands on to get good results.

  • source
  • [–] 21 points 7 months ago

    Let me rewrite your question, and correct me if I'm misrepresenting it:

    "Why should we spend resources on X instead of Y?"

    Well, for this kind of question, I would prefer to choose a "high value" X and an "important" Y.

    Space exploration, and science as a whole, is extremely cheap and good for humanity.

    Let's talk about other expensive "X" first:

    • Unnecessary war efforts.
    • ICE (if we are taking about US)
    • Saving banks when they screw up on their bets.
    • Incentives to coal and gas when solar is already more viable ...

    Maybe you started to think about it because that's an amazing subject, and it is. That alone should be reason enough for us to want to do it. But it is not the only reason. Space exploration already gave us a lot of tech we rely on today. And still, is a very difficult field that will require more tech advancements, that will benefit us in the future.

  • source
  • view more: next ›