Blow and Muratori gained a following of engineers by bashing existing popular languages and engines, claiming they were all garbage.
They both started this after the Witness came out, 10 years ago.
Since then, guess how many games Muratori has shipped? 0. (He cancelled his announced game.)
Guess how many Blow has shipped? 0 so far, but it sounds close now.
These engineers spent their time ragging on other developers for slinging bad code and doing things horribly, meanwhile those developers were shipping games and apps and all sorts of other stuff.
That's kind of a rediculous assessment. "How many games have you shipped in the last 10 years" is the standard for how good your advice is.
John has made two games + one soon in the last 17 years. Braid started off the indie boom, and the witness was a blockbuster hit. Casey works on game engines and optimization, and has an entire video series about writing a game from scratch.
I agree that some authors don't ship any actual software and engineers should stray away from their advice, but this is not that case.
To be fair, I had not heard of the Witness until well after it came out.
Braid came out the same time XBox Indie Games.
I will say, I do not find a lot of their rhetoric convincing. Especially for people who have never attempted to write the software they are criticizing.
Blow only writes single player games that do not persist significant data to the machine. Nothing bad happens if your save file is corrupted. Nothing of value is lost if scene transitions have a bug.
But they're going to tell me that hyper-scaled multi-user real-time software is written poorly?
Also, I've been watching Muratori's Handmade Hero series. The deeper it gets into the game, the worse it gets. At one point, he's like "Ah, I dunno, we'll implement bubble sort because we don't have time to do any other sort." Followed by a diatribe about why bubble sort is a bad name. It's a fine name. Things bubble up.
Second, merge sort is just as quick to write and faster.
But in general, they alternate between speaking in platitudes and disparaging other software.
> Especially for people who have never attempted to write the software they are criticizing.
E.g. Casey and Blow often criticise the Visual Studio debugger. It's slow, has quite limited functionality. And it progressively gets worse over time (e.g. it can no longer update watched values at the same speed as you step through the program).
Do they both have to write a debugger to demonstrate how bad it is?
You don't have to write some software to criticise how bad it is. E.g. I cannot but make fun of Discord for implementing "we will intentionally kill our app if it consumes 4GB of memory and are very good at prioritising fixing memory issues seeing a whopping 5% improvement for p95 of users": https://www.reddit.com/r/discordapp/comments/1pej7l7/restart...
Doesn't mean I have to write Discord to criticise it. All I need is an understanding of rather basic performance and of general engineering practices.
> Especially for people who have never attempted to write the software they are criticizing.
Casey was criticizing new Windows Terminal got into an argument with Microsoft's project manager that said that it was impossible to implement optimizations that Casey talked about. Well, Casey reimplemented terminal, it was not that hard.
Part of the purpose of the series of Handmade Hero is to build a game from the ground up with no dependencies. So I don't think he's bringing in stdlib
So he could use that, but goal is to be someone who doesn't necessarily need to do that.
At some point I think he caved and just started using OpenGL. I don't know because he turned off all of the comments on his youtube channel. I think the only thing he's demonstrated is how bad an idea "building a AAA game entirely from first principles" is.
He says verbatim his goal is to be a stepping stone for serious engine programmers (not necessarily "general purpose", but definitely AAA-level), even though obviously we are not going to be making a AAA game for obvious reasons :)
So fair enough, but between that and his claim that he's showing people how to create a "professional quality" game I think the difference between a AAA game and a "AAA-level" game engine has no distinction, it's basically the same thing.
Is what he has done so far professional grade, capable of "AAA-level" games? I don't think so, but I concede that probably depends on what your parameters for "AAA" and "professional quality" are. It might be fine for indie games but it seems to me that Casey was selling an audience on revealing something deeper.
The point is that Blow has two blockbuster hits under his belt and can afford to take a decade to ship a single game. Most people would go broke never having shipped a game if they tried to do things Blow's way.
Soulja Boy never made any videos about Garry's Mod
This is kind of a joke and I know he was mostly poking fun at Braid but this does speak to how mainstream indie games got in that first wave that hit XBLA.
Casey hasn’t worked on game engine or engine tech in almost a decade. That’s not to say he doesn’t know what he’s talking about, but imho it’s important to be aware that he hasn’t worked on a real shipping product in a long time.
another POV is, business IT projects fail at a higher rate than video games do! the people who post about "shipping" are projecting: "at least my garbage is delivered frequently, which is key to being employed, not key to creating meaning."
He didn't need to finish it in order for it to have an impact. Makers of FilePilot and Animal Well both attribute Handmade as being big inspirations for them to go the way they did. They said, they got the most value from the first 50 eps or so. You'll hear lots of them on the Wookash podcast.
So for your opinion to carry any weight, please enlighten us as to the games you have shipped that qualify you to comment on their take on programming practices.
Not really. Let's reverse the situation on you - why should we take your opinion seriously, we have no idea how much you have shipped, if anything at all, so by your logic, your ragging on the other programmers practices is ridiculous.
I've shipped a few things over the years, but doubt I have strong takes in programming, besides 'the "properness" of a variables name is dependent on the amount of lines between it's definition and usage.' Doubt anyone will take my considerations seriously.
I'm not making any claims about programming practices
If someone comes out saying "you guys are all doing this wrong" and yet they can't finish their own project then why would I take their advice seriously?
If you suggest a way of doing software development and you can't even show it working out to completion, what does that say about your proposed methods?
I had a larger rant written, but this is the only part that had any value:
Yes, one can argue that lack of produces results does not give big plusses towards their work processes, but it does not necessarily negate the value of the concepts that they preach.
The value of a thing is not only defined by who is spouting it, one must evaluate the argument on it's own merits, not by evaluating of the people yelling about it.
There are plenty of concepts in this world that I cannot make work, that does not mean that the concepts are bad. It only means that the failure reflects on me and my in-capabilities.
And this might be something that you are not noticing: You are making claims about programming practices indirectly by stating that THEIR practices are not worth considering due to lack of shipping anything.
It's not really the same. Casey is suggesting people that don't spend 10 years crafting everything from scratch are somehow "lesser than." The user you're replying to is pointing out that Casey has set a completely arbitrary rule for game quality that conveniently leaves out his inability to ship something, and that's funny.
We're not saying games taking longer than a few years are failures, we're saying good games can encompass both approaches. But Casey, and his followers, are doing purity tests to feel good about themselves.
And this is assuming the games they ship are even good or noticeable to the user. I don't much care for Braid or The Witness, and I don't want my favorite dev studios to suddenly write everything from scratch every time. I would have a lot less fun things to play.
If you mean Computer, Enhance!'s Performance Aware Programming series, it's ongoing, but the pace is slower than about 1.5years ago. Given how good it is, and how fastidious and comprehensive Casey is, I imagine it doesn't really pay for itself, even with an impressive subscriber count.
I give Blow a little benefit of the doubt just because spending all of your money on your small business and seriously facing the risk of failure is pretty stressful. I'd be a lot meaner than he is if I were in his situation.
I think I'll judge that by looking at how convincing their arguments are (some are not, I think), not by raw output. After all they already output a lot.
He wrote this whole game in it. Apart from that, a couple dozen or hundreds of beta-testers. Not sure whether the language ever gets released, maybe he's too worried about having to maintain it and not being able to change it anymore.
> Since then, guess how many games Muratori has shipped? 0. (He cancelled his announced game.)
On one hand I'm sympathetic to this view point, on the other, he's done thousands of hours of YouTube videos and inspired a ton of programmers.
> Guess how many Blow has shipped? 0 so far, but it sounds close now.
Not going to lie, it's probably difficult being financially secure and still hustling like you're broke. I imagine it's more by choice (to do other things) than being unable to ship.
Why are they being criticized from the arbitrary metric of the last 10 years, when both had careers far longer than that? Jon's advice for software is the same advice he used when developing Braid and the Witness, which are both great games and for their time, technological feats, especially from an indie.
Jon's production from the last 10 year isn't even due to bad software methodology from what I observe, it's mainly seems to be because his company is creating a new programming language tailored to games. This doesn't seem to be done to make money, but rather, to try and fundamentally fixed issues that he perceives in game development. It's a lofty goal, and the compiler itself uses the same software methodolgy that he argues for, and it's quite good.
So I don't think this critism is fair. We should look at the arguments they present, and their multi-decade long careers as a measure of thir authority on this subject.
I broadly agree with the author’s point there, but disagree with the specific language he used. In my view, engineering includes those pesky non-technical considerations, like the business context and the human factors, which bring their own tradeoffs and priorities to the engineering decision-making.
That is, his “pure engineers” are not really doing engineering, at least under my understanding of the term, whereas (some of) the impure engineers actually are! :)
I don't much about casey, but jblow seems to have gotten popular partly because of the timing with live streaming becoming mainstream and also because people find his brash "tell-it-like-it-is" opinions refreshing. It's the same reason why people tend to gravitate towards guys like linus or stallman. Having opinions and not being a fence-sitter makes you interesting.
If there's anyone who I think deserves to be able to say "all existing languages/engines suck" it's someone who made his own language from scratch to make an engine with it from scratch to make a game with it from scratch to combat the problem.
What? Its about 3-5 years for a AAA game and you ideally pipeline things such that a studio is shipping somewhat frequently. Almost no one can front a decade worth of development without shipping anything.
Where are you getting a decade from? Consoles ship more often then that.
Square Enix: so so many but at least a few FF14 expansions, FF15, Nier: Automata, Dragon Quest XI, Octopath Traveler, Kingdom Hearts III, Final Fantasy 16, Final Fantasy VII Rebirth
Bethesda: The Elder Scrolls Online, Fallout 4, Fallout 76, Starfield
Epic: Robo Recall, Fornite.
Epic cancelled Paragon and Unreal Tournament and Fortnite is a live service game where they're constantly shipping content so its harder to define single releases but they have new money coming in from new content.
And these are only from the main studio, not the dozens of games published by these entities.
There's plenty of examples there of multiple games per studio. Hard to get public into per "team". Teams are mutable within a studio and devs roll off and onto other teams.
Arguably teams are tied to and only ever ship a single game so I'm not really sure what you're arguing at this point.
Someone can't honestly write this unless they aren't a fan of games to begin with. Are you saying the Clair Obscur devs don't care about their craft because they used Unreal Engine?
There is a massive gap between Handmade Hero and a bloated, unoptimized game. It's one thing to be a purist that wants to do everything Handmade Hero style. It's another thing entirely to claim people who don't do that are hacks who don't care about their craft. There is A LOT to game development other than writing things from scratch.
Casey has made great resources, but I understand OPs frustration. He's created a culture of devs that think people shipping games over 100mb are soulless profit chasers. Animal Well is awesome, but not everyone wants to spend 7 years making a platformer.
Probably a nuanced point in what's the purpose for espousing the virtues of performance if you don't have the output to show it is worth it?
If you want advice about making games would you rather learn from the person that routinely ships games or a person that shipped a game once 10 years ago?
Is that a trade off worth chasing? "Potential perfection" with nothing to show for it?
More like, shipped 2 hit games, which were both technological and artistic feats for their time. And developed a blazingly fast compiler. Casey also was a developer in RAD game tools developing animation tools. Their output is probably better than most industry developers. I understand if you don't like their attitudes and the way they attempt to teach/preach to other engineers, but IMO their work speaks for itself. I take their advice and try to apply it to my own work, because it seems to have work for them.
I'm not saying I don't like their attitudes but it's a viewpoint I am struggling with myself.
I'm starting to realize caring about all these minutia of details that don't really matter for my professional goals. I know my software isn't special, caring about pumping out as much performance as possible when I just sling JS professionally feels a tad myopic?
What is the point of it just continues the pattern of procrastination towards the actual goals I want to achieve? Does this also apply to them?
What is the point of espousing all these supposed virtues when the output isn't that special? I mean Braid is still good, but let's not act like greener devs haven't put out good games too without all the jackassery baggage.
Yea I largely agree with you on that point. I think when discussing Jon, Casey (and to add another, Mike Acton), there's actually a series of advice that they give that get lumped into a whole, and people don't really see the parts of what they're saying and instead focus on the part that sounds most critical to their work.
I do agree that if you take from their "teachings" that every dev needs to optimize every thing, and never use any other language than system languages, that advice is myopic for most devs. However, I don't really see them arguing for that, at least not entirely.
From following their teaching for a while, they mostly preech about the following things which I agree with, even when talking about higher-level languages, technologies.
- Get the clowns out of the car: Don't make things needlessly expensive. Write simple procedural code that maps cleanly to what the hardware is doing. This is essentially stating OOP, large message passing, and other paradigms that abstract the problem away from the simple computations that are happening on your computer is actually adding complexity that isn't needed. This isn't about tuning your program to get the highest amount of performance, but rather, just write basic code, that is easy to follow and debug, that acts as a data-pipeline as much as possible. Using simple constructs to do the things you want, e.g. an if-statement versus inheritence for dynamic dispatch.
- Understand your problem domain, including the hardware, so you can reason about it. Don't abstract away the hardware your code is actually running on too much where you lose vital information on how to make it work well. I've seen this many times in my professional career, where devs don't know what hardware the code will be running on, and this inevitably makes their code slower, less responsive to the user and often drives up cost. There are many times in my early career (backend engineering), that just simplifying the code, designing the code so it works well for the hardware we expect, greatly lowered cost. The hardware is the platform and it shouldn't be ignored. Similarly, limitations that are imposed by your solution should be documented and understood. If you don't expect a TPS greater than some value, write that down, check for it, profile and make sure you know what your specturm of hardware can handle, and how much software utilization of that hardware you're getting.
- Focus on writing code, and don't get bogged down my fad methodologies (TDD, OPP, etc). Writing simple code, understanding the problem more deeply as you write, and not placing artifical constraints on yourself.
Now each of these points can be debated, but their harder to argue against IMO then the strawmany idea of them proposing that you must optimize as much as possible. And they argue that you will actually be more productive this way, and produce better software.
FWIW, you may have some datapoints showing that they do propose what I called a strawmany version of their ideas, but I have seen them advocating for the above points more so than anything else.
---
I do want to add, for Jon Blow, I don't think he has a problem with people using engines. From what I've seen he's played, and loved games that used engines in the past, and had no problem with their output in terms of gameplay or performance. From his talk about civilization ending relating to game dev, he's more concern that if no one tries to develop without an engine, we as a civilization will lose that ability.
> I don't think he has a problem with people using engines. From what I've seen he's played, and loved games that used engines in the past
He's also said quite openly that if you're only starting, it's fine if you reach for a ready-made engine. It's that you should try and understand how things and systems work as you progress.
Yes, this is well put. I was heavily influenced by Casey back in 2014 and the advice I give juniors now is always that first point about "getting the clowns out of the car". There's a lot of crossover with the "grug brained developer" here too, which is much more aligned with the web/enterprise world.
I find it very hard to convince people though. It runs counter to a lot of other practices in the industry, and the resulting code seems less sophisticated than an abstraction pile.
Aha! I think I know my contention with this advice now. Who can actually disagree with this? Like I'm saying yes to everything, no one I know would say no to this. Never had a coworker say aloud: "I want to write code to make things worse."
These are the platitudes of our industry that no one disagrees with. Like you said, this is what Blow + Muratori teachings can be distilled into. But there is something worse it also assumes, coming from such people.
Both Blow + Muratori have extremely privilege dev careers that a good ~80% us will never achieve: they have autonomy. The rest of us are merely serfs in someone's fiefdom. Blow has his fief, Muratori his. They can control their fiefs but not the majority of us devs. We don't have autonomy in the direction of the company, we don't control the budgets, we don't even control who we interview or hire.
Assuming that this onus of organizational standards has to be placed on someone with no authority to dictate it isn't just. Also as someone who has consumed content from these two for about a good 8ish years as their videos pop into my feed: I've never see them advocate for workers to be empowered to make their environments better. They mostly just trash on devs that have no authority.
With that mindset I need to seriously decouple myself from these people. Plenty of other devs advocate for the same things in our craft while also advocating for better rights as workers.
Some people actually have mouths to feed. Some people don't have the luxury of preaching for whatever ideals they have without a need to release anything in 10 years; that doesn't make their products "garbage".
> Some people don't have the luxury of preaching for whatever ideals they have without a need to release anything in 10 years
Wait, how did they gain this "luxury"? Are they trust fund babies or something?
Or did they earn their big stash of money by producing "garbage" and now retroactively are preaching ideals that they themselves didn't follow or what?
This line of "criticism" doesn't make any sense whatsoever.
After all both in question live off money they've made and/or are making from their (arguably) uncompromised quality work.
That is to say their uncompromised quality work has directly resulted in them being able to not release anything for close to 10 years, and practice their ideals in software they ship even if the "shipping" takes 10 years to do.
It would be more fair to say, that most people don't have the craftmanship and skill (and not the luxury) to be able to produce high quality work and software that enables them the so called "luxury".
>Or did they earn their big stash of money by producing "garbage" and now retroactively are preaching ideals that they themselves didn't follow or what?
In the JBlow case - yes, he made his money using C++. So far, he hasn't shown that using Jai is particularly productive for software engineering.
> So far, he hasn't shown that using Jai is particularly productive for software engineering.
And how would he do that exactly to whatever ungodly standards you are setting for the man?
Many people have criticized C++ in past (which is very easy to do), yet he's practicing what he's preaching in the most direct way humanly possible, he's both (1) designed and implemented a new programming language (that has directly addressed most of the issues), whilst (2) also making a complete non-trivial game in the newly designed language at the same time.
His games have always taken long time to make, and now he's making game + engine + programming language. At the same frigging time!
The only "luxury" JBlow has is that he's an exceptional individual and you're not. He has rare combination of ability, perseverance and work ethic, and by all accounts most people are neither of those things at once.
Most criticisms 99% of time are either misrepresentitive, misinformed jealousy or something to do with politics.
I have no issue with personally acknowledging that some rare individuals are simply way better than me.
And to prevent sounding like a gushing-fanboy, I suspect that his newest game won't sell very well, because his first two games have atleast something to appeal to general public (either visuals of Witness or time travel mechanics (somewhat novel at the time) of Braid) while this game doesn't appear to have the same draw.
This game has too much of a generic-sokoban puzzler vibe to it to appeal to the general public who aren't already ardent puzzler fans (and are there enough of those and can he reach enough of them? etc). And the trailer doesn't help to change this perception.
>And how would he do that exactly to whatever ungodly standards you are setting for the man?
By providing a result in a way that will be superior to the current status quo. Maybe there will be results, but right now there are none.
I have no idea why you are so invested. I don't care about the man's personality or whatever qualities he has. I look at what he does, and so far, he spent 10 years making a game that you yourself admit won't be even that good.
Of course, you could say that changing the course of the industry not possible in one man's lifetime, so you'll need to gather round more people to get the action going, but this tone actually prevents you from starting a Jai revolution.
>I don't care about the man's personality or whatever qualities he has.
The only thing I'm addressing is the so called "luxuries" you alluded to, and the alleged "luxuries" he has is directly a result of his personality and his qualities.
The only reason you don't have those so called "luxuries" is because you're not even in the same ballpark as good. It really is as simple as that.
> By providing a result in a way that will be superior to the current status quo.
But he's done exactly that.
> I look at what he does, and so far, he spent 10 years making a game that you yourself admit won't be even that good.
I'm not saying that the game won't be good necessarily, I'm saying the game probably might not sell very well (atleast not to justify the amount of money spent from purely business perspective, etc)
He hasn't. He made a programming language that allows making a sokoban game in 10 years. That's probably not what people need. The industry can make similar games in a course of several months. It doesn't look like a groundbreaking achievement to me. A monumental amount of effort, sure, but the _result_ isn't there.
Plus, _in the past_, he made Braid, in C++, in a relatively practical way. He made money using the industry standards, now he loses money deviating from the industry standards. The question I'm interested in is: why would anyone listen to what the man _says_ if his own preaching makes him lose money?
But okay, you don't want to hear any of that. You keep fixating on the "luxury" part. The reason we talk about JBlow is because he made Braid back in 2008, and it was an awesome game, and it sold well. More importantly, the timing when it released - it was what kicked off the boom of the indie game development back then. He also made The Witness, and although it was also a good game, it was most likely not as groundbreaking as Braid, considering that he chose Braid instead of The Witness for a remaster. And then he complained that it, quote, "sold like dogs**", end of quote. Unfortunately, what was the jewel of the indie game development in 2008, doesn't really excite the audience that much in 2024. The world has moved on.
The music indsutry is well aware of a phenomenon of a "one-hit wonder". If the JBlow's qualities were the only reason he could make Braid and get rich enough to not release anything for a decade, then surely anybody with these qualities could make Braid 2 and do the same thing, correct? Well, nobody can do that. Not even JBlow himself. Not anymore. It's not 2008.
> The music indsutry is well aware of a phenomenon of a "one-hit wonder".
He made two hit games, Witness was released 7.5 years later.
> Within a week of release, Blow stated that sales of The Witness had nearly outpaced what Braid had done during its first year of release.
> The Witness is widely regarded as one of the best games of the 2010s. The game appeared on 'Best of the decade' features from IGN,[103] Polygon,[104] NME,[105] CNET,[106] and National Post.[107] Edge considered the game the 22nd-best game of all time in 2017
Calling him "one-hit wonder" simply has no basis in reality.
He's at minimum a two-hit wonder.
> it was most likely not as groundbreaking as Braid, considering that he chose Braid instead of The Witness for a remaster.
Now you're making shit up on the spot to make an argument.
Think for a second will you, how exactly would he remaster Witness? Braid Anniversary Edition was announced on 2020,
at which point Witness would merely have been ~4 year old game.
Braid was also made for a 720p console, the Xbox360 Xbox Live Arcade service, so remake atleast makes some sense.
> The question I'm interested in is: why would anyone listen to what the man _says_ if his own preaching makes him lose money?
What exactly is he _preaching_? Not what you have cooked up in your mind, but actually _preaching_?
Why would anyone pay attention to the man who has made TWO hit games in a row, and a third one in his own programming language (that has inspired countless other programming languages like Zig and Odin), yes, why indeed people would listen to an exceptional guy who has repeatedly demonstrated competency and delivered results, whilst always putting it all on the line?
Can you make atleast one hit, not two, just one? Or anything of note?
No you can't, you can do nothing, that's why you don't have the "luxuries" and people don't listen to you, but pay attention to him. You might not like it, but it is what it is.
And you like to comfort yourself with the thought that you don't have some sort of unearned "luxuries", because otherwise you would do great things.
But the reality is that he's exceptional and you're not.
That the game development industry requires a new programming language. So far, the evidence for that is slim. (I mean, metaprogramming with #run is cool, I'm also fed up with cmake. But surely we don't need to throw away all of our C++ tooling for that? Nah, we probably need something more incremental.)
> Calling him "one-hit wonder" simply has no basis in reality. He's at minimum a two-hit wonder.
Okay, I've been corrected. The Witness also sold really well. So he's a two-hit wonder, he clearly had developed a process to make great-selling indie games. I admit that, I admire that. (I only said good things about the guy anyway, why you would call me a "hater" is beyond me.) But now, he deviated from this process. His primary goal now is clearly not to create a good game, but to promote Jai.
> why indeed people would listen to an exceptional guy who has repeatedly demonstrated competency and delivered results, whilst always putting it all on the line?
Because there are limits to everyone's competence. It's like a generalized Peter's principle - being successful in one area doesn't mean you'll succeed in all others that you put your hand in. Even John Carmack didn't really succeed in rockets.
After all, the game dev industry is showbiz. Its ultimate goal is entertainment. JBlow is an entertainer, first and foremost. There are a lot of musicians and actors more influential than JBlow, does that mean I won't be a fool if I listen to their opinions on anything more important than what to eat for breakfast? No, not really. And in the same way, not a lot of people will choose Jai for programming, not in the next 20 years for sure.
> Can you make atleast one hit, not two, just one? Or anything of note?
No, absolutely not. I'm actually the most useless creature of all, good for nothing (other than keeping you engaged, apparently). You got me. And I'm not even trying. I'm not trying to preach for anything, develop new industry approaches or whatever. I'm just humbly making a point: but even if I weren't the most useless, I wouldn't be able to reach the JBlow's heights. Even if I had the same set of skills that JBlow had in 2008. For example, a notable part of the success of Braid was thanks to a contract with Xbox Live Arcade, and where is XLA now? The world has changed. The market has changed. The audience's needs have changed. Becoming an indie dev of such caliber now requires a different set of skills, one that a single person might not even physically have.
At some point, you'll have to admit that (1) it's not only the qualities and the hard work that brought JBlow to where he is, but also sheer luck, and therefore (2) yes, it's a luxury. If you don't believe in (1), well, okay then. But if you agree with (1), from that (2) trivially follows. If it doesn't for you, then it's purely semantics, I guess.
> That the game development industry requires a new programming language. So far, the evidence for that is slim.
I love how you one hand acknowledge your severe lack of ability and achievement. And yet at the same breath you confidently put forward to know better - than JBlow no less - what the game-dev-industry or world at large needs. Or that you'd even have the ability to gauge evidence for it(or lack of it).
What evidence would even qualify as proof that game-development-industry (or world at large) requires a new programming language?
What is the exact threshold of "suck" that you have to cross before you go "yup, we need something different"? Does such threshold even exist?
And how do you measure it?
> There are a lot of musicians and actors more influential than JBlow, does that mean I won't be a fool if I listen to their opinions on anything more important than what to eat for breakfast?
Is John Blow making bold opinionated statements about fine-dining or something?
No? Then what are you even talking about?
Why are you constantly making shit up to discredit the guy?
This is NOT rational behavior, its some sort of ego defense:
"like how dare he say bad things about C++, who does he think he is (just some one hit wonder game-designer, just got lucky!)? He has no idea what he's talking about!"
Except, he making statements about a language that he has used extensively for more than 25years at this point. And used it to ship large, intricate, largely succesfull hit-games all with their own engines where he has done bulk of the programming work.
That is to say, you can HARDLY find anyone more competent and suited to comment on deficiencies and shortcomings of C++, and how to improve them and fix them.
Now, just because he makes astute observations about various defects in C++ doesn't make him special, after all C++ is extremely badly designed mess, and it is very easy to do so, and thousands of people have done so.
What makes him special - is that he - has mostly delivered on this (stretching himself thin in the process), whilst also making a large game at the same time. This is very rare and exceptional.
> metaprogramming with #run is cool, I'm also fed up with cmake. But surely we don't need to throw away all of our C++ tooling for that? Nah, we probably need something more incremental.
Who is this council of "we" you're refering to? A council of average Joeys that haven't shipped anything of note and is more concerned with whats "cool"?
You have roughly zero idea what the actual painpoints of making and shipping large games are.
His latest game does full rebuilds in 2 seconds, so he can iterate and make changes quickly.
There are no "incremental improvements" that can be done to C++ to suddenly make builds not take MULTIPLE MINUTES.
> JBlow is an entertainer, first and foremost.
This is what you have got wrong, JBlow is an exceptional programmer first and foremost, who also happens to be a pretty good at thoughtful gamedesign, and pretty good at doing public speaking, among other things.
> a notable part of the success of Braid was thanks to a contract with Xbox Live Arcade
Notable part of success is that he made Braid interesting enough to win "innovation in game design" at IGF.
Winning IGF ment he got contract with XLA (interested in making money and promoting platform)
This is a deterministic process, there's no dice rolls or lottery draws involved here.
If you're exceptional and you make exceptional things you succeed sooner or later, statistically speaking.
The whole thought process that if you spawned another much younger JBlow in 2026, he would be attempting to make another verbatim Braid, instead of something completely different - way more attuned to current market conditions is not very bright. He (the young JBlow clone) might not even choose to do games in these market conditions, he might chose to do exceptional, highly influential work in a completely different domain.
What however is highly likely is that he'd be highly, highly successful at whatever it is. Because highly exceptional hardworking people just succeed (unless they are born in Mumbai or Karachi)
I mean, if you're born as an average Joey, instead of being born exceptional, it is _luck_.
After all, who would choose to be average when they can be exceptional and bright?
But it is important to acknowledge at which point luck materializes.
And the lucky event wasn't XLA at 2008, the lucky event is beign born exceptional.
Most people would call being born rich a luxury. And not - being born exceptional and applying the said talent and hard work to ever more ambitious projects.
> Even John Carmack didn't really succeed in rockets.
He was very successful at engineering aspects of rocketry considering his very small and completely self funded budget. Just not comfortable burning 1mil of his personal funds / retirment money per year (that was still considerable money to burn out of personal stash in 2007/2008)
Just to be clear, your comments are implying everyone who doesn't write everything from scratch is shipping garbage.
Ignoring how misinformed that opinion is, I would say The Witness is a very compromised game. Maybe if less focus went into the technical aspect, it could've been better.
Fact of the matter is that code quality is a pretty small part of whether a game is good or not. It can be notable when it's good and it can sink a game when it's really bad, but there's a huge gap in the middle where it doesn't really matter that much (especially to the player).
Discourse | Full Stack Engineer | Remote | Full Time
Discourse creates open source forum software in Ruby on Rails and Ember.js. We've always been 100% remote and are hiring for a few positions right now so please check out our web site:
In Toronto mortgages don't work this way. Fixed rate mortgages are typically 5 year terms. After the term is up they'll have to get the higher interest rate.
Well that's all up to the buyer, but most people are risk averse when it comes to their home. The default mortage term is 30 years, and most people fix the interest rate 20 or 30 years.
People who took a shorter term for the interest rate in the past 10 years, now have a housing cost of a few hundred euros, because it came down from 3-4%.
Mortgages where the amortization period and the term are equal are extremely rare in Canada. Most Canadian fix their interest for a term of 5 years (at a fixed rate or a fixed deviation from the prime rate).
I'm not sure about those stats you posted from 3 years ago since they aren't using the same `rake stats` numbers that are built in to Rails. Discourse's Rails app is currently 63k SLOC not including tests.
On my relatively fast computer booting takes 4s without bootsnap and 2.5s with it, which is a nice quality of life improvement.
As a long time (5 years full time) Ember developer, this is quite interesting to me philosophically.
I've spent a lot of time trying to tell people that all the stuff in Ember is there for a reason; for example, you're going to need a router, you're going to need support for controllers, etc. I still feel strongly that if your app is large and serious you are going to need that stuff.
But.
A lot of people just want to jump in and start building. React's immense popularity has shown the value in creating a view layer framework without all the extra stuff. It's great for onboarding new developers since there is less surface area to familiarize yourself with, and you can add in extra stuff (work your way towards full Ember) as you go.
It also comes with the added benefit of being able to add small components to a page without running the whole thing as an application, which is a use case Ember was not so great at before.
I used Ember for about 2 years and thought so too.
Now I'm using React and I think it's approach is much better.
The API is tiny compared to Ember and there aren't much concepts, still it accomplishes everything Ember did.
I feel bad to say this, but in the modular, library heavy, NPM based JS world of today, React (and other component frameworks like Cyclejs or hyperapp) fits just in. While Ember feels like a anachronism of the big framework days of Rails. :/
With Glimmer as a standalone library, I think ember's going in the right direction. There's been some excellent work on Fastboot and Engines in the last year or so and I really like the approach ember's team is taking with this.
React, for me, still offers better composability. You deal in plain JS objects, pass them around, and can build really complex UIs on top of that. I also really like redux. I still use ember heavily though; I think we'll get there as well!
At the end of the day, the Ember team takes a lot of time to not just build things the right way, but also make it as painless as possible for teams to upgrade along the blessed path. This has been a learning process to understand how much more time that takes, and has caused some past announcements to feel like they weren't delivered on, when in fact they simply just took more time to get right.
The other lesson to take is to be more cautious about announcing stuff before its really ready. But they don't seem to have learned that here. Here we have a project with its own logo, a marketing video with a nice electronica beat behind it, and a YouTube Live announcement...
... For something they are telling you to install from their master branch.
One of the things with a large framework is that moving to a completely new direction is more challenging than it looks. So, at times, ember has made unrealistic promises — and Yehuda alluded to this in the keynote — but one can learn from it and get better.
As for Fastboot, it has its edges but there are people using it in production (DockYard is one, if I'm not wrong). ember-engines also says it's experimental and it does have some missing stuff (from my experience) but what is there works well.
Some of the things perhaps needed a rewrite of the underlying architecture. One great thing about ember (apart from v 1.13) has been just how painless it has been to upgrade. All the major changes they have made have largely been drop-in. Getting to that kind of backward compatibility is also a pretty impressive feat considering how big it is.
So, all in all, I agree that some of the things were overhyped and unrealistic but it seems they have learned from it, and I think that's just fine.
While the Ember devs talked about stuff like Fastboot and Glimmer, while other frameworks just had all this out of the box.
Their whole approach seems to be rather concept heavy and back in the days (2014/2015) the docs where horribly outdated and you had to check stackoverflow for basic things.
I had to use Ember 2 years on a project and found it clunky, but okay. I switched to React 2 years ago. And after I met a few hardcore Ember devs from back in the days, who said they switched to Angular2 or React I think this was the right decision. It's nice that the existing projects get so good support, but I wouldn't recommend anyone to start something new with Ember :\
Why would you want to build a bespoke React-based framework for every app you make? Why not simply have everything you need out of the box, plus the ability to easily integrate any npm library into your app via first-class build tooling that is miles easier to use than something clunky like Webpack?
I remember when that wave hit the Ruby/Python space, with things like Pyramid/Pylons. These days that seems to have gone the way of the dodo, with the big monoliths still being around and then some minimal HTTP decorators like Sinatra/Flask/Node. Problem is that the middle ground would require a level of modularity that we still haven't reached, despite all the talk of "software ICs" that came around with early OOP.
I predict that's how we're going to end up in a few years again. Some big monoliths (whatever react is morphing into currently, plus Angular and as the world is a cruel mistress, ExtJS), plus a plethora of DOM wrappers and view libraries.
You know that pyramid powers some of the most important infrastructure for python? Like new version of PYPI (https://pypi.org/)? And lots of big organizations use it - like Mozilla or NASA, sites like Reddit still use pylons.
IF you think it went the way of the dodo, I'd suggest doing a bit of better research before predicting the future :D Because IMO you are seriously off here.
I'm talking about the trend of build-your-own frameworks, not the software itself. Heck, there are enough sites out there still using Zope, MASON and Aolserver.
Pyramid is feature complete as a framework in my opinion - with defaults requires less thinking vs. lets say flask - the resulting applications will be more elegant and better organized (partly because it doesn't use globals eveywhere). The glue is quite good nowdays.
I've been working full time on Ember stuff for a long time now, and I can not imagine a single reason to ever fork Ember. I've used different programming languages (CoffeeScript, don't make fun), templating languages (Emblem.js, don't ask), built and served it with Rails, without rails (Ember-CLI was a godsend), and hacked at it in a million different ways. All this was supported by API's or tooling within Ember (even when it was a bad idea, which it often was).
I would really like to know what prompted you to fork Ember.
The first time it was for a sub-route that could be brought up in any other route (to show a little search pane in the app). We were told by the community just "not to do that" but it was in our spec and there wasn't a way to load the same countroller for multiple routes.
The second time was more short lived, but it was to allow asynchronous modules to be loaded after the main app. There were no community solutions to this at the time.
The last time wasn't really forking ember but we underwent a painful process of remaking most of our views in vanilla JavaScript for performance on mobile, which has gotten completely out of hand with all the two way bindings of pre-glimmer ember. It felt like we were fighting the framework the whole time.
If you go off the rails, it is extremely painful. I haven't looked at Ember in a while, because of my experiences, so ymmv. It could all be completely different now.
When and why did you fork Ember to get around it's opinions? I've been developing with Ember for 5 years now, and the only time I ever had to modify the source was with Ember Data pre-1.0.0, when it wasn't solidified at all. The concepts behind the framework are really simple, and literally everything is configurable.
That hasn't been my experience with ember in the past 1.5 years. Granted when I was first introduced to it about 3 years ago, there were many issues and I wasn't keen on using it but since then things have improved a bunch.
Nice to hear, I haven't used Ember for about 2 years now. When they started putting more effort in their CLI, this was the signal for me to jump ship and go for something more light weight.
That isn't really accurate unless you are adding additional libraries to accomplish all of the things Ember does. I'm not arguing with the rest of your post, just saying that statement is incorrect (in that it doesn't tell the entire story).
"still feel strongly that if your app is large and serious you are going to need that stuff."
My approach usually is, start minimalistic and if you need additional stuff, you can usually add it later. That is why I like React. For example if I need router, I can choose from many implementation, but there are also cases when I don't need it all.
This is a very good way to go. In my experience, adding a new tool can take a day or two of refactoring in a medium sized project; but removing one can take a week. Removing a bunch because you completely over-engineered the solution and can't maintain it can often take a month, or even get dangerously close to "scrap it and rewrite" territory, which is a complete death sentence for a small company.
Unless I'm working with people I know well, I'll often elect to start off a fresh project with just React and maybe Redux, and build from there. Even if I know full well that we'll need some stuff like thunk and react-router, my preference is to leave them out and let the team run into the problems they solve before we introduce them.
IMO even if just one team member gains a new understanding about why their tools exist and why they're using them, it's worth a bit of refactoring.
I can see where you're coming from, but I tend to bucket apps I write into either general use case, mostly business-logic apps, or highly specific services. (say, a network proxy or compositor or something) The general use case apps all tend to share a good deal of requirements (multiple pages, authentication, forms, etc) and while it would certainly be possible to pick and choose each component, it's nice to have a shared set of functionality that is well-tested together and that stays the same between multiple projects and teams.
I think adopting something like ember is pretty much the opposite of "can't maintain it" since while I understand how it works internally, I don't actually have to maintain it myself. In my experience I've seen more instances where we ended up ripping out a homegrown library to replace with a community-supported solution than the other way around.
Oh, absolutely. I wasn't trying to comment on the difference between the monolithic and modular approaches of Ember and React respectively. I think the monolithic approach actually solves the problem I'm describing to some extent, because developers in those ecosystems are forced into using these tools and patterns, which gives people a vested interest in making sure they're actually good before going into the next release and seeing widespread adoption.
redux-thunk is a great example of what I'm talking about. The design pattern prescribed by it is confusing in subtle ways. They're basically overloading the terminology of "action creators" to mean two wildly different things. The main benefit is solid (it provides a way for controllers/business logic functions to access the data store through dependency injection rather than closures, making them easier to test) but the implementation isn't well thought out, the terminology surrounding it is confusing, and it provides rookie developers more ways to shoot themselves in the foot (see getState abuse).
If any of this craziness was proposed as a core part of Angular or Ember there would be enough sane devs speaking out against it and it would be changed. But since in a modular system in React you are free to choose parts as you please, everyone that knows what they're doing just elects not to use stuff like this, until it builds up enough of a cargo cult following that it becomes standard and starts infiltrating your work place, and suddenly you're outnumbered 20 to 1 by people that have just "always done it that way".
Can you clarify what you mean by "the implementation isn't well thought out"? It's a 10-line function that basically just checks to see if the argument is a function, and if so, executes it.
Thunks _are_ "action creators", in the sense that they are given `dispatch` and allowed to dispatch things. The word "thunk" is a long-standing CS term, per [0].
I addressed the `getState` question in my blog post "Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [1]. As a summary, yes, thunks (and sagas) give devs complete freedom to do what they want, and more "convention-driven" middleware can be useful, but they're also a level of abstraction that's not necessary, and sometimes you _need_ to execute arbitrary logic that doesn't fit a specific pattern like "REQUEST_START/SUCCESS/FAILED".
'implementation' was probably the wrong choice of word there. 'design decisions' is probably better.
I'm not sure we're working with the same definition of 'action creator' here, because redux-thunk completely moves the goal posts. In redux, an action creator is a utility function which takes some parameters and creates an action, returning it. This is rather intuitive. It's purpose is to allow functions that dispatch actions to build their actions using a common interface, with little risk of generating an action in a format the dispatcher is not expecting.
In redux-thunk, an action creator is a function which takes some parameters and executes a bunch of business logic, dispatching actions created by OTHER action creators along the way. It does not create any actions and does not return any actions. It's a misnomer.
The only thing a redux-thunk action creator has in common with an actual action creator is they both implement the dispatch interface. This is not at all intuitive for new developers.
Moreover, it's completely unnecessary. What do you gain by overloading the dispatch function to do two completely unrelated things? Nothing. You could just as easily create a differently named higher order function that passes dispatch and getState into whatever function is passed into it, and it would be functionally identical.
Eh... a thunk could absolutely call `dispatch({type : "SOME_ACTION"})` rather than doing `dispatch(anotherActionCreator())`. It also allows consistent use of binding to `dispatch` in conjunction with `connect`, per my post "Idiomatic Redux: Why Use Action Creators?" [0].
The canonical explanation for why middleware is the place for async logic is in a couple of SO posts by Dan Abramov [1] [2]. Quote:
> So the benefit of using middleware like Redux Thunk or Redux Promise is that components aren’t aware of how action creators are implemented, and whether they care about Redux state, whether they are synchronous or asynchronous, and whether or not they call other action creators.
In other words, a component simply calls `props.someFunction(someData)`, and it doesn't care where the function came from, or exactly what it does. It could be a plain action creator, a thunk, or a spy in a test. If there's asyncness that needs to happen, that can be handled outside the component in a reusable fashion.
There's also precedent for overloading `dispatch` and "teaching" it to understand parameters other than plain action objects, such as promises.
I understand your points, but very much disagree with your conclusions. (In a slight appeal to authority: I'm one of the current maintainers of Redux, and keep a list of links to React+Redux resources [3].)
Anything can dispatch a hard coded action though. By that logic if I elect not to use the common action creator pattern (without thunk, i.e just standard action creators that return an action), does that make my React components action creators?
What if I put a 'createFoo' function in my component that creates a foo action, and call dispatch(this.createFoo()) from elsewhere in the component? Now what is the action creator? Is it the function, or is it the component? Because going by the terminology in the redux docs it'd be the function, and going by the terminology in the redux-thunk docs, it'd be the component.
That's the ambiguity I'm talking about. I'm sure Dan Abramov has a consistent logical model in his head for reasoning about this, but it hasn't been properly divulged to the community. I could find you at least 5 devs I've met IRL that think it's the function, 5 that think it's the component, and 5 that think it's both.
> So the benefit of using middleware like Redux Thunk or Redux Promise is that components aren’t aware of how action creators are implemented, and whether they care about Redux state, whether they are synchronous or asynchronous, and whether or not they call other action creators.
No, the mapDispatchToProps pattern is what provides this layer of abstraction. If a component calls 'this.props.doFoo', why does it care whether doFoo starts an asynchronous process by calling an overloaded 'dispatch' function that could mean one of two completely different things, or using the same thunk pattern with a less confusing name?
I'm not disagreeing with anything you're saying in this post. What I'm saying is that the choice of API for redux-thunk is ambiguous and confusing, not that the pattern itself is bad (in-fact I think it's very good).
> There's also precedent for overloading `dispatch` and "teaching" it to understand parameters other than plain action objects, such as promises.
There's precedent for murdering people too, it happens a hundred times a day across the country. Doesn't make it a good idea.
It's perhaps not as custom as I made it sound. The code we have is a wrapper around the [virtual-dom](https://github.com/Matt-Esch/virtual-dom) library which does most of the low level work.
The "widget" framework is a series of simple ES6 classes that allow us to keep state around and delegate events as actions up to Ember controllers. We had a lot of pre-existing, battle tested code that was written using Ember idioms and was not a performance problem, so we kept that around and used the virtual dom stuff just for rendering HTML as fast as possible.
Why not React? Our main pain point was rendering, and we didn't need all the extra stuff React provided as those bases were already covered by Ember. Why include 26k min+gzip when we would only use a small part of it that was already provided by another excellent virtual-dom library?
They both started this after the Witness came out, 10 years ago.
Since then, guess how many games Muratori has shipped? 0. (He cancelled his announced game.)
Guess how many Blow has shipped? 0 so far, but it sounds close now.
These engineers spent their time ragging on other developers for slinging bad code and doing things horribly, meanwhile those developers were shipping games and apps and all sorts of other stuff.