At least to me, the difference is that one is ostensibly an explanation of how the AI arrived at the joke, the other is a post-hoc explanation of the joke.
You can be pretty sure the AI isn't doing a post-hoc explanation because the only writable memory it has access to is the tokens it has already output - i.e. the explanation of the joke. Everything else is reset between every token.
As long as it comes up with different jokes different times you ask it (assuming randomness in sampling) - how could it.
The problem is it can’t remember what it hasn’t written but the end result still makes sense, so there has to be some goal after parsing the initial context that the tokens are emitted towards to. This means there’s nothing stopping it from producing an explanation, it might be in there from the very start.
One of the problems with halon, and the write-up mentions this, is that it is super effective at starving the fire of oxygen, but has zero effect on the heat of the fuel that was burning. So the fire goes out, but if oxygen is reintroduced before the fuel has a chance to cool sufficiently, it reignites - and now not only are you back where you started, but you have all the toxic byproducts that burning halon produces, which will kill you in a hurry if you breathe them in.
> One of the problems with halon, and the write-up mentions this, is that it is super effective at starving the fire of oxygen
That's not actually quite how it works. But yes, the end result is the same. I'll copy-paste my comment from the Medium:
That's NOT how halon works! It's a common misconception, but it's incorrect. In fact, halon doesn't react with pretty much anything, it's very chemically stable. You can mix halon with pure oxygen and it'll just sit there, doing nothing.
This stability is exactly why it works so well. You need only a few _percent_ of halon by volume to stop the fires, not even close to consuming even a fraction of the 21% of oxygen.
Normal oxygen consists of two atoms bonded together (thus "O2"). And fire is spread by oxygen radicals, lone oxygen atoms that have an unpaired electron, eager to make bonds. In a fire, an oxygen radical reacts with a molecule of fuel, and this reaction produces enough energy to create at least one more oxygen radical, sustaining the chain reaction.
But halon has these chlorine and bromine atoms, they are bound tightly to carbon, but not as tightly as oxygen would be. So oxygen radicals have enough energy to displace them and bind to the central carbon atom. But the resulting energy release is not enough to create _more_ radicals, so the chain reaction is stopped.
Moreover, the chlorine radical can then snap back onto another carbon atom (from the fuel source), releasing a bit of energy, but not enough to create a new oxygen radical. And the cycle can repeat again.
What you wrote is not contradicting the parent, who just said that it was “super effective at starving the fire of oxygen”. You just described the mechanism. You also contradict yourself by first saying that halon is inert, and then that it neutralises oxide ions by swapping halogens, which is the opposite of non-reactive. The effect of that is that it immobilises reactive oxygen before it oxidises the fuel. And it indeed does nothing to decrease the temperature, which does mean that the fire restarts as soon as oxygen is re-introduced. I know you’re not wrong, but the delivery could be improved.
Anyway, you can elaborate and provide information without disagreeing with the comment you’re replying to. It’s fine, and often informative.
Typically, "starving of oxygen" means that there's not enough oxygen around anymore. That's how CO2 extinguishers work, for example. They literally remove enough of the oxygen to make the combustion stop.
Halon does NOT remove the oxygen, there's always plenty of it available. Instead, it stops the chain reaction.
> You also contradict yourself by first saying that halon is inert, and then that it neutralises oxide ions by swapping halogens, which is the opposite of non-reactive.
As I said, you can mix halon and oxygen, and they won't react (even if you try to ignite them). Halon is very unreactive, but it's obviously not _totally_ inert like helium.
As I said, you can mix halon and oxygen, and they won't react (even if you try to ignite them).
That makes me wonder if any of the original designers of the oxygen system considered whether a halon-oxygen mix would've been better than pure oxygen.
As far as I understood it reduces temperature also because it boils so easily (very low boiling point). That pulls energy from the fuel. As well as capturing oxygen.
This is why it was used as a refrigerant also.
Also if the fuel is below the auto ignition temperature but above flashpoint it would need another spark to re-ignite.
> Some societies optimize for the individual. If 8 lights is better for me then I get 8 lights. The experience gor other drivers us a "them" problem not a "me" problem.
>
> Other societies optimize for public good.
That is, frankly, bullshit. Societies, by definition, only exist when their members act, in aggregate, for the good of the community. A society cannot exist where everyone only acts in self-interest at the expense of everyone else. If you make self-interested choices for no other reason than "I did it because I could", that's just pure selfishness.
Society is forced to tolerate some degree of self-interest, but it isn't an optimization problem, because nobody is tweaking the parameters - things work until they don't anymore. That's why every society that has collapsed, did so either due to war, due to greed and self-interest causing it to turn on itself, or some combination of the two.
It isn't important that you make choices that benefit others, but rather that you at least care about how your choices affect others, and attempt to reduce the harm of your own self-interest. If you don't even bother to do that, then you don't deserve to be part of our society, or any other, IMO.
If only people that believed they stand alone, that everyone should fend for themselves, actually had to do so, maybe the world would be a better place.
I'll disagree only a tiny bit here: To me (also a compiler engineer), a transpiler is shorthand for source-to-source translation from one language to another at a similar level of abstraction (e.g. Lua to Ruby, Java to C++). The implementation of a transpiler meeting that definition is generally a simpler project than a compiler, by virtue of the fact that you get to offload a lot of things to the compiler of the target language. That doesn't mean they aren't incredibly complex in their own right though - compilers are just enormously complex projects for anything approximating a production-ready toolchain. Anyone using the term as a pejorative should be laughed out of the room.
In any case, I 100% agree that this is obviously a compiler. The fact that the compiler emits WASM as text, i.e. WAT, doesn't mean it is source-to-source translation - the output is still assembly code for the target machine.
And as an aside, does it really emit WAT? or is that just a debugging view of its output? If you can emit WAT, there is zero reason you can't emit WASM too.
It it apparently _is_ an actual problem, which is why an attempt at solving it is being made. A black market for reservations is bad not just for customers, but for the establishment that loses out on business if the reservations aren't actually sold, and therefore nobody shows up.
they should go after ticketmaster and livenation which is a far, far bigger issue except of course they lobby hard while black market reservation folk don’t. they need to unionize or something and then lobby hard too :)
It's not a problem at all. Cook at home or go to another restaurant. These legislators should be put on a strict diet of water and bread for a few years until they learn.
A restaurant has a fixed number of reservations possible. How do you suggest allocating them when demand exceeds supply? One way or another, some will not be able to get a reservation.
> There are many things that are beyond supply and demand: love, sex, children.
Those are most definitely connected to supply and demand.
High status men get high status women, and vice versa. What do you think drives the price of a hoe? And how many children one has is often the result of willingness to pay for them.
> Why should restaurant reservations be any different?
You might not need to go to college, but you're going into significant debt if you do, so now one has to decide which disadvantage they want to start their career with: no degree, or crippling debt.
A fast food job might be $17/hr, but the cost of gas is >2x what it was when that same job paid $8/hr, not to mention other basic costs like groceries, rent, and buckle up if you have to go to the doctor. Pay has simply not kept up with the cost of living for most Americans.
Why would anyone be happy that everything is ephemeral? That implies a lack of stability, more anxiety about the future, less confidence that you can weather bad times.
Humans are tactile creatures, everything being digital leads to a counter-intuitive sense of isolation - more connected, but less personal. There are positives too, but as an older Millennial, it has been interesting to be along for the ride as the potential of the internet and social media went from a superpower, to kryptonite. Who knows where things will be in 5-10 years, but it's hard not to see how some of our greatest tools are being turned against us in the search for more profit.
Millennials are, if anything, brutally realistic - a trait required to navigate the last 16 years. We were forced to watch as the last bit of life in the idea of a strong middle class was snuffed out, and had to enter the workforce right as the GFC hit. Our parents were the last generation where one could reasonably expect to live a life that truly lived up to the ideal of the American Dream - that one could get educated, get a job, buy a decent house and raise a family, without it being especially noteworthy to do so. For many Millennials, if not every generation following, it is essentially nothing more than a dream at this point. Corporate greed, and a government fully captured by it, has all but killed the middle class, and I fully expect that the advent of AI - rather than being a boon for the middle class - will drive a nail in its coffin. Those with the most to gain are already on top, and I've already heard way more people here talk about what they'll be able to do without needing to hire anyone, than I have about how the people left jobless will benefit. It is readily apparent that nobody with any power is going to do anything about it before a significant amount of suffering is felt - maybe not even then. All you have to do is listen to how people talk about it, as if everyone will magically figure out something else to do when every sector starts losing jobs simultaneously. Our society has a greater chance of eating itself alive first.
I consider myself lucky amongst most Millennials - I entered the workforce before the GFC, then joined the military shortly after it (not due to the GFC, but the timing worked out). I was able to get far enough along in my career in those first years though that I never had to struggle with finding a job like many did. I was able to get a house in my 30s thanks to the GI bill. Very few of those I grew up with are in the same boat, many are living much the same as they were 15 years ago - unable to save enough to buy a house, facing reduced job prospects in the future. What reason do they have to be anything _but_ pessimistic?
For me personally, I think we've simply lost the battle against greed, and there is a tipping point after which reigning it back in is impossible without burning it all down. That's something nobody should want, least of all the rich, but it's played out many times in history, and we keep falling into the same trap, just different ways. I think this time it probably was Citizens United where we lost our grip, that decision made it inevitable that corporate interests would be the driving force of government, not the needs of its people. Who can say for sure what will happen, but we're all along for the ride regardless.
> Millennials are, if anything, brutally realistic
No, your entire post is an example of the dramatic doomerism waxing on the anxieties of normal life. Complaining about anxiety is one of the hallmarks of a millennial.
> In 2008 gas cost as much as it does now and fast food did only pay $8/h
Did you deliberately pick the time where the cost of gas skyrocketed before eventually coming back down to more normal levels? Gas where I lived at the time went from like $2/gal to $4/gal for months, then came back down to ~$2.75 but never fully returned to where it was. You're cherry picking your facts.
> your entire post is an example of the dramatic doomerism waxing on the anxieties of normal life. Complaining about anxiety is one of the hallmarks of a millennial.
Where was I complaining about anxiety? I do think many people are anxious, and have reason to be - but if I'm complaining about anything, it's greed. Dismissing the extensive evidence of its pervasiveness in our society today, and the negative outcomes it is producing, is the mindset of someone that doesn't care about anyone or anything that doesn't affect them personally.
With the increase in fuel economy, the cost of gas as an actual pain point is close to the lowest level it has ever been for the vast majority of the US. The only real exception to this is places like California where additional costs are added for tax revenue or additional emissions controls.
> I do think many people are anxious, and have reason to be
Previous generations had just as many reasons to be anxious, they just didn’t sit around crying about it non-stop in victimhood perpetuity.
Erlang absolutely has closures, you are mistaken. What you are referring to are "function captures", which bind a function reference as a value, and there is no environment to close over with those. However, you can define closures which as you'd expect, can close over bindings in the environment in which the closure is defined.
The interaction between hot reloads and function captures in general is a bit subtle, particularly when it comes to how a function is captured. A fully qualified function capture is reloaded normally, but a capture using just a local name refers to the version of the module at the time it was captured, but is force upgraded after two consecutive hot upgrades, as only two versions of a module are allowed to exist at the same time. For this reason, you have to be careful about how you capture functions, depending on the semantics you want.
> but is force upgraded after two consecutive hot upgrades, as only two versions of a module are allowed to exist at the same time.
Force upgraded is maybe misleading. When a module is loaded for the 3rd time, any processes that still have the first version in their stack are killed. That may result in a supervisor restarting them with new code, if they're supervised.
Ah right, good point - I was trying to remember the exact behavior, but couldn't recall if an error is raised (and when), or if the underlying module is just replaced and "jesus take the wheel" after that.
What does is it look like? I was talking about this thing:
Val = 1, SumFun = fun(X) -> X + Val end, SumFun(2).
It looks like you define arity 1 function that captures Val, while in fact you define arity 2 function and bind 1 as a first argument. Since you can't redefine Val anyway, it's as good as a closure, but technically it doesn't capture the environment.
Maybe I'm mistaken and there is another way to express it?
The example you've given here does not work the way you think it does. I would agree however that the mechanics of closure environments is simpler in Erlang due to the fact that values are immutable, as opposed to closures in other languages where mutability must be accounted for.
I would also note that, for the example you've given, the compiler _could_ constant-fold the whole thing away, but for the sake of argument, let's assume that `Val` is an argument to the current function in which `SumFun` is defined, and so the compiler cannot reason about the actual value that was bound.
The closure will be constructed at the point it is captured, using the `make_fun` BIF, with a given number of free var slots (in this case, 1 for the capture of `Val`). `Val` is written to the slot in the closure environment at this time as well. See the implementation of the BIF [here](https://github.com/erlang/otp/blob/6cefa05a2a977864150908feb...) if you are curious.
At runtime, when the closure is executed, the underlying function receives the closure environment, from which it loads any free vars. In my own Erlang compiler, the closure environment was given via pointer, as the first argument to the function, and then instructions were emitted to load free variables relative to that pointer. I believe BEAM does the same thing, but it may differ in the specific details, but conceptually that is how it works.
The compiler obviously must generate a new free function definition for closures with free variables (hence the name of the function you see in the interactive shell, or in debug output). The captured MFA of the closure is this generated function. The runtime distinguishes between the two types of closures (function captures vs actual closures) based on the metadata of the func value itself.
Like I mentioned near the top, it's worth bearing in mind that the compiler can also do quite a bit of simplification and optimization during compilation to BEAM - so there may be cases where you end up with a function capture instead of a closure, because the compiler was able to remove the need for the free variable in cases like your example, but I can't recall what erlc specifically does and does not do in that regard.
> let's assume that `Val` is an argument to the current function in which `SumFun` is defined, and so the compiler cannot reason about the actual value that was bound.
That was exactly the case I was talking about, because otherwise there is no need to even make arity 2 function. If the value is known at compile time, the constant is embedded into the body of inlined function.
>At runtime, when the closure is executed, the underlying function receives the closure environment, from which it loads any free vars.
To my understanding, no it doesn't, as the value is resolved when the function pointed is created, not when the underlying function executes, which the code you linked shows too. I know it uses the "env" as a structure field, but it's partial application, not the actual closure which has access to parent scope. Consider two counter examples in python:
for x in range(1,10): ret.append(partial(lambda y: y*2, x)) # that's what erlang does
for x in range(1,10): ret.append(partial(x, lambda y: y*2)) # that's an actual closure, as all lambdas will return 18 because x is captured from the parent context
But then again, it doesn't matter since variables are assigned only once.
>Like I mentioned near the top, it's worth bearing in mind that the compiler can also do quite a bit of simplification and optimization during compilation to BEAM - so there may be cases where you end up with a function capture instead of a closure, because the compiler was able to remove the need for the free variable in cases like your example, but I can't recall what erlc specifically does and does not do in that regard.
I was looking into it a week ago, and erlc does what I described when it can't figure out the constant at compile time.
add: If we are at it, BEAM doesn't even know about variables, only values and registers anyway, so it has nothing to capture anyway.
> To my understanding, no it doesn't, as the value is resolved when the function pointed is created, not when the underlying function executes, which the code you linked shows too. I know it uses the "env" as a structure field, but it's partial application, not the actual closure which has access to parent scope
The code I linked literally shows that the closed-over terms are written into the closure environment when the fun is created, and if any term is a heap allocated object, it isn't copied into the closure, only the pointer is written into the env. The only reason you can't observe the effects of mutability here is because, unlike Python, there is no way to mutate bindings in Erlang.
Again, this isn't partial application - not in implementation nor in semantics.
My reading is that they were evaluating leaders on their introversion/extroversion, intuitiveness, and overall success. So you could have both introverted-intuitive and extroverted-intuitive leaders, and overall, the introverted-intuitive leaders were _more_ successful.
BZ2 was one of my favorite games for quite some time after it released, just a blast to play. I had been really into BZ98 before it, and didn't think a sequel would be able to match the magic, but I ended up playing more of BZ2 in the end. Anyway, it's nice to be able to say thanks to one of the devs for all the good times!
Any particular interesting stories about BZ2's development that you recall? Always interesting to hear how games like this come together, so much of the time it seems like more luck than anything!
I worked on 3d modeling/texturing and mp maps, though my time was divided between BZ2 and our other game Dark Reign 2 and other duties, so I was never full-time on BZ2. Of the games I worked on during my 3 years at Pandemic, BZ2 was my favorite.
I was very young when I joined Pandemic, having interned my senior year of high school and then joining full-time that June. It was a wonderful company to work for and had just broken free from Activision 6mo prior so there was a lot of early startup company culture being built. Witnessing how to build a company the right way was very informative to my later career.
Iirc I think we got a bit ahead of our skis with BZ2's engine rewrite, and in retrospect should have treated BZ2's tech as more of an expansion of BZ1's instead of a whole new game. The engine caused a lot of headaches and bugs, and it taught me early in my career that rewrites and new tech aren't always the right decision.
I think the decision to be more ambitious was due to the rapid transition in graphics going on in the late 90s, it was the age of early graphics accelerators like 3dfx Voodoo & Riva TNT. Hard to hit a moving target.
BZ2's codebase had quite the lineage, pieces of it transmogrified over the years from MechWarrior 2 -> Interstate 76 -> BZ1 -> BZ2 -> Dark Reign 2 & Star Wars Clone Wars. Getting ambitious while also dealing with the legacy bits I think contributed to the many early bugs. I wasn't an engineer but did futz around with the particle system which was one of the new fancy parts that got more attention.
BZ2 came in hot for Christmas 99, it wasn't exactly ready and needed a lot of patching over the next several months. If we'd had been less ambitious with the tech I believe it'd have been a decently polished release and had more success, since art, design, and gameplay were not behind. I remember feeling sad we were releasing before it was ready, and the lesson that better planning and tech choices were the way to avoid that feeling.
Unfortunately Activision wasn't a great partner for us as a publisher, there was some bad blood as they didn't like that we'd broken off as a studio rather than stay under their wing, so they didn't do much to promote the game. We were pretty pissed with that. Same thing happened with Dark Reign 2.
As far as design goes, towards the end of 99 I dove into making BZ2 maps, building Ground Zero and I think a few others. Later the engine became known as the Ground Zero or Zero engine, not sure if it was named after the level or just chosen independently. I remember being particularly motivated to work on BZ2 because I really loved the game and it was getting close to release. I had some freedom to decide my time as DR2 was going through a rough spot, so I just decided to throw myself into BZ2.
There were some multiplayer maps I didn't get to finish, including one that was basically a big 3d asset I built in Softimage that was a rock formation with multiple levels that would have really pushed the boundaries of what was possible in BZ2 maps. I'd have loved to see that come together in time, tho I'm not sure what the AI pathfinding would have done with it - I think I designed it specifically for PvP tho. Once BZ2 was released, attention immediately turned to shipping DR2, which had gone through some team turnover and needed a near complete redesign in 6 months. I wound up making all the multiplayer maps for that, and having a great time with that team.
I hope to write up more war stories at another time. It's been 25(!) years now since release. Crazy.
