Sure, but at the time they showed real interest in becoming a mainstream game engine, showed some cool advanced projects, and had a few years to try out, why did the give up if there was hype?
I'm not sure what "cool advanced projects" you're thinking of, but to my recollection, there was very little in the way of finished work created with the original Blender Game Engine. There were two game efforts associated with the Open Movie Projects: Yo Frankie! (associated with Big Buck Bunny) and Sintel The Game (associated with Sintel.) The former had something like a proper release, but the latter only ever got a few alpha releases before being abandoned: neither was terribly impressive except inasmuch as a demo of the technology, and to my recollection, neither inspired much hype. (The Wikipedia page for Yo Frankie! says dryly, "The game was noted by the gaming press," without any further elaboration, which does not speak to massive amounts of excitement or hype.)
Since then, aside from some interesting bits of work that didn't actually make shipping games easier, the engine really languished. My understanding is that a big part of the reason the engine was removed was that it made work on other parts of Blender more difficult, and that dispensing with the (little-used) engine in favor of the (increasingly popular) modeling tool was clearly a net benefit to being able to develop Blender, especially since the mantle of "open source game engine" had been taken up by other competent projects like Godot.
So yes, they may have at some point aspired to becoming a "mainstream game engine", but there's more to that effort than just aspirations and demos. (And at the same time, the fact that the BGE faltered doesn't mean that other open source game engine efforts would necessarily face the same fate.)
It's probably also worth saying that people have forked the game engine and you can still use it: the forked version is called UPBGE, and there are people out there trying to make it work. By and large, though, the Blender project seems to point people at projects like Godot, with the idea that a focused game engine is probably better suited to modern games than something that strapped a game engine onto a piece of modeling software.
If I had to take a guess without any proper research:
1) Godot didn't want to chase two rabbits at once. Making an engine is hard, and making a modeling program is hard. If they split attention between the two, they may have ended up with a half-assed engine/modeling program instead of a professional grade modeling program and an abandoned engine.
2) much simpler, but the game engine team fell out. So there was no one to properly maintain the Blender Game Engine. No malicious reason: it's an open source initiative and this would be 5+ years before Godot got major funding. They may have changed life perspectives, may have gotten poached, or simply lost interest (and ofc there's other office politic conspiracy theories)
but these are 2 of many reasons, and I'm sure if you tracked down the right person in Blender you can simply ask for the real reason (and then maybe make close friends for the real gossip lol).
The former is referring to representing an AST using a GADT in order to include the typing discipline of the target language in the host language. For example:
data Term t where
Num :: Integer -> Term Integer
Bool :: Integer -> Term Integer
Add :: Term Integer -> Term Integer -> Term Integer
IsZero :: Term Integer -> Term Bool
IfThenElse :: Term Bool -> Term a -> Term a -> Term a
With this AST, you can express well-typed programs like `Add (Num 2) (Num 3)`, but the Haskell type system will stop if you express an incorrectly-typed program like `Add (Num 2) (Bool False)`.
The "Trees That Grow" paper, on the other hand, is about reusing the same AST but gradually adding more information to the nodes as you progress through the compiler. For example, you might want to start with variable names being raw strings (so that a term corresponding to `lambda x: lambda x: x` looks like `Lam "x" (Lam "x" (Var "x"))`) but eventually replace them with unique symbols so that shadowed names are non-identical (so that under the hood it looks more like `Lam 1 (Lam 2 (Var 2))`, although in practice you'd want to keep the old name around somewhere for debugging.)
One way to accomplish this is to introduce an explicit type-level notion of compiler phases, give your terms a type parameter which corresponds to the phase, and use the phase to choose different representations for the same nodes:
data CompilerPhase = Parsed | Resolved
data Expr (phase :: CompilerPhase)
= Lam (Name phase) (Expr phase)
| App (Expr phase) (Expr phase)
| Var (Name phase)
type family Name (t :: CompilerPhase) :: *
type instance Name Parsed = String
type instance Name Resolved = Int
Using this example, an `Expr Parsed` will contain variables that are just strings, while an `Expr Resolved` will contain variables that are integers, and you can write a pass `resolve :: Expr Parsed -> Expr Resolved` which just modifies the AST. (This is a toy example: in a real compiler, you'd probably want to create a new type for resolved variables that still keeps a copy of the name around and maybe some location information that points to the place the variable was introduced.)
They have a bool / int expression language example. (And funny thing I'm coding up such a type checker and evaluator right now in TypeScript. TypeScript union types seem to be pretty expressive and useful for this problem.)
However I'm STILL confused ... Admittedly I skimmed through the GADT chapter and I didn't follow all of it, but I don't understand why the answer isn't:
1. have a untyped representation that allows (Add (Num 2) (Bool False))
2. write a type checker on that representation
3. The output of the type checker is a new IR, which can only express (Add 2 3) => Int and (Eq 5 (+ 3 2) => Bool
Is the more abstract GADT solution supposed to "save" you some work of writing a type checker by somehow letting you reuse Haskell or OCaml's type system to express that?
That's a little weird to me ... it seems to be confusing the metalanguage and the language being implemented.
It's not surprising to me that this would go awry, because in general those 2 things don't have any relationship (you can implement any kind of language in OCaml or Haskell).
---
Hmm OK I actually DID run into the issue where you need dynamic checks in the evaluator, that should be impossible BECAUSE the previous the type checking phase passed.
i.e. some of the rules you already encoded in the type checker, end up as "assert" in the evaluator.
Hm I will think about that. There is some duplication there, sure. But I still think there's a weird confusion there of the language the compiler is written in, and what the compiler DOES
You're kinda coupling the 2 things together, to avoid a little duplication.
I also wonder how all that is actually implemented and expanded into running code. The GADT syntax seems to get further and further away from something I imagine can be compiled :)
---
edit: Thinking about it even more, although I did run into the dynamic checks issue, I think it's because my type checker only CHECKED, it didn't LOWER the representation. So I think what I originally said was true -- if you want more type safety, you introduce another simple IR. What's the benefit of using GADTs ?
> That's a little weird to me ... it seems to be confusing the metalanguage and the language being implemented.
Well, that's sort of the point. It's perhaps a little less important if you're writing a compiler for a separate programming language, but that's a relatively rare use case. GADTs are mainly used for implementing DSLs to be used elsewhere in the same program.
> Is the more abstract GADT solution supposed to "save" you some work of writing a type checker by somehow letting you reuse Haskell or OCaml's type system to express that?
Yes. Writing your own typechecker and integrating it into an existing compiler pipeline is a ton of work, easy to screw up, and a potential compatibility nightmare.
> I also wonder how all that is actually implemented and expanded into running code. The GADT syntax seems to get further and further away from something I imagine can be compiled :)
GADTs are syntactic sugar for constrained type constructors. So this
data Example a where
Example :: Int -> Example Int
becomes this
data Example a = (a ~ Int) => Example a
which is then compiled to a type coercion in the intermediate language
Since Ruby 3, the automatic coercion of keywords to a hash—the second example underneath "Passing Hash to Functions" in this post—is considered a legacy style and is generally frowned upon in new code. That is to say, code like the second call to `foo` here:
One of the strongest arguments for avoiding this sugar is that it makes the code more brittle in the face of future changes. In particular, in the example above, if we add a new keyword argument to `foo`, then any call which omitted the curly braces will break, while calls which used them will keep working fine:
# added a new keyword arg here
def foo(kwargs = {}, frob: false)
kwargs
end
foo({k: 1}) # still ok: `frob` defaults to false
foo(k: 1) # ArgumentError: no keyword: :k
That's kind of the point of default values, though. If you wanted to make a change to the method and you want it to break to alert you to all the calls, then you can add a keyword without adding a default value for it.
If you know git: a federated wiki works like that. To make a federated wiki work like a traditional wiki, you can think of there as being a "canonical copy" which you can clone, make edits, and then use a 'pull request' process for incorporating those edits back into the original. But you also don't need to have a single source of truth: you can, for example, have a group of people—say, students studying for a class—who are building their own wikis, and among each other they can copy in pages, make changes, copy changes back, and so forth, all building a web of things. In the same way that git can replicate a subversion-like workflow but also introduces the possibility of different workflows, a federated wiki can replicate a traditional wiki but also has a number of workflows it can accomplish.
Thanks! I'm aware of the abstract technical idea, but is there any evidence that Ward's wiki ever worked like that? Did he ever accept a "pull request" or are there any notable forks which do?
There are a truly massive number of RPGs out there with a wide variety of open licenses, especially the various Creative Commons licenses. The indie RPG sphere is massive and includes tabletop systems that range from "mild variations on the core D&D formula" to "almost fundamentally alien approaches to doing structured role-playing". D&D has long-standing brand recognition and cultural cachet, but it hasn't been the only player in this space for decades.
Absolutely and then some! I personally would argue that D&D itself—5E in particular here—is actually a fairly middling tabletop game. It's held back by a lot of historical cruft because even new editions end up being forced to stick to decades-old design decisions for the sake of tradition. A simple example here is the distinction between ability scores and ability modifiers: this is an old D&D-ism and trying to remove it sparks complaints about how it's "not D&D", but it's frankly some unnecessary complexity and other tabletop games lose nothing by dropping scores and just using modifiers.
Apart from the core design, D&D is also pretty middling as a product. Being a DM for D&D is hard—a fair bit harder than running many other tabletop games—and the book are at best a so-so resource: there's a lot of extra prep and careful balance that rests on the DM's shoulders, and doing it right means either falling back part-and-parcel on adventure modules or doing a lot of careful tuning and reading forums and Reddit threads. In an ideal world, the core books would include everything you need to know, but in practice the best DM advice is outside the core books (and sometimes even contradicts the books themselves!) Many other games don't have this problem.
To be clear, I don't think D&D is a bad game, but plenty of other games out there have clearer core designs, better presentations, easier-to-grasp rules, and overall more polish.
It depends on what you're looking for! I'll give just a handful here, but I'm happy to expand if you have a specific follow-up questions to these.
If you're interesting in something very D&D-like, there's obviously Pathfinder 2E[1], which builds on the same D&D skeleton but has a much sharper and cleaner approach to grid-based tactical combat. However, I'd also suggest looking at some of the games in the OSR ("Old School Renaissance") space. Games like The Black Hack[2] or Maze Rats[3] provide a much smaller set of rules which are easy to adapt to other adventures: the goal is that you can take adventure modules for effectively any existing D&D-like game—including both present and past versions of D&D—and run them with little overhead.
Something pretty different mechanically but which is quite compelling in that space is Torchbearer[4], which is based on the underlying Burning Wheel[5] system but made significantly simpler (and shares a lot of those simplifications with Mouse Guard[6] except it's, well, not about sword-wielding mice.) Torchbearer is a great dungeon-crawl-focused system that can really capture grit and difficulty in a way that's a lot of fun, but it's also the kind of game where you can get a total party kill not just by a dragon but also by running out of food and torches, so expect a grimy tough game out of it!
If you're looking for something even further afield, I'd suggest taking a peek at Dungeon World[7], which borrows the core mechanics from indie darling Apocalypse World[8] but applies them to a traditional D&D milieu: that said, I'd actually start with Homebrew World[9], which streamlines and clarifies a lot of the rules, but it might require Dungeon World itself to get a handle on how to run the game. Games inspired by Apocalypse World—sometimes called Powered by the Apocalypse games—definitely play a bit differently—they tend to be a bit more "zoomed-out", e.g. combat being resolved in a fewer high-level rolls rather than playing out a full sequence of six-second slices like D&D—and they aren't to everyone's liking, but I think they're worth trying.
I'm also going to plug my personal favorite tabletop game, Blades in the Dark[10], which is not a traditional fantasy game (although people have adapted the the rules to more traditional fantasy, c.f. Raiders in the Dark[11]) but which I think is super compelling. It's about criminals in a haunted Victorian-ish setting doing odd jobs, and builds a system that's top-of-its-class for doing that, including mechanical support for heist-movie-style flashbacks and a lot of systems designed to let you do risky moves and narrowly avoid failure from them. Some of my absolute favorite TTRPG moments have been in Blades games.
Any of that sound interesting? Want other examples or directions?
Thanks for your detailed response, it's excellent and so kind of you to give me such detailed suggestions. I feel I have to check out every single one of these systems. I only knew Pathfinder and Dungeon World.
I like the idea of the OSR systems with small rulesets. So I'll check The Black Hack first. Do you know about any systems like this one that have been published under the Creative Commons license?
The other one I mentioned—Maze Rats—is licensed as CC BY 4.0, so that might be a good place to start! (The Black Hack is licensed under the OGL 1.0, which unfortunately means it's not immune to the whole mess that this thread is about, but I'm hoping that a lot of the creators who put stuff out under the OGL 1.0 either come up with a new license that's not associated with WotC or relicense their stuff under something like a CC license. I guess we'll see!)
It's kinda wild to watch HN suggest that a tech company can do as well as established tabletop gaming companies as if it's as easy as asking ChatGPT. I suppose considering how beloved Tesla and Theranos were I shouldn't be surprised.
DnD has inconsistent quality and has a ton of rules, but few of them add much value. There's really not much polish either imo. The vast majority of the rulebook get ignored because they don't make the game better and often make it worse. The current generation of players, largely inspired by the rise in acceptance of geeky hobbies, by Critical Role and similar shows, etc, would be better off with a different system entirely. These people play to have fun with friends, to have exciting stories and moments, not to follow the ten thousand rules and baggage dnd has acquired over the years.
Dungeon Masters make or break the game. They do it by storytelling, by presenting challenges and helping players overcome them, by creating a sense of ownership and reward. DnD is not good at teaching people to do those things.
I've played some other systems, and immediately they were easier to play and more fun for the group. You don't need 20 rule books, you need a simple set of rules and a desire to participate in a shared storytelling experience, and that's really it.
> Sure, but do any of them have the quality and polish to replace DnD?
D&D isn't anymore polished than Runequest or Warhammer in the commercial space, or a ton of Creative Common RPG. D&D is just more popular. This isn't polish, this is "corporate".
Also, as was obscured by the title mangler, the "dead" in the title is just a side remark; the title without the parenthesis is "10 most influential programming languages", and "(ly dead)" after "most" is just a parenthesis.
Maybe we'll just revert to the linkbaity title in this case. I had it briefly as "Mostly-dead, influential programming languages (2020)" but that probably did more harm than good.
Just curious: How do you determine whether the title change worked? Do you try it out and then check back later to see whether commenters are still getting hung up on the topic?
Well, it's not a claim that these are the ten most influential programming languages. Lisp was clearly more influential than most of these, but it didn't make the list because it's still alive.
I think the title was mostly just a pun/riff on the title of the other post linked in the first paragraph, which did claim to be a list of the most influential languages, and doesn't really make sense if read as a specific concrete claim.
The short form is that Corrode is effectively deprecated in favor of c2rust. Indeed, Corrode hasn't been updated since 2017, while c2rust still gets active development—last commit as of my writing this was 2 days ago.
It's worth noting that the developer of Corrode was consulted on the early design of c2rust, which means c2rust was able to benefit from hindsight on architectural decisions in Corrode. That ended up leading to a bit of a messy history between the two (c.f. https://jamey.thesharps.us/2018/06/30/c2rust-vs-corrode/ with HN discussion https://news.ycombinator.com/item?id=17436371 —although I believe that after that blog post the c2rust developers did end up acknowledging their inspiration and apologized for not doing so earlier.)
> This all works, people have been doing it for years in C, C++, Java, Rust, and more. In Zig, we can do better.
We can also do better in those other languages, too. For example, in Rust, I can use a crate like `bitfield` which gives me a macro with which I can write
Don't get me wrong: it's cool that functionality like this is built-in in Zig, since having to rely on third-party functionality for something like this is not always what you want. But Zig is not, as this article implies, uniquely capable of expressing this kind of thing.
C has them and their implementation seems to be universally disliked. Using an external crate with an implementation that people do like, with the possibility to substitute another if you disagree, seems better than to force a specific implementation into the language (that people will then replace with external dependencies or that people will learn to avoid as a concept).
Sometimes, there's value in providing a standard way of doing things. Even if it isn't perfect in all cases (or even a median case), then at least most people coalesce around how it's used and its limitations.
But yeah, sometimes it's better to have options. If it's common functionality though, there will likely be 1000 different implementations of it that all just slightly differ [0]. Perhaps it were better for that effort to be put into making the standard better.
I don't think there's a universally correct answer by any means, but for something so common as bitflags, I think I personally lean towards having a standard. Replacing an implementation wholesale feels like it should be reserved as a last resort.
Either way, I think mature pieces of software (languages especially) strive to provide a good upgrade path. Inevitably, the designers made something that doesn't match current needs. Even if it's just that "current needs" changed around them.
[0]: And if we subscribe to Sturgeon's Law, 90% of those are crap, anyway. Though they might not appear so on the surface...
As long as the compiled code is just as efficient as it would be had it been built-in to the language, I don't see the issue? Bitfield ops are very low-level constructs that are only useful in very specific project types. Their portable usage can be tricky, it's not something a majority of coders should reach for.
That's the luxury of a standard build system: essential but rarely used features can be left out of the core language / lib because adding them back in is just a crate import away.
There are lots of reasons to not want it built-in e.g. it makes the language more complex, and if bad semantics are standardised you’re stuck with them.
If the language supports implementing a feature externally then it’s a good thing, as it allows getting wide experience with the feature without saddling the language with it, and if the semantics are fine and it’s in wide-spread use, then nothing precludes adding it to the language later on.
It’s much easier to add a feature to a language than to remove it.
It is not at all the point of this talk, but as a side-note:
> …the functional programming language Haskell [compiles] via C, for example…
This is not correct. GHC, the de facto Haskell compiler, targets an intermediate language called C--, which resembles but is not identical to C and was explicitly designed as a compiler target. The point that some languages do compile to other high-level languages is true—Nim and Haxe being some good examples—but it is not true of Haskell.
> Use the C code generator. Only supposed in unregisterised GHC builds.
> This is the oldest code generator in GHC and is generally not included any more having been deprecated around GHC 7.0. Select it with the -fvia-C flag.
> The C code generator is only supported when GHC is built in unregisterised mode, a mode where GHC produces “portable” C code as output to facilitate porting GHC itself to a new platform. This mode produces much slower code though so it’s unlikely your version of GHC was built this way. If it has then the native code generator probably won’t be available. You can check this information by calling ghc --info (see --info).
This research is built on some pretty shaky ground—including some very loaded picking-and-choosing of vocabulary—and because it doesn't have very strong predictive power, hasn't made much of a dent in the community in the last decade since it's been published. Here's a discussion from the blog Language Log that discusses a lot of the methodological problems that show up: https://languagelog.ldc.upenn.edu/nll/?p=4612
Nuts, you beat me to it; I was going to provide that exact same link, together with an excerpt from a comment: "The LWED database reconstructions just aren't good enough to form the basis of a successful effort along those lines."
Aside from the specific details, I feel like papers of this nature would be on much firmer ground if they included controls. In this case for example, that would mean showing that are greater word-correspondences in these eurasian language families than with other language families.
