- itishappy"Sometimes shit happens" should be viable in a courtroom sometimes, but by nature competition rules leave less room for interpretation.
- Re: Judgement:
I think it's exactly their popularity that lead people to call the big awards shows "a joke." Pretty common with stuff like the Emmys and Grammys.
- They're not equivalent...
> technically gen AI but have non of the ethical issues
- > Seems like the objection is to the process, not the result.
Right. The game is not eligible for the award. This is not a comment on the quality of the game.
The Indie Game Awards require zero AI content. The devs fully intended to ship without AI content, but the made a mistake, disqualifying themselves for the award. This is simply how competition rules work. I have a friend who plays competitive trading card games, and one day he showed up to a national event with an extra card in his box after playing with some friends late at night. It was an honest mistake, and the judges were quite sympathetic, but he was still disqualified!
BTW, the game is incredible.
- FYI, last year was the first ever Indie Game Awards.
- Is this actually a problem? Is there anybody actually arguing against line smoothing algorithms?
- I'd agree if this were about The Game Awards or similar, where indie devs are expected to compete against the AAA goliaths, but I've always understood the Indie Game Awards as being more about the craft then the end product.
From the FAQ:
> The ceremony is developer-focused, with game creators taking center stage to present awards, recognize their peers, and openly speak without the pressure of time constraints.
https://www.indiegameawards.gg/faq
Regardless of AI's inevitability, I don't particularly care to celebrate it's use, and I think that's the most reasonable stance for a developer focused award to take.
- Fair point, but I think it's a lot more true of functional ones.
The problem is pretty easy to see in a C-style for loop:
The index variable depends on it's value in previous versions of the loop and can be modified in the loop body! Can't parallelize that!for (int i = 0; i < 5; i++) { printf("%d\n", i); if (i % 2 == 0) i++; }Side effects and mutation break many of the promises provided by functional constructs. Hybrid languages like Python can illustrate this:
A language like Haskell might be the other extreme. You're not allowed to use an `f` that breaks this:# pure, parallelizable [2 * item for item in items] # side effect! order matters! [print(item) for item in items] # side effect! order matters! [arr.append(item) for item in items][f item | item <- items] - I would argue that imperative programming is the only one with a concept of linear time.
Here's a functional example:
Are those multiplications run in sequence or parallel?map (*3) [0,1,2,3,4,5,6,7,8,9]Here's a fancier functional one:
What order are the fields fetched?getUser = User <$> getName <*> getEmail <*> getStartDateIf you answered "unspecified" then you're right! A compiler could parallelize either of these expressions!
- > Church ends up defining zero as the identity function
Zero is not the identity function. Zero takes a function and calls it zero times on a second function. The end result of this is that it returns the identity function. In Haskell it would be `const id` instead of `id`.
I suspect that this minor misconception may lead you to an answer to your original question!zero := λf.λx.x one := λf.λx.fx two := λf.λx.ffx id := λx.xWhy isn't the identity function zero? Given that everything in lambda calculus is a function, and the identity function is the simplest function possible, it would make sense to at least try!
If you try, I suspect you'll quickly find that it starts to break down, particularly when you start trying to treat your numerals as functions (which is, after all, their intended purpose).
Church numerals are a minimal encoding. They are as simple as it possibly gets. This may not speak to Church's exact thought process, but I think it does highlight that there exists a clear process that anyone might follow in order to get Church's results. In other words, I suspect that his discover was largely mechanical, rather than a moment of particularly deep insight. (And I don't think this detracts from Church's brilliance at all!)
- You must be a lot more comfortable as a passenger than I am, because that honestly sounds like my personal hell. I don't mind driving, but I hate being in any vehicle for extended periods. Have you considered a chauffeur?
- How does temperature explain the variance in response to the inclusion of the word "critical"?
- I feel like shortcuts are often enough. They function quite like this: a symbolic language that allows you to build up an intuition. They use icons that you already know, and instead of being bespoke per designer (how many different save icons are there?) they work across your entire OS. The muscle memory you build, instead of being bespoke per menu (and dynamic in time), allows you to skip the menu entirely!
- It used to!
- They sure do, and just like biological evolution it is not a principled process. Sometimes evolution results in a worse outcome.
- > When you detect me trying to learn a new feature, help me find it...
"It looks like you're trying to learn a new feature. Would you like help?"
I miss Clippy.
- > It should be the opposite: with more messages you want to scale with independent consumers, and a monotonic counter is a disaster for that.
Is there any method for uniqueness testing that works after fan-out?
> You also don’t need to worry about dropping old messages if you implement your processing to respect the commutative property.
Commutative property protects if messages are received out of order. Duplicates require idempotency.
- Here's a minimal python translation of the important bits:
Admittedly this is a bit unwieldy in Python. Haskell's `do` notation desugars to repeated binds (and therefore requires something to be a Monad), and does a lot of handiwork.class Reader: def __init__(self, func): self.run = func def pure(x): return Reader(lambda _: x) def bind(self, f): return Reader(lambda env: f(self.run(env)).run(env)) ask = Reader(lambda env: env) def calc(): return ask.bind(lambda input_str: Reader.pure(len(input_str))) test = calc().run("test") print(test)-- this: calc :: Reader String Int calc = do input <- ask pure $ length input -- translates to: calc' :: Reader String Int calc' = ask >>= (\input -> pure $ length input) - A reader is just an interface that allows you to build up a computation that will eventually take an environment as a parameter and return a value.
Here's the magic:
That Monad instance might be the scariest bit if you're unfamiliar with Haskell. The (>>=) function takes a Monad (here a Reader) and a continuation to call on it's contents. It then threads the environment through both.newtype Reader env a = Reader { runReader :: env -> a } ask = Reader $ \x -> x instance Functor (Reader env) where fmap f (Reader g) = Reader $ \x -> f (g x) instance Applicative (Reader env) where pure x = Reader (\_ -> x) ff <*> fx = Reader $ \x -> (runReader ff x) (runReader fx x) instance Monad (Reader env) where (Reader f) >>= g = Reader $ \x -> runReader (g (f x)) xMight be used like this:
Not sure how this compares to Zig!calc :: Reader String Int calc = do input <- ask pure $ length input test :: Int test = runReader calc "Test" -- returns: 4https://stackoverflow.com/questions/14178889/what-is-the-pur...
Edit: Added Applicative instance so code runs on modern Haskell. Please critique! Also added example.