Відео

His explanation is not really good but I agree that in games unit tests are nonsense. You have to design your unit tests to cover all cases in the game. In games I don;t think its possible. You end up with two sets of cases - in game and unit test - which partially overlap, and your code needs to be designed in specific way (TDD) to facilitate tests, so you end up with superflous requirements.

I find it funny that if the problem is compilers are slow, the solution was to make a whole other slow language instead of unfucking the compiler.

i wonder about his opinion on C# (sorta interpreted then compiled) and Haxe (trans(?)-piles to C/C++ or whatever lang)

meanwhile bash and powershell hold up the world

I completely agree with Jon that scripting language can become bug prone and its slow. For my perspective the num of reasons to embed scripting language in the engine could be: - To be productive (i.e Do a hot reload within the engine running). - As Interface to only allow a set of functions in the engine.

Use c# native aot. It compiles to native code. Use that to create a "scripting" library that can be called by c++. .Net8 finally gets us to this place.

Theres a reason why you separate performance-critical simulation things and gameplay things. C++ has massive compilation times, especially for things like large games with tons of external libraries. You need to quickly iterate these things to get a functioning product quickly. Also languages generally aren't flat out interpreted, they're put into more efficient JIT bytecode first. C#, which *does* have debugging and type checking, I count as a scripting language that compiles to JIT bytecode. This whole take is confusing.

I enjoy Jon's opinions, but I've made several games that run fine in JavaScript with very few bugs 🤷‍♂

Ask Square Enix how relying on scripting for FF14 worked out for them. The story ultimately has a happy ending, but that's because they dumped a ton of money into totally rewriting the entire game to relaunch it while keeping the old one patched enough for ppl to play for 2 years.

Waiting 15 minutes for your game to build? Oh baby. I work in AAA game development. For some changes my end-to-end compile/build time is 4 hours. Fucking shoot me.

So basically its a skill issue on his part

"Scripting language interpreter is a compiler that doesn't compile" Jonathan Blow

Emacs would be so much better if it were simply a Common Lisp library and a standard implementation, e.g. SBCL. It would suddenly be - Fully compiled. - Easy to debug. - Fast.

I choose to define unit tests as any test which does not require external input or output, and no external dependencies. So they run very fast, and very reliably. Whether you are testing the lowest level or highest level functions is a separate argument. Personally I test both when ever I can, and test to the stated definition of the unit being tested. If this ends up with less than 100% coverage (outside of a few edge cases which are essentially impossible to reproduce if your program is functions ing correctly) then this implies that the implementation has coded for situations that it doesn’t need to, and so refactoring the unit is the appropriate response (usually).

makes sense

I was using lua on my engine. Not any more. Next PR will remove that HAHAHAHAH

Jonathan's bit at the end about ignoring costs is right on the money (pun intended). I often struggle trying to make that exact point at places I work.

The Emacs devs finally brought native code compilation to Emacs, and I am genuinely surprised it took so long because yes: Emacs Lisp is slow. Also yes, Emacs is not good at debugging its own code, which is incredibly ironic because Emacs+SLIME+SBCL (Common Lisp) is hands down the best environment I have ever used for any programming language. You get a compiled, statically checked language that feels like a scripting language to write, comes with a built in universal debugger, and provides the same compiler you use for your original compilation for your new code at runtime.

My rules of thumb for testing: 0. Spec out the feature, decompose it into sub-problems with solutions using some data structures and algos. 1. Write a stub API in the layer where it needs to be integrated. This is how you discover the API shape. 2. Write a few realistic test cases for the API. Does not need to be exhaustive. Its just a way to set more goals for your implementation than just the happy path. 3. Implement the API. 4. If you have to write a tricky algorithm or data structure, TDD it. It's a judgement call how much benefit you expect to get out of the tests. That's why you don't unit test trivial stuff.

Scripting languages are fine, for the reasons he states as the "why" at the beginning. Currently, the best reason for scripting languages is to allow community modding, but the original reasons are still valid because compile times can still be onerous. Most of the reasons he gives against scripting languages still apply to the game without the scripting language, and as always developer discipline is critical to achieving best performance.

Using the word "Test" in TDD is another one million dollars error. Call it "Specification", as it by the way is, and then you won't say any more "To write a specification before code is complete nonsens".

if you're going to be compiling to machine code to extend an application you may as well compile to a dynamically loaded library using a separately installed compiler but with headers included in the distribution. I do think luaJIT is a pretty good option if you want to have a simple 'scripting language' for extension but also 'compiled'

You don't need to write the guts of the test imo to still be following TDD, but you need to write the specs imo before the implementation and the specs should describe the underlying behaviors you expect, if you don't know what those are yet then figure that our first before you waste time typing nonsense on a keyboard.

