• 0 Posts
  • 18 Comments
Joined 2 years ago
cake
Cake day: June 16th, 2023

help-circle

  • In applied CS, it’s common to talk about pure and impure functions instead of Turing machines.

    Pure functions are, broadly speaking, equivalent to Turing machines. A pure function may only depend on its inputs (like a Turing machine) and has no outputs besides the return value (like the end state of a Turing machine’s tape).

    Impure functions cover algorithms that aren’t Turing machines. For example, you might have a random number generator rand: 1 → N that outputs different natural numbers on every invocation rand() and is hence impure. Output functions are also impure, e.g., a function write: N → 1 that writes a number into a file can’t be a Turing machine, because Turing machines have no concept of files.

    Computer programs that consist entirely of pure functions aren’t very useful, because they can’t interact with the user or reality. The typical approach to solving this is to put the core program logic inside pure functions that interact with impure parts through a limited interface. That way, you can apply CS concepts to the important parts of the program and neatly separate out the impure parts.

    Edit: Changed ∅ to 1 (singleton set) in function definitions. A function can’t return ∅ and a function taking ∅ can’t be called.


  • As a Finnish speaker, I just can’t see generic localisation systems like Fluent working with agglutinative languages. For instance, consider the Polish example for Firefox Account from Fluent’s front page:

    -sync-brand-name = {$case ->
       *[nominative] Konto Firefox
        [genitive] Konta Firefox
        [accusative] Kontem Firefox
    }
    

    In Finnish, this would be called Firefox-tili. Tili means account and belongs to the Kotus type 5 words, which specifies how the word is inflected with various suffixes. Fluent doesn’t support agglutination, so you’d have to specify every form of the word separately:

    -sync-brand-name = {$case ->
        [nominative] Firefox-tili
        [partitive] Firefox-tiliä
        ... 10ish more inflections
        [nominative first person] Firefox-tilini
        [partitive first person] Firefox-tiliäni
        ... 10ish more inflections
        ... the above inflections but for 2nd and 3rd persons
        [nominative first person plural] Firefox-tilimme
        [partitive first person plural] Firefox-tiliämme
        ... 10ish more inflections
        ... the above inflections but for 2nd and 3rd persons plural
        [nominative first person questioning] Firefox-tilinikö
        [no idea what this is even called] Firefox-tilittömänäkin
        [no idea what this is even called 2] Firefox-tililleensäkään
        ... lots more
    }
    

    Ideally, you’d only specify that Firefox-tili is a type 5 word and the system generates all of that boilerplate.













  • Another point in favour of databases is simplicity of client-server communication and data models.

    Many objects in WoW (not too sure about spells, but most likely them too) work such that the client asks the server for the related DB rows when it sees an object for the first time. So instead of sending code across the wire, which would be a bad idea for many reasons, you instead send structured data that the client interprets.

    Of course, you could just bake the spell code into the client at compile-time, but then dataminers will take it apart on day 0. WoW datamining mostly works such that you play the game normally and see what data the server gives you.


  • Although I’ve used a number of languages including Python, Javascript, and Go to build software, the bulk of my experience is working in Java.

    Notably, Python’s type annotations are extremely similar to Typescript. I guess the author hadn’t used Python’s type annotations very much (which is understandable considering they’re often missing from libraries and the implementations are buggier than Typescript).