Is he a big proponent of the Suckless software community?

this guy is so far up his own ass

This is a classic case of "I have a really big hammer so everything looks like a nail". He is extremely comfortable in his environment (compiled languages) so he only sees the down side of a scripting language and he doesn't see the benefits as being "real". The whole argument about "non-serious" programmers is absurd. Serious programmers use scripting languages all the time. This would be as absurd as saying only people who write raw assembly are serious programmers and people who write in compiled languages are not. You say scripting languages are slow, but again I could say compiled languages are slow and that only raw assembly is fast. You are just setting an arbitrary goalpost based on your personal experience. You say that you don't have a debugger or can't debug scripting languages and that is simply false. You say blueprints are OK even though all the arguments you try to make would indicate that you don't think blueprints are ok. Does everything belong in a scripting language, or course not. Just like everything you need to choose the right tool for the right job.

Scripting Languages are good for Game Modding in my opinion. For example Garry's Mod has scripting done PERFECTLY, it has made many people start and learn how to code. It is also easy to use and more fun. I somewhat agree that if a game is entirely made in a Scripting Language it is gonna be very slow but for modding it has a positive effect.

When I was a junior engineer learning TDD and doing pair programming helped me a lot to improve. Now I dont do tdd anymore but it was a good learning experience

This is why games are broken on release half the time.

I don't really think blueprint/unity's node scripting thing are good as scripting languages because blueprint exposes a ton of engine stuff by default that you can't turn off, and unity's thing exposes everything that's already exposed to C# Being able to know everything designer will interact with in advance is imo a pretty important part of scripting languages and those don't tick that checkmark

Also, funny that Blow talks about costs and wasteful development, given he writes 3D engines for games that can be made in Unity. Like WTF. Go invest $20m on a puzzle game and complain it's still not done. Hilarious. This guys has some good insights, but then he gives you some rather questionable arguments.

The problem with Blow is that he's used to small codebases (Braid, for example) that either make money or get abandoned. Real projects out there need tests because the project is going to be ongoing for a decade or longer. So you can't just write & write code until it crumbles and changing the code without regressions becomes difficult. But for that you need to work on real-world projects, not small games.

Jonathan surelly do not know what he want to program if unit test are problem to him. You should not start programming if you don't know what problem you want to resolve and because of that for sure you do not have alogorithm/pseudo code for this solution.

...The problem with Starfield.

I kinda disagree. A well-made scripting language can save you a lot of development time. Not every scripting language is tied to an interpreter or virtual machine, scripting languages can be compiled to machine code as well. The real problem I see is that scripting languages in almost general is the lack of a smarter object/class creation system, like an embedded object pooling or something like that, to prevent users from allocating stuff during runtime.

Scripting languages were a great way games in the 2000-2010s allowed people to create custom content, Gmod being a prime example. Clearly this is different from creating and shipping a game.

How can Jonathan Blow be such a pompous ass with every take he has?

In some situations (i've mostly encountered it with math & algorithm problems) the call signatures and tests are a no-brainer, and you can reliably write them before the meat of the program (and it makes perfect sense in that context). Could it be that TDD is a practice from college "algorithms and data structures" course that someone extrapolated to a whole field of programming?

TDD is an alright tool to have but shouldn't be treated as dogma. I think it works best with stuff that can be easily unit tested, with clear inputs and outputs. I think the stuff of writing the test before the code is not very valuable. What's important is that you test your shit.

that's crazy to me that Jon was working on sokoban 6 years ago.

I always didn't understand because TDD because it didn't make sense to write test first, then code, then something?

Say what you want about Blow in 2024.. the dude rocked the fuck outta that floral

andrew tate lookin ass

The way I see it, you're gonna need a DSL either way, so might as well make it a part of the engine. I mean, eventually, every serious game will need to represent some _ongoing process_ that some object is performing, which has to be _pausable at any moment_ and _persistable to a save file._ If you have a DSL that can do all that - that's already a scripting language.

Dogshit opinion.

It’s telling how he said “in my opinion” and not “in my experience”

What about a language that can be compiled AND interpreted and has an interpreter that can run scripts that can change the state of already compiled and running programs written in that language? So basically you'd get lots of iterations AND you'd be able to compile your scripts as object files if you want them as binaries (Yes I'm thinking of Lisp)

the Andrew Tate of programming

i like gdscript. it's like blueprints but better :P.

There's a lot of stuff Jon says is outright bad which is actually a trade-off. Scripting languages can be worthwhile to use depending on your experience and use-case, but they aren't very useful at all for someone like Jon for all the reasons he listed.