The primary issue here I think is that because of their low barrier to entry, people forget that scripting languages where designed specifically to implement the automation of well understood, but routinely occurring multi-step tasks; as opposed to building fairly large, non-trivial, carefully engineered and maintainable projects.
not really. It's just one of the big obvious downsides of scripting languages. if you step back for a second and say, give scripting languages to a bunch of profeccient long-time programmers, you get other issues. Many issues he brought up in this video, like debuggability, bug-prone interpretation, lack of strict type checking (this is literally a bug generator marketed as a feature). I understand the idea and benefit of accepting any type by default but its absolutely insane to not check for a function paramter type until runtime by default. Another is tool fragmentation, like compilers and build systems, limited feature support, weak interoperability between lower level languages, having to write bindings all the time, being dog slow. Scripting languages can just be a pain all around and ironically none of them having anything to do with being "interpreted". Java, C# and C++ all have interpreters, you don't see them having issues with performance or strict type checking. Arguably C# is a bit *too* strict with type checking
@@Mallchad No...the fundamental issues with scripting languages within the context of using them in use cases they aren't suited for is because they are interpreted and all that is associated with that. This is by simple definition.
@@thecollector6746 I don't understand what interpreters have to do with debuggers, strict typing, or anything else. x86 assembly instructions can be interpreted. What does that have to do with making good code? and how does that shape what the language can be good for?
@@Mallchad ..that's because you are rebutting an argument I never made. Scripting Languages were not designed for building non-trivial, scaled, performant applications. FULL STOP. This is a FACT. I didn't bother reading the rest past your open because why bother ?
Tldr use the right tool for your job. Don't use python to write a raytracing program and don't use c to write a web scraper you'll use once a week. Ffs this is common sense
I mean. I still like the idea of Lua as an interface for ameteur programmers to add recipes and stuff to the game like Factorio. Minecraft could've done with a lightweight interpreter/api for some simple entities and crafting systems.
@@someonesomewhere3817 Do you actually think JITing Lua for game content would be faster than an in game visual editor directly saving data as game assets? I think I'm being pretty clear about the suggestion, and it seems unfathomable that even C++ code could be faster than directly loading serialized data.
@@someonesomewhere3817 Well yeah it's way easier to throw in script hooks. There's a difference between "what's a cheap solution I can cobble together with freely available tools" and "what does a good solution to the problem look like". I prefer to focus on the second question.
@@someonesomewhere3817 I'm aware of Lua's simplicity, I've written game engines that use it as a scripting language. I'm not sure what you mean by needing to reserialize, serializing data should be incredibly fast. If you have enormous amounts of data then you're going to be breaking it into chunks anyways, so just save the edited chunks. There's no performance to be gained, loading and saving game assets is part of the game, if that's slow then you probably need to fix it. You'd almost always rather have a visual editor, you could use lua scripts to create a particle config or tilemap. But it'd be incredibly unproductive to specify a tilemap as text, it's better to have a visual editor where you can tweak stuff and serialize it. You keep using phrases like "more convenient". It is convenient for programmers because it's basically plug and play. But it's inconvenient to modders and designers that want to create content. It's obviously too much work to make a visual editor for everything, but to say it's somehow better to not any seems silly.
John is fascinating to listen to, but "it's a disaster, don't ever do it" feels narrow-minded. Interesting to hear another perspective, but ultimately I don't agree with him here. And how many of John Blow's games have mods of any kind? No one's managed to mod his games by hacking stuff onto his compiled code. He wants people to extend games by editing the compiled code? Fine, he should add a well defined modding interface or open-source his code. This entire video is devoid of any nuance. He compares unlike things as equivalent, like shipping a compiler vs shipping an embedded script engine. He suggests emacs would be better if you could configure it by editing the native code. But guess what? EMACS IS OPEN SOURCE AND YOU CAN ALREADY CONFIGURE IT BY EDITING THE C CODE AND RECOMPILING, AND NO ONE DOES. Has he seen the garbage C code for xwindows in the emacs source tree? Working with Elisp is way better. And he wholly ignores the problem of security, that any user can just hack stuff onto native code without creating security vulnerabilities. Want to extend a game? Just download a mod in the form of some random compiled C++ code from the internet, what could go wrong?. Scripting languages give you a sandboxed environment, at least to some extent. I could go on, but it seems John has some pretty strong opinions about scripting and is overly dismissive of the problems that scripting was created to solve.
Would you say these problems are intrinsic to compiled languages? Or could they theoretically be solved if all systems and components were written in language other than C++? Like Rust for instance?
@@sasuke2910 Some of the problems go away I guess, it's less likely that a user would introduce security vulnerabilities if an extension to a program was written in Rust for sure. But let's suppose that you download a natively-compiled extension from the internet, whether it's written in rust, or something else, there's always the risk that someone nefarious messed with the executable code after it was compiled. Extending an application by scripting, on the other hand, allows a program to run scripts in a, theoretically, hermetically sealed sandboxed environment, where scripts don't have access to memory, files on the computer, etc.. Furthermore, John Blow suggests that shipping a compiler with your application is comparable to shipping an embedded scripting language, which is not the case. Bundling rustc and llvm with a program is simply not the same as integrating Lua for example, a tiny 20,000 line extensively-tested scripting engine. Overall, I was just arguing that John Blow dismisses scripting languages without providing a viable alternative. Allowing people to extend applications using native code isn't a viable solution if you only distribute closed-source programs, as John Blow does. Rust is a great language, but still not something that ordinary users can use to extend software. While safer than C++, Rust is still a complex systems language. Maybe Rust will replace C++, but scripting will still be useful and necessary. But, now that basically all scripting languages compile to bytecode, the line between programming language and scripting language is extremely blurred. The performance issues aren't as severe as Blow suggests. Programming language vs scripting language isn't as meaningful a distinction as it was in 2005, when, according to Blow, people supposedly abandoned scripting languages (he doesn't cite data, of course), so I'm surprised that John makes such a big deal out of it. Providing only native code as a way to introduce extensions to a program assumes that it's perfectly fine to give user code access to an application's memory, but there are plenty of scenarios where, partly for security, you don't want to do this.
@@evanbowman4065 Well, if the OS was better sandboxed with applications not having access to the full disk, if applications could partition their memory space safely, and all applications shipped with header-file equivalents would all those problems not be solved? If your main issue that he doesn't provide a current alternative, then I guess that's legitimate complaint, but he and his team have been working on a new compiler and toolchain for about 6 years now. If you're limited on time/money and you only need your application to survive for 10 years, then making something with Lua makes a lot of sense. But this Jon is talking about the ideal design for the next generations of software.
@@sasuke2910 "Well, if the OS was better sandboxed with applications not having access to the full disk" Yeah, that could be done, but don't expect clueless end-users to actually do it. "if applications could partition their memory space safely" If you're loading foreign code into a process, e.g. with dlopen or similar, how do you propose to partion memory space to prevent access? You could run code as separate processes and communicate via shared memory, but then you need to create a protocol for communicating with the application, and this sounds not altogether different than building a api, and in the video John Blow dismisses api endpoints for an application (script apis in particular) tedious and error prone. He seems to want a monolithic unified codebase, which implies loading user code into a single process, unless I'm missing something? "If you're limited on time/money and you only need your application to survive for 10 years, then making something with Lua makes a lot of sense. But this Jon is talking about the ideal design for the next generations of software." 10 years is generous, most code doesn't even survive that long. But I see no reason why script extensions written in Lua or some other scripting language would survive less long than ones written in natively compiled languages. I've seen plenty of natively-compiled C executables that no longer run after OS upgrades, but ancient Java/C#/Lua/etc. programs still seem to run fine, as they're hosted on a VM. Would you care to explain why native code would survive past ten years while scripts would not?
@@evanbowman4065 "John Blow dismisses api endpoints for an application (script apis in particular)" I think the key distinction is a "native" endpoint, not a scripting one. Native in this case meaning whatever the host language/ABI is. "which implies loading user code into a single process, unless I'm missing something" I don't think so, right now OS's isolate memory using processes, so it makes sense to use them if you can't isolate dlls in another way. Although it's not very hard to imagine a feature to flag memory for access from dlls. "Would you care to explain why native code would survive past ten years while scripts would not?" It's not about being native to the OS architecture, it's about being native to your own system. The extreme added complexity in your runtime environment and tooling cause systems to rot more quickly. For example, systems that require multiple debuggers rot faster than systems that can make use of a single unified debugger. If your game is in Python (god forbid), extensions to it should come in the form of Python modules that interact with your existing api. If your game code is Lua dynamically loaded into the Unity C# CLR, that gets loaded from the Unity C++ framework. Then your whole toolchain and future is very shaky compared to unified projects where you just dump a million lines into rustc.
The value of scripting language is not its performance, but in community making the game content. I can provide some games where modding gave more to the game then devs themselves
There's no reason you can't make mods without scripting languages. Counter Strike is probably the most well known mod ever created, but it did *not* use a scripting language.
I still think that Blow's point that modding it with the same language that the game is built in solves many many problems. But I think you also have a solid point that a _community_ forms and grows much much better when it's even a little bit easier or more accessible. If the goal is quality community mods, excitement about modding is extremely beneficial, no matter how bad the actual experience of modding is. Most people (unlike Blow) get excited about the surface level and not the little details that matter in the long run.
If your own team members can't use the tools very well, how good a game can you possibly make? The point JB was making was simply that as a tool scripting language is always a worse choice compared to real programming language (for coders) or a custom made tool (for other members of dev team) like Blueprints. If your team has good tools, you can always provide those for modding.
It CAN mean that, but it doenst HAVE to mean that. You can compile to a dynamically linked library and reload it at runtime. This way you can write that C++ code in the editor and compile it, then bring it into the game as the game is running. If it fails to compile, for any reason, then you dont and the game keeps running without problem.
When working in Unreal Engine, I make such things a editable property (e.g. public UPROPERTY) so they can be edited in a editor. I don't see any reason why any game shouldn't be able to support such functionality.
If only people would let Jon get past the first parts of his discussion so we would be able to have someone as experienced as him discuss the more interesting part underneath this which is where do you draw the line between how much dynamic you let the data for you game become between how much you keep in gameplay code. If you make your data dynamic enough (let it define complex behavior) you could easily end up with having almost a badly implemented scripting language. But you still want a data oriented design and have things be dynamic through data. That is a balance act and I would love to have Jon discuss how he approaches that problem.
This is a trash take, it's undefensible... he makes generalizations that are total BS, talking about scripting languages as a whole, where there's scripting languages with type checking, for example... you can definitely have a full blown debugger, for example Python has a full debugger... etc. It is just an awful take.
@@davidgildegomezperez4364Python is also 100x-180x slower than C++ with the exact same code (simply due to its interpreter), so that'll instantly be your game's bottleneck
@@davidgildegomezperez4364 What are you even saying? Do you agree that an instruction takes cycles for the CPU to do? Take *LEA C,[A+B]* (c = a+b), which is an instruction that takes at worst 1 cycle to complete (uops dot info). Comparing that to 180 instructions that average out to 100 cycles, with cache misses etc. - do you agree that it's only logical for it to take longer? You can go measure and get the same result like I did, but my statement should be obvious and logical even without measuring. In C# it just turns into 1 LEA instruction. But in Python the same LEA turned into: mov qword ptr [r11+38h],r14 add r14,2 jmp _PyEval_EvalFrameDefault+5872h mov rdi,qword ptr [r12-8] lea rax,[__ImageBase] mov rsi,qword ptr [r12-10h] sub r12,8 mov rdx,rdi mov rcx,rsi call qword ptr [rax+r13*8+3E7A70h] mov qword ptr [rsp+8],rbx push rdi sub rsp,30h xor r8d,r8d mov rdi,rdx mov rbx,rcx call binary_op1 mov qword ptr [rsp+10h],rbp mov qword ptr [rsp+18h],rsi mov qword ptr [rsp+20h],rdi push r14 sub rsp,20h mov rsi,rdx movsxd r9,r8d mov rdx,qword ptr [rcx+8] mov rbp,rcx mov rdi,qword ptr [rdx+60h] test rdi,rdi je binary_op1+2Fh mov rdi,qword ptr [rdi+r9] mov rcx,qword ptr [rsi+8] mov qword ptr [rsp+30h],rbx cmp rcx,rdx je binary_op1+55h xor ebx,ebx lea r14,[_Py_NotImplementedStruct] test rdi,rdi je binary_op1+0ADh test rbx,rbx je binary_op1+90h mov rdx,rsi mov rcx,rbp call rdi mov rax,qword ptr [rcx+8] test dword ptr [rax+0A8h],1000000h je long_add+24h mov rax,qword ptr [rdx+8] test dword ptr [rax+0A8h],1000000h jne _PyLong_Add sub rsp,28h mov r8,rdx mov rdx,qword ptr [rcx+10h] lea rax,[rdx+1] cmp rax,3 jae _PyLong_Add+3Eh mov r9,qword ptr [r8+10h] lea rax,[r9+1] cmp rax,3 jae _PyLong_Add+3Eh mov ecx,dword ptr [rcx+18h] mov eax,dword ptr [r8+18h] imul rcx,rdx imul rax,r9 --> add *rcx,rax* add rsp,28h jmp _PyLong_FromSTwoDigits push rdi sub rsp,20h lea rax,[rcx+5] mov rdi,rcx cmp rax,105h ja _PyLong_FromSTwoDigits+2Fh lea rax,[rcx+3FFFFFFFh] cmp rax,7FFFFFFFh jae _PyLong_FromSTwoDigits+48h add rsp,20h pop rdi jmp _PyLong_FromMedium mov qword ptr [rsp+10h],rbx push rsi sub rsp,20h movsxd rsi,ecx mov edx,20h mov rcx,qword ptr [_PyObject] call qword ptr [_PyObject+8h] push rbx sub rsp,20h mov rbx,rdx call pymalloc_alloc sub rsp,28h lea rax,[rdx-1] cmp rax,1FFh jbe pymalloc_alloc+17h mov qword ptr [rsp+30h],rbx mov qword ptr [rsp+38h],rsi mov qword ptr [rsp+40h],rdi lea edi,[rdx-1] shr edi,4 mov qword ptr [rsp+20h],r14 lea r14,[__ImageBase] lea eax,[rdi+rdi] lea rsi,[rax*8+4C7120h] mov rdx,qword ptr [rsi+r14] mov rcx,qword ptr [rdx+10h] cmp rdx,rcx je pymalloc_alloc+9Fh mov r9,qword ptr [rdx+8] inc dword ptr [rdx] mov rax,qword ptr [r9] mov qword ptr [rdx+8],rax test rax,rax jne pymalloc_alloc+1C1h mov r14,qword ptr [rsp+20h] mov rax,r9 mov rdi,qword ptr [rsp+40h] mov rsi,qword ptr [rsp+38h] mov rbx,qword ptr [rsp+30h] add rsp,28h ret test rax,rax jne _PyObject_Malloc+46h add rsp,20h pop rbx ret
mov rbx,rax test rax,rax jne _PyLong_FromMedium+4Ah mov qword ptr [rsp+30h],rdi mov eax,esi cdq mov rcx,rsi sar rcx,3Fh mov edi,eax and rcx,0FFFFFFFFFFFFFFFEh lea rax,[PyLong_Type] xor edi,edx mov qword ptr [rbx+8],rax inc rcx sub edi,edx mov qword ptr [rbx+10h],rcx test dword ptr [PyLong_Type+0A8h],200h je _PyLong_FromMedium+88h cmp dword ptr [_Py_tracemalloc_config+4h],0 je _PyLong_FromMedium+99h mov dword ptr [rbx+18h],edi mov rax,rbx mov rdi,qword ptr [rsp+30h] mov qword ptr [rbx],1 mov rbx,qword ptr [rsp+38h] add rsp,20h pop rsi ret mov rcx,rax cmp rax,r14 jne binary_op1+0D9h mov rbx,qword ptr [rsp+30h] mov rbp,qword ptr [rsp+38h] mov rsi,qword ptr [rsp+40h] mov rdi,qword ptr [rsp+48h] add rsp,20h pop r14 ret mov rcx,rax lea rax,[_Py_NotImplementedStruct] cmp rcx,rax je PyNumber_Add+35h mov rax,rcx mov rbx,qword ptr [rsp+40h] add rsp,30h pop rdi ret sub qword ptr [rsi],1 mov r15,rax jne _PyEval_EvalFrameDefault+58AFh sub qword ptr [rdi],1 jne _PyEval_EvalFrameDefault+58C6h mov qword ptr [r12-8],r15 test r15,r15 mov r15,qword ptr [rsp+30h] je _PyEval_EvalFrameDefault+161h add r14,2 jmp _PyEval_EvalFrameDefault+59FCh
@@davidgildegomezperez4364*C#/C++:* lea *Python:* mov add jmp _PyEval_EvalFrameDefault mov lea mov sub mov mov call mov push sub xor mov mov call mov mov mov push sub mov movsxd mov mov mov test je mov mov mov cmp je xor lea _Py_NotImplementedStruct test je test je mov mov call mov test je mov test jne _PyLong_Add sub mov mov lea cmp jae _PyLong_Add mov lea cmp jae _PyLong_Add mov mov imul imul → add *rcx,rax* add jmp _PyLong_FromSTwoDigits push sub lea mov cmp ja _PyLong_FromSTwoDigits lea cmp jae _PyLong_FromSTwoDigits add pop jmp _PyLong_FromMedium mov push sub movsxd mov mov _PyObject call _PyObject push sub mov call sub lea cmp jbe mov mov mov lea shr mov lea lea lea mov mov cmp je mov inc mov mov test jne mov mov mov mov mov add ret test jne _PyObject_Malloc add pop ret
mov test jne _PyLong_FromMedium mov mov cdq mov sar mov and lea xor mov inc sub mov test je _PyLong_FromMedium cmp _Py_tracemalloc_config je _PyLong_FromMedium mov mov mov mov mov add pop ret mov cmp jne mov mov mov mov add pop ret mov lea _Py_NotImplementedStruct cmp je mov mov add pop ret sub mov jne _PyEval_EvalFrameDefault sub jne _PyEval_EvalFrameDefault mov test mov je _PyEval_EvalFrameDefault add jmp _PyEval_EvalFrameDefault
I think it's not so much a criticism on scripting language generally. This is more about scripting language in the context of game making. Basically it's a bad idea to use a different language for different teams to build the same program
It is near impossible to make a game using a single language tho. At least Cpu and Gpu (shaders and compute) will use different languages and if it is online or multiplayer the backend server program will often be different from the frontend.
@@esbensloth Yeah you're describing programming different services for a game. But even gl shader language forces you to enforce single responsibilities. Your code can get messy otherwise. For Lua scripting, it's basically a hook for existing gameplay code. The problem here is that you're using two languages to code the same mechanism at the same time, which can get messy. It's the same if you use GL and high order languages at the same time to draw the same shapes.
So I am not in the gaming industry, so when I think of scripting languages I probably think about it a bit differently than Jon. I use scripting languages when I am debugging problems that are larger than one specific corefile. When you have to gain quick insight from a lot of data (logs, counters, ...). When you need to pipe together some output from some small programs - that kind of stuff. For most other stuff I am really hesitant about using a dynamic / scripting language. I understand why people use them in build systems (since that problem looks like the same thing I mentioned before - connecting together the output of a few smaller programs) but to me it feels really scary how shaky everything is. If you need something to last long you should build it with robust parts. My small observability one liners only live until I understand/solve that specific issue. I only use a dynamic language because atleast it is saner than Bash, and in a perfect world these small programs would get replaced by some real piece of code that would provide real and more ergonomic observability of our system. (btw, I know it is an old clip and I have already commented here ages ago - but I like coming back to these clips and reviewing how I feel about them)
can you mention an example of when using a scriping language might be a bad idea? also "If you need something to last long you should build it with robust parts" can you explain more, i can see a lot of companies using Javascript/Typescript (scriping language) to create desktop apps and web apps, for example VS Code was made using Electron.JS and for me its been great to write programs in.
Scripting languages might be the single biggest reason for losing my sanity as a programmer. For the 10 years of me writing code primarily in scripting languages, I've tried solving the problem of good design without compromising things like performance, readability AND MODULARITY. I'm starting to think this is not possible with scripting languages. Maybe scripting languages would solve problems of compiled languages only if they had zero-cost abstractions, idk...
My own personal opinion(borne out of experience, but just an opinion nonetheless) I beleive the reason why Scripting Languages aren't particularly suited for non-trivial projects is that they simply were not designed for such tasks, but because of their low barrier of entry, they are often selected for every task imaginable, and then as time goes on, the same people who where told Python or JavaScript weren't suited for in the first place then go on to try to make Python and JavaScript into a poor man's Java, C#, C++, etc without gaining any self awareness whatsoever.
@@thecollector6746 yet there is something to be said for usability, user base and ecosystem health. The cutting edge of web dev is what it is for a reason.
@@BusinessWolf1 That's fair. I think we are at a place now where we can achieve both via compiled languages that provide the option of "scripti-ness" like Groovy Kotlin, Scala, Go, and Rust, and their quasi derivatives like Odin, and Zig.
I mean, Emacs Lisp has a full blown IDE, debugger and more built right into it. I don't think Blow is correct on the difficulty on debugging scripting languages.
Just do like terry, and make your own OS too... Or even better, your own computer and parts ... Your own tools, like the guy of that channel doing a iron knife from the mud, wood and jungle...
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'
Late to the game here but was Jon running some kind of end-to-end testing on his game here? Seems like wouldn't be something he'd be super thrilled about doing, but I can't tell what else could be doing.
I've been working in a mainstream game studio for 2 years now and we use lua for gameplay code. I was apprehensive at first but honestly it is very convenient. As with all scripting languages that I know of there IS a debugger, I don't know what John was talking about on that one. The dynamic type system does sometimes cause type-related bugs but honestly its just a lot more convenient. Things that would be a 100 lines in c++ are only a few lines in lua because of a lack of boilerplate. All the lua code hotreloads in 1 second making iteration times really quick. The thing that John said about having to write hooks to c++ and back is true but the bulk of that work is just done once and any future hooks can be added in seconds. We don't allow artists to write code, that is silly. We make editors that generate code for them. The only real issue is performance. We don't jit our lua, we interpret it in the most basic way. That being said the number of times things have had to be rewritten in c++ for adequate performance I can count on one hand. 98% of the time lua does the job, 1% of the time we export 1 or 2 functions to c++ to avoid frequent memory allocations and the other 1% is a full refactoring in c++. Something that John didn't mention is just how far you can take the flexibility of a dynamic language (I assume because he hasn't used one too much). Lua doesn't have a class system but we have made an in-house one that ia significantly more flexible than any class system in mainstream static languages. Classes frequently inherit more than 50 other classes and it works great. We have a system that automatically resolves complex inheritance of methods by calling them all and accumulating their result in some way. The UI and many other systems are all in lua and are easy to work with. There are many other nice things about lua that I can't fit inside a single youtube comment. TL;DR There are many things that I agree with John about but scripting languages is not one of them.
I don't think he'd disagree in the current landscape if you're trying to get stuff done fast, but you're suck thinking in current C++. There's nothing about compiled languages that mandate lots of boilerplate and very slow compile time with no hotloading. If C++ compiled and hotloaded in under 1sec would you still have that opinion? Also, I wouldn't insult Jon, by implying that he hasn't worked extensively with Lua and been writing interpreters for 30+ years.
"Classes frequently inherit more than 50 other classes and it works great. We have a system that automatically resolves complex inheritance of methods by calling them all and accumulating their result in some way." Oh my god that sounds like a nightmare to understand/debug. Reminds me of Tom + JDSL.
I was with him until he mentioned visual scripting. It's everything he complained about but worse. Blueprints in unreal on large projects turns into an absolute shitshow. It's just code except you can't search it, tracking it with version control is annoying, it's binary so it's unmergable (you can kind of do it visually but it's an absolute pain, and merging across diverging branches is literally impossible). The last game I shipped had networking code implemented in blueprints. The fact that any of that is the case absolutely blew my mind in the worst way possible. Oh, and it runs like absolute shit. The exact same naiive implementation in c++ runs literally 10 orders of magnitude faster in almost every case, but since it's a proper language there's all sorts of better tricks you can do, too.
ive heard the refrain often that with a scripting language you dont have a debugger and im confused what everyone means by that? you *can* write a debugger for a bytecode vm
You can, but Lua and many other systems don't ship with one because it kinda needs to be custom to properly interact with your own engine code. The time and complexity cost of building/maintaining/using a internal debugger and toolchain is almost certainly higher than building an "in-game editor" equivalent that serialized level data directly.
i think a scripting language has it's place in making a game extensible by giving the end user ability to add levels, missions, puzzles, etc. i wouldn't expect the end user to understand compilers and a complex language (not even one like lua) nor would i want to ship an entire compiler with the game. the scripting language should be something simple that hooks directly into the game by specific functionality.
I agree with this, but that's pretty much the only case in which a scripting language makes sense. Problem is that too often developers have used them with this notion that you could have "non programmers" doing scripting... as if scripting wasnt programming. It is, and like Jon says, you actually get more complexity, not less. Instead of one language, now you have two. Maintainability suffers. Debugging suffers. Optimization suffers. And you divide your programmers by language, so you segment your engineering effort and who can look at what code and who cant.
@@zeejenkins making a DLL requires the end user to understand compilers and a complex language. sure the user could use plugins, but that requires someone else to make the plugin.
@@dinobotpwnz Uh, depends on who? The world isn't about your idealistic views. Someone not knowing anything about programming should be able to make mods because that means potentially more content, potentially more enjoyment, potentially more profit for the company. Simple as that.
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 game I am writing uses a scripting language, in the form of WASI. It's only for user-generated content, the two issues for why I am using it is because: 1. It's really hard to properly sandbox native code, yes I know there's a billion ways to do so but they always sacrifice something. 2. Cross-platform is really hard, by using WASI I can let users bundle a sandboxed multiplatform module that other users can safely execute. I do honestly really hate the syntax and the garbage collectors of most scripting languages though, so even when I write modules I tend to do them in Rust haha.
15 second compile times are still too much for me (outside of games), who has instant (sub-second) turnaround time for changes I make in the code I work on.
You can get the same without a scripting language. Like, instead of a script you can have a separate C++ compilation unit that builds a DLL and then you can hot reload that
@@monomere Okay, but that part will be only a couple hundred lines of code and compile in a second or less. WIth better languages like Jai that will be much faster anyways
This. I work in lua mainly. I have a sub second recompile & run time. Lua part of the game is ~1.4 million lines of code over 5k files. I can sit all day without restarting the game. Just doing instant code changes. So does the other 20 gameplay devs over here. I have worked at other companies, and the turn around time working with C++ as gameplay code is just ludicrously slow. I always hear people saying "you can setup C/C++ to get super fast instant reload" But I have never seen it in larger code bases.
I dunno. Naughty Dog, Valve, Blizzard and many other studios seems to be doing pretty well with scripting languages. Most of their titles are purely written in some form of scripting language, whether it being Lisp (Naughty Dog), Squirrel (Valve), Statescript (Blizzard)... you name it. I think the points the Jon brings up are very valid. But some of the pitfalls he mentions, such as designers writing bad code, can be solved with teaching, communication, team management and documentation. Things you should have in any company, even if you don't use scripting languages for your games. Being able to iterate on design choices quickly is what can make a game better, because decisions can be made in less time. Regarding speed; sure it's not as quick as your inline assembly code which runs quicker than any compiler can fathom. But there are ways, using static analysis, to provide information about complexity and warn about it. Depending on your scripting language of choice, you can introduce linting and formatters which can help clean up your diffs for the team to review.
I once worked with multiple designers who had been briefed about code commit guidelines from the company. They usually write the initial code and commit it once and never touch, fix or refactor the code ever again. As long as it works, and looks the way they want it to, its good enough - which causes hassles down the line. Its not about them writing bad code, since they can fix that problem if they give it enough attention, its usually the attention they give it - the good old "if it works, it works"
@@dealloc maybe it is a management problem, but that's how policies prohibiting designers from touching code get implemented. Same as how security departments aren't allowed to touch or look at code. Well, in most of the companies in my country that is.
You have no idea what you're talking about. None of these titles are "purely" written in a scripting language, they all use a mix of compiled languages and a bit of scripting languages.
@@michaelzomsuv3631 There's a distinction between gameplay (99% of what you do in a game) and engine-most gameplay is written in a scripting language which uses underlying systems. Everything from AI, dialogue, missions, cut scenes, etc. can be executed effectively through scripting, whether it being high-level (i.e. node graphs) or not (code).
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.
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 kinda love working with LÖVE2D and LÖVR, but if the project gets big enough, refactoring does become a pain. Still, seems WoW used Lua in a pretty decent way for UI plug-ins, wonder what Jon's opinion is on that. Also, Warcraft 3 and Starcraft 2 have used Lua to script AI and such, if I am not mistaken. Again, seems to me a pretty decent approach, allowed easier level/scenario creation by 3rd parties it seems.
I'm an addon developer for wow (AuraBreak Notify and others) and I would have had a much easier time with static types But relaunching the game for every change? Reconnecting? Relogging, loading? Fuck that, Jonathan
While performance, accuracy and strictness are important aspects, he misses the fact that moddable games become WAY more popular than non moddable ones. Terraria, Minecraft, Warcraft 3, World of Warcraft (UI, mostly), Skyrim, etc. Massively popular *also* because they're moddable. Sometimes you just have different goals.
Consider that Counter Strike and Dota are both mods of games that do not have scripting systems, scripting is not a requirement for modding. Also, isn't Minecraft a counter example? Most Minecraft mods are implemented in Java, the same language as Minecraft, not a separate scripting language.
@@user-ti3od9qf5y > it’s written in java which you can easily decompile and modify it’s code. That wouldn't be a scripting language... "Scripting language" in this context means using a **different** language than what was originally used to create the game. "Scripting" does not mean "interpreted" or "non-C++".
@@user-ti3od9qf5y Maybe spend some time researching what these terms mean before trying to have a conversation about them. You really don't know even the basics of what you're talking about if you think The Witness and Braid didn't require a powerful machine to run when they were released.
@@sasuke2910could just use C++ and have the engine load libraries (.dll or .so) as and you have the benefit of high performance code and installable mods
It took me 2 secs to go from rust to C. Then as soon as i try to do smtg in lua its sooo painful because of unintuitive syntax, other abstractions etc. If i wanted a specialised language for specialised tasks then fine, script me. But for anyhting general C is sooo easy
Why not do the Id Software thing and do both? Id Software, for Quake III, used C as the scripting language! Thing is, Id Software implemented a compiler that outputs stack-based bytecode. Perhaps in this case, a regular C interpreter reading source code would be more beneficial.
Great idea, but while we're at it, why not precompile it? And why not C++? Same reason, the compiler and toolchain are heinously complicated. But this does seem like the general solution. We just need a nicer language that compiles faster, is less memory error prone, has a simpler toolchain, and strong metaprogramming facilities.
@@sasuke2910 that's not a bad idea, problem is that it makes modding more difficult. More complex the programming language, the more people you turn away. Why not C++? Because C++ is way more complex than C, especially when doing game logic, and its simplicity makes C alot easier to debug compared to C++. IMO, the perfect language would've been Golang but if only Golang didn't have trash ABI to where it's really slow to interface with C libraries. Toolchain for using a C interpreter isn't hard either. If I had my own game company + active game project, I'd most likely pick the latest Python or Lua for scripting since they're both very widespread. I'd lean towards Python since that's used alot more than Lua IMO.
There is one use for scripting languages, writing scripts, as in dialogue or story. While you can use ini or other formats it is more convenient to write branching dialogue with a more code like syntax, that said you don’t need a full language. Logical storage format I suppose.
That's more a task for a DSL (domain specific language). Which is comparable to the visual scripting he talks about in the video: they're limited so there's less room to do stupid things and less complexity that may degrade performance.
If you use javascript these days though, granted your rendering isn't heavy, you can deploy to pretty much everything very easy using an embedded browser. With that said, for 3D games, heavy rendering, and consoles that's no good.
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 disagree with jon here. If done well and you have a solid and fast API, scripting languages can be monumentally helpful in developing your game even if it's a standalone game with a bare bones engine. It allows for extremely fast iteration, it abstracts away game logic from the engine which is crucial for debugging and code maintenance and it allows you to actually focus on the GAME development rather that messy c++ engine code
There's nothing wrong with initially developnig your game using a scripting language. As long as there's that final step of saying "now that the logic has been prototyped, we will convert it back to a language that isn't slow and hackish".
I really disagree with a lot of what he says - it's hard not to be inflammatory toward him. Even when he makes a good point, it's buried in so much bull, it's ultimately pointless. Edit: OK, after a Socratic discussion with a friend, I've come to the conclusion that my reaction might be too strong - he's basically dissing on something that I've spent a lot of time developing, so it hits a little too hard.
I think the most useful thing about scripting languages is to store some value that need to be changed frequently, and sometimes you need a data markup language like XML or JSON, but you want them to have some programming ability like simply generating a table, which is quite convenient. People think scripting language is bad, it's because some people decide to use it to do complicate things as Jonathan Blow mentions.
Emacs is 100% Lisp, any customization will have to be done in Lisp... For a C programmer that must be very painful :) IMO his development style would probably be served best by vanilla vim, tbh.
@@berkano_plays pedantic correction: Emacs itself is almost entirely C, including a lisp interpreter. It's still customized and extended using lisp however, similar to the games jon's comparing it to.
He is extremely biased here, since he has not worked in a big game studio... Generally, there are gameplay programmers that work on the scripting, and engine programmers that work on the C++ codebase. Yes, it's a lot more work for the engine programmers to support the script language, but it pays off during the gameplay testing and codding. You can generally hire people with lower language understanding, or even give the script to the designers. It's hard to find competent C++ programmers for everything. It's good idea to not mix the languages, since scripting requires completely different approach then wring in C++. Yes, there is extra work, but the engine lifecycle is much bigger then the game lifecycle. So the investment pays off. It's far from a "failed paradigm". But there is a right way to do it, and many wrong ways. It's like saying - JavaScript failed, which is absurd. It's something very handy, but yes, it can also get very messy if you are doing it wrong.
whats a scripting language? like python, bash/ powershell, lua, lisp, gdscript; what else? is mojo, julia, kotlin, zig, octave a scripting lang? why not? just 'cz of type checking?
It's not black and white. It's a combination of features, and every language makes different choices on the tradeoffs. You could say a scripting language is really just anything people happen to use to write scripts rather than applications. But then there isn't a hard line between a script and an application.
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.
The utter disregard for the end user is absurd. I can't just send them my code if my engine is encumbered by third-party middleware like so many engines are.
Late to the party, but this is tricky. Having the engine built on a different language introduces a lot of complexity for both the Unity team and for us. The Unity team has to make sure every new feature plays nice with the C++ editor/player, while also making sure nothing breaks or bugs out on the C# side. We, on the other hand, have to deal with the technical quirks that comes with that interop, from writing lots of boiler plate to compensate for stuff like poor encapsulation (thanks to serialization), a lack of constructors (since the engine has to create our objects), and to jumping through hoops to make sure we don't over or under use the main thread (since the update loops is single threaded on the C++ side). On the other hand, C# is a powerful full on industry language, and since C# can be JIT compiled, we don't have to compile the entire engine or editor every time we modify our game logic, and with the IL2CPP compiler, it all compiles down to C++ in the final build when we do so C# performance isn't a concern. So its a give and take with Unity.
lol, i came here after watching a whole gdc talk by naughty dog on the combat system of the original the last of us game, which, news flash, was built completely using scripting, written by designers, not programmers
@@ducksoop.x He’s no boomer, which is easy to find if you bothered. Besides, just because X does something, doesn’t make it the wisest choice. Just because X doesn’t do it doesn’t have anything different: they both have tradeoffs, and the question is, what tradeoffs are you willing and able to make? Context matters.
Or, the thinking goes "We'll give them a scripting interface so they can customize it to suit their tastes" except they never do know what it is they want and they want YOU to customize it, not them. So it ends up making more work for you that's mostly not needed.
normally i think jblow mostly talks nonsense but this snippet is so true and makes me miserable day in day out, scripting is such a pandoras box that has caused nothing but trouble on projects i've been on.
hard disagree on the visual scripting take though, i'll let it go cause it was relatively new when this clip was made but visual scripting has become as bloated and load bearing as ye olde scripts were, is just as annoying to debug and has exactly the same problems as scripting languages do.
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.
In my opinion, this demonstrates his passion and concern for the future of game programming. Taking a more holistic perspective, it also reflects his worry about the broader software ecosystem. These factors contribute to his evident frustration.
First of all, scripting languages are used so game developers don't have to go through the pain of writing their entire game in C++ (which is already a messy complex language to work with). It also lessens development time, and the performance really depends on how you implement the code so that it doesn't get affected by things like garbage collection. It's also possible to write an entire game in C++, but have completely bad performance because of bad coding style. Second of all, how do you define a "real programming language"? I define a programming language as one that solves problems and expresses a solution in which a computer system can understand and execute. If your definition of a "real" programming language is interfacing with the computer hardware, then the only "real" programming language is Assembly. Assembly is the only language where it allows users to completely interact with machine instructions, complete manipulation of memory, etc. Compiled languages such as C and C++ only generate machine code, but you never actually interface, nor completely control the code actually generated by the C/C++ compiler. EDIT: Also, just a history lesson, C++ wasn't always the "lingua franca" of video gaming. Back then, Assembly and C (though in many engines, C was mainly used for scripting while the entire engine was made in Assembly) were pretty much the dominant languages of video gaming until games got more complex and hardware got more advanced, then C++ started becoming dominant, especially around 2005. After that, C++ became hard to work with because of its complexity, thus game development took longer. That's why scripting languages are used in the first place, to ease development time.
The assumption here is that the only alternative is to write their entire game in C++ when that patently isn't true. Java, C#, and D(Remedy Games are among the very few outfits that have used D in their games) are all compiled, strongly typed languages that are demonstrably and significantly fasters than scripting languages and prehaps more importantly...THEY SCALE
With the way C# is structured we really shouldn't be calling it a scripting language. I only ever heard it being called scripting back in college when we were taught server-side scripting in C# with ASP. NET. and my professors called C# files as scripts, but I think that's from the legacy of programming anything server-side being called "scripting".
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.
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.
This is very reassuring for a newbie trying to make a simple game in lua, lol thanks John :/ not everyone is a computer genius, us dummies need scripting languages
I think he's mostly talking about hybrid systems. Where your system has 2+ different languages. If you build entirely in Lua then you don't face a lot of the complexity he's mentioning.
Lua has the same complexity as C with slightly fewer pointer-related footguns. It's neither easier no harder than C, they are nearly the same language in terms of functionality, except Lua is more limited and weird in the way it achieves low-level programming One of the problems with Lua in learning is it doesn't make you think about types ahead of time, which feels easy but gives you a lot of headache with typing issues that are stupid easy to solve in languages that force you to type your variables. (hint, put assert(type(arg) == number)) or whatever your type is everywhere
Embedding a scripting language is very Unixy but a terrible idea if you have to cross the programmer / artist barrier. Don't make programmers do art and don't make artists write code. It's just not the way they're wired. Bad results inevitably ensue. "The Art of Unix Programming" is by programmers, for programmers. Visual scripting is good for artists and gameplay programmers. You can have issues with performance. I'd treat it as a prototyping tool.
I see a lot of C# comments, probably because Unity uses it. But how often is Unity used for triple A games? UE4 is much more prevalent in AAA and only provides (hot reloadable) C++ and Blueprint. I think the whole flow of creating the engine in C++ and hooking up Mono is only done because computers have gotten very fast and we can get away with unoptimized solutions.
Not sure why everything is measured in terms of how many "A"s they have. Plenty of games, created by independent studios, have been made (written in C# either XNA or Unity) that feels like AAA. AAA titles is not a good measurement for how good an engine is, nor even how good those games and studios are.
Unreal is super annoying to learn for me due to blueprints and the elitist community. I learned Unity super easily because of the amazing documentation and the plentiful tutorials that still mostly work. Unreal I find it hard to find good tutorials in c++ because most are in blueprints (why even use unreal if you are using blueprints?) and the documentation is laughable compared to Unity's.
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.
For gameplay I couldn't imagine using a scripting language, but for cutscenes, a scripting language is much better than using some tool provided by an engine for making cutscenes, you can go way way faster.
Welcome to 3 hour long Unreal Engine 4.26 game builds outputting 300GB of binary data. And assets are all binary because why should someone actually want to edit assets outside of a fullblown GUI game editor with thousands of buttons 😂
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
I have a friend who plays a wargame called "Dominions 5" and writes extensive mods using their scripting language, it's quite impressive and people seem to be happy with it. Personally if I had to build a (2d) game with a non-programmer and that this person needed to be able to add content, I'd give them the possibility to add stuff using json or something like that but it would be really constrained. Making a GUI tool would better their own "DX" but the constraints would be the same... It's not scripting per say because I could very well compile everything once we ship a beta/production build and keep it as "scripts" only for the dev build... Just talking outta my ass, tho.
www.quora.com/Why-do-game-companies-all-use-C++-rather-than-say-Lua-or-Java-Are-they-shifting-away-from-C++ Seems like we are all scrubs. This would explain however why I'm running into performance issues coding in C#. Basically scripting laguages have automated garbage collectors. You cant control the gc so you get unpredictable performance spikes. While in C++ there is no gc - so no unpredictable behaviour. But you have to take control of the lifetime of your object in memory yourself. It seems you only can code in c# when using unity. Sooo i'll stay with c# for a while i guess.
@Scholar of the first sin I promise you that there is nothing fundamentally different between a Python "interpreter" and a Java or C# "virtual machine". You are just wrong trying to see C# as a compiled language.
@@nandoflorestan the plain ignorance of not explaining yourself is showing. @scholar please don't listen to this fool. Here is a better way of explaining it cs.stackexchange.com/questions/23951/are-java-and-c-also-purely-interpreted-languages
I've been coding for half my life and I don't even know what makes a language a scripting language, I just assume the ones with script on the end are scripting languages
It is not about programming language it's about how it's used, for example Javascript is used to manipulate browser objects so it's used as a scripting language in that context, VBA is used to manipulate Word, Excell, AutoCad and so on, so VBA is used a scripting language. Most of early implementation of programming languages that wear designed to be used for scripting like Javascript are built as an interpreters but recent versions are usually generate machine code, but due to semantics of Javascript it may be harder to produce machine instructions, for example function add(a, b) { return a + b; } may operate on strings, numbers, dates so compiler may need to add checks to ensure that compiled block operates with correct types.
@@VolcanicPenguin Haha, you know what? I was gonna say something about the fact that you've been coding half your life and you don't know that. But, it's refreshing to see programmers who don't pretend like they know everything. Anyways, I guess the main difference is, compiled code is turned into machine code whereas scripted code is fed into a sort of virtual machine that performs all the instructions. That's a very brief overview but I definitely recommend you read about it, it's an interesting topic.
@@noahfletcher3019 That can be a problematic distinction because even interpreted languages often have preprocessing, compilation to bytecode etc. going on in the background to improve performance. How I understand it "scripting language" means it's used as a secondary language for configuration or extensions for some software that doesn't require recompiling the whole thing. I think it makes sense in many situations, but Jonathan Blow is also correct in that properly implementing a scripting language in an engine may not be worth the trouble.
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.
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 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.
The point is, you could do the same and just not use the scripting language, just use the real language, like how gmod was made. It's an HL2 mod, but wasn't made with scripting, same with Portal and Counter-Strike.
@@sasuke2910 yes but scripting adds ease of use. Source engine takes AGES to compile and it would mean that you will have to remake a game for modding... but Lua here saves the day.
@@alphenex8974 Compiling being slow is a fixable problem. I'm not sure what you mean by needing to "remake a game", you can use the same api that any Lua system uses.
@@sasuke2910 Yes, stuff can escape from sandbox environments, but can't a c/c++ DLL have malicious stuff implemented easily? Putting that responsibility on the players and not providing a safer way of modding feels treachery to your players imo.
@@yokunjon It might be slightly easier, but any sufficiently advanced mod system will be able to exploit or crash the host game in some way. Sandboxing helps, but doesn't require you use two different languages. You can sandbox C++, C#, or whatever your main language is.
I think, main benefit of scripting languages that they allows players make mods to the games. Mods often improve base game experience (see Paradox Games, Warcraft 3, Skyrim or Dwarf Fortress for examples). With scripting languages is it even possible for players to fix bugs themselves (for example, there is a bugfix mods for Dragon Age Origins that fix combat, AI and/or quests). If you ask players to use write a DLL in some serious programming language to make mod, that would not happen.
I despise the idea of using a language the engine is not built in to make the game. Indie devs (usually) do not have experience in code architecture and maintenance, they dont realize how much maintenance goes into bindings, upgrades, etc. You are essentially managing 3 things: language A, language B and translation between the two. That involves context, threading, exposing of interfaces. If you make a engine in C++, bite the bullet and learn how to add hot-reloadability. Scripting languages are not easier, more performant or simpler than exposing hot-reloadable files using the same language as the engine. I also seen a lot of indie programmers adding Lua because they think learning a 2nd language is easier than just cleaning up their engine's interface and making it simpe to use. 😔
Do you propose that we we also write programs in the language the the OS we use is written in? The point about scripting languages not being easier, isn't true. This is why they exist in the first place, whether you like them or not. They make it easy for beginners to get started programming something without having to learn each and every compiler and linker and their billions of build systems.
@@dealloc I dont get your point. What is the purpose of a scripting language? If you already know C, why would you take your C engine and add Lua to it when you could just create an easier interface with the C you already have? What is the point of adding Lua? I dont know any programmer out there in the wild that only knows Lua for instance, so what is the point? The only option is that people have to learn Lua to use the scripting. Makes no sense, just learn the language of the engine and you can do both scripts and engine code. We're not talking scripting for modders that's irrelevant. Scripts as in scripts for the developers, so "beginners" are a non issue
@@Terszel Most people, who are serious about their engine/game, add scripting languages to make simple logic quicker to iterate on for designers. If you were to build your game by yourself or with people who _know_ the language, a scripting language would just be a bottle neck. But you can't expect every game designer to know your flavor of C and build system and to keep up to date with how you change your APIs. Providing a stable API through a scripting language can help mitigate this.
@@dealloc it really isnt a challenge to learn build systems, thats part of onboarding which is standard and brings me back to my earlier point that devs shouldnt integrate scripting languages because their engine seems too complex for designers to use, if it is then the engine needs more work and you can have a visual layer rather than forcing useless languages down designers throats
@@Terszel Complexity is relative. There are no one true build system in C/C++..Each project and maintainer has their own flavor of API and build system, because there are no constraints in these languages. I disagree that a scripting language is the result of a badly designed engine. Modern engines are more complex than your average indie developer's home-made engine and are very well designed. I agree that visual scripting can work to some extent. But there are limitations where it breaks down. The more complex your logic gets, the harder it is for anyone to scan and follow the flow. This is already a problem with a lot of state machine-based animation tools for complex animations. Designers should definitely learn to use the tools they work with, but teaching them C, because that is your favorite language, is not going to fly for most and will not be a cheap hire.
i disagree.. you don't use scripting language to code your gameplay or whatever. you need to use scripting languages to create content. core mechanics can remain in the core, be it C++ or any other language. the content is really entity scripts, world events, interactions, and all things that won't be executed constantly, most likely just once
@@reinhold1616 If you aren't indenting code normally in C based languages, you're probably the issue. While I'm not a huge fan of whitespace significant syntax, my current stance is caring about it is bikeshedding
Scripting languages make possible for some of the game logic to reside outside the compiled binaries. Which is critical for mods. Any game which must have robust mod support would always need to give some way to the mod makers to create game logic, conditionals and scripts to use in mods. So, yeah not gonna agree to Mr.Blow's hypotheses there at all.
How is that different from compiled languages? Dynamic libraries exist, not all of your code has to reside in the main executable, mods can ship dynlibs just fine. As a matter of fact, if you are shipping the compiler with the main game modders can also ship text files so the game could compile them during loading.
At least two quite major differences. 1) Security, scripting environments are easily sandboxable 2) if you ship dynlibs you'd have to be able to cross-compile them for every platform the game runs on
@@digitalspecter Youre already compiling the game for all the platforms it runs on so if youre shipping dynlibs, it would simply be another target for the build system. One wouldnt need to ship an x86 dynlib on an ARM platform I wouldnt think.
Problem is they used the easiest scripting languages. Kinda shows that some game developer coders aren't that great software programming or at least the ones making tool choices or more correctly more human than we think. If they used lisp it would be better but then you'd need real coders to understand lisp so it doesn't make it much easier at first. Emacs is the exception. Agree it needs an upgrade. Lisp is not that bad but can see why it's not popular with game developers. But it depends on how it's architect. Multiple exe example
One of the reasons Lisp would be good in this context is precisely that you DON'T need "real coders" due to Lisp's malleability. Honestly, I'm not sure why Lisp (and I mean Common Lisp) isn't popular among game developers, but garbage collection is probably one reason.
Also, CL is very pragmatic, easy to learn (as in; get results), facilitates refactoring well due to its simple syntax and semantics, and infinitely extensible due to the programmable reader and macros (functions processing code as data). Just because the language is so ingenious that people can write code that is difficult to understand even if you are an intermediate lisper, doesn't mean the language itself is difficult to learn and do useful stuff in. I probably would've never grokked programming if it weren't for Lisp, which I accidentally stumbled upon in a bookstore, and bought the book without having a clue about this unknown hipster language. It just looked interesting. Now, many years later, I'm writing a game engine in C, and I owe it all to Lisp.
The primary issue here I think is that because of their low barrier to entry, people forget that scripting languages where designed specifically to implement the automation of well understood, but routinely occurring multi-step tasks; as opposed to building fairly large, non-trivial, carefully engineered and maintainable projects.
That is why we don't build large maintainable projects. Certainly not well engineered ones.
not really. It's just one of the big obvious downsides of scripting languages.
if you step back for a second and say, give scripting languages to a bunch of profeccient long-time programmers, you get other issues.
Many issues he brought up in this video, like debuggability, bug-prone interpretation, lack of strict type checking (this is literally a bug generator marketed as a feature).
I understand the idea and benefit of accepting any type by default but its absolutely insane to not check for a function paramter type until runtime by default. Another is tool fragmentation, like compilers and build systems, limited feature support, weak interoperability between lower level languages, having to write bindings all the time, being dog slow.
Scripting languages can just be a pain all around and ironically none of them having anything to do with being "interpreted". Java, C# and C++ all have interpreters, you don't see them having issues with performance or strict type checking. Arguably C# is a bit *too* strict with type checking
@@Mallchad No...the fundamental issues with scripting languages within the context of using them in use cases they aren't suited for is because they are interpreted and all that is associated with that. This is by simple definition.
@@thecollector6746
I don't understand what interpreters have to do with debuggers, strict typing, or anything else.
x86 assembly instructions can be interpreted. What does that have to do with making good code? and how does that shape what the language can be good for?
@@Mallchad ..that's because you are rebutting an argument I never made. Scripting Languages were not designed for building non-trivial, scaled, performant applications. FULL STOP. This is a FACT. I didn't bother reading the rest past your open because why bother ?
Tldr use the right tool for your job. Don't use python to write a raytracing program and don't use c to write a web scraper you'll use once a week. Ffs this is common sense
Sure it's common sense, but programmers will argue about anything, especially when it comes to defending their hammer of choice.
I think you completely missed the point of this rant. Scripting language "is" the right tool, but it sucks anyway.
No one should ever use Python...
@@RadovanPalik what an obtuse statement with no reason to back it up.
Just to prove you wrong, I'm going to write a raytracing program in javascript.
Jon Blow lives in the future.
he can rewind and forward his life like in his game Braid
Perpetually*
I mean. I still like the idea of Lua as an interface for ameteur programmers to add recipes and stuff to the game like Factorio. Minecraft could've done with a lightweight interpreter/api for some simple entities and crafting systems.
Do you think Lua is better than a visual programming interface for recipe creation?
@@sasuke2910 Yes.
@@someonesomewhere3817 Do you actually think JITing Lua for game content would be faster than an in game visual editor directly saving data as game assets?
I think I'm being pretty clear about the suggestion, and it seems unfathomable that even C++ code could be faster than directly loading serialized data.
@@someonesomewhere3817 Well yeah it's way easier to throw in script hooks. There's a difference between "what's a cheap solution I can cobble together with freely available tools" and "what does a good solution to the problem look like". I prefer to focus on the second question.
@@someonesomewhere3817 I'm aware of Lua's simplicity, I've written game engines that use it as a scripting language.
I'm not sure what you mean by needing to reserialize, serializing data should be incredibly fast. If you have enormous amounts of data then you're going to be breaking it into chunks anyways, so just save the edited chunks. There's no performance to be gained, loading and saving game assets is part of the game, if that's slow then you probably need to fix it.
You'd almost always rather have a visual editor, you could use lua scripts to create a particle config or tilemap. But it'd be incredibly unproductive to specify a tilemap as text, it's better to have a visual editor where you can tweak stuff and serialize it.
You keep using phrases like "more convenient". It is convenient for programmers because it's basically plug and play. But it's inconvenient to modders and designers that want to create content. It's obviously too much work to make a visual editor for everything, but to say it's somehow better to not any seems silly.
John is fascinating to listen to, but "it's a disaster, don't ever do it" feels narrow-minded. Interesting to hear another perspective, but ultimately I don't agree with him here. And how many of John Blow's games have mods of any kind? No one's managed to mod his games by hacking stuff onto his compiled code. He wants people to extend games by editing the compiled code? Fine, he should add a well defined modding interface or open-source his code. This entire video is devoid of any nuance. He compares unlike things as equivalent, like shipping a compiler vs shipping an embedded script engine. He suggests emacs would be better if you could configure it by editing the native code. But guess what? EMACS IS OPEN SOURCE AND YOU CAN ALREADY CONFIGURE IT BY EDITING THE C CODE AND RECOMPILING, AND NO ONE DOES. Has he seen the garbage C code for xwindows in the emacs source tree? Working with Elisp is way better. And he wholly ignores the problem of security, that any user can just hack stuff onto native code without creating security vulnerabilities. Want to extend a game? Just download a mod in the form of some random compiled C++ code from the internet, what could go wrong?. Scripting languages give you a sandboxed environment, at least to some extent. I could go on, but it seems John has some pretty strong opinions about scripting and is overly dismissive of the problems that scripting was created to solve.
Would you say these problems are intrinsic to compiled languages? Or could they theoretically be solved if all systems and components were written in language other than C++? Like Rust for instance?
@@sasuke2910 Some of the problems go away I guess, it's less likely that a user would introduce security vulnerabilities if an extension to a program was written in Rust for sure. But let's suppose that you download a natively-compiled extension from the internet, whether it's written in rust, or something else, there's always the risk that someone nefarious messed with the executable code after it was compiled. Extending an application by scripting, on the other hand, allows a program to run scripts in a, theoretically, hermetically sealed sandboxed environment, where scripts don't have access to memory, files on the computer, etc.. Furthermore, John Blow suggests that shipping a compiler with your application is comparable to shipping an embedded scripting language, which is not the case. Bundling rustc and llvm with a program is simply not the same as integrating Lua for example, a tiny 20,000 line extensively-tested scripting engine.
Overall, I was just arguing that John Blow dismisses scripting languages without providing a viable alternative. Allowing people to extend applications using native code isn't a viable solution if you only distribute closed-source programs, as John Blow does. Rust is a great language, but still not something that ordinary users can use to extend software. While safer than C++, Rust is still a complex systems language. Maybe Rust will replace C++, but scripting will still be useful and necessary.
But, now that basically all scripting languages compile to bytecode, the line between programming language and scripting language is extremely blurred. The performance issues aren't as severe as Blow suggests. Programming language vs scripting language isn't as meaningful a distinction as it was in 2005, when, according to Blow, people supposedly abandoned scripting languages (he doesn't cite data, of course), so I'm surprised that John makes such a big deal out of it. Providing only native code as a way to introduce extensions to a program assumes that it's perfectly fine to give user code access to an application's memory, but there are plenty of scenarios where, partly for security, you don't want to do this.
@@evanbowman4065 Well, if the OS was better sandboxed with applications not having access to the full disk, if applications could partition their memory space safely, and all applications shipped with header-file equivalents would all those problems not be solved?
If your main issue that he doesn't provide a current alternative, then I guess that's legitimate complaint, but he and his team have been working on a new compiler and toolchain for about 6 years now.
If you're limited on time/money and you only need your application to survive for 10 years, then making something with Lua makes a lot of sense. But this Jon is talking about the ideal design for the next generations of software.
@@sasuke2910 "Well, if the OS was better sandboxed with applications not having access to the full disk"
Yeah, that could be done, but don't expect clueless end-users to actually do it.
"if applications could partition their memory space safely"
If you're loading foreign code into a process, e.g. with dlopen or similar, how do you propose to partion memory space to prevent access? You could run code as separate processes and communicate via shared memory, but then you need to create a protocol for communicating with the application, and this sounds not altogether different than building a api, and in the video John Blow dismisses api endpoints for an application (script apis in particular) tedious and error prone. He seems to want a monolithic unified codebase, which implies loading user code into a single process, unless I'm missing something?
"If you're limited on time/money and you only need your application to survive for 10 years, then making something with Lua makes a lot of sense. But this Jon is talking about the ideal design for the next generations of software."
10 years is generous, most code doesn't even survive that long. But I see no reason why script extensions written in Lua or some other scripting language would survive less long than ones written in natively compiled languages. I've seen plenty of natively-compiled C executables that no longer run after OS upgrades, but ancient Java/C#/Lua/etc. programs still seem to run fine, as they're hosted on a VM. Would you care to explain why native code would survive past ten years while scripts would not?
@@evanbowman4065
"John Blow dismisses api endpoints for an application (script apis in particular)"
I think the key distinction is a "native" endpoint, not a scripting one. Native in this case meaning whatever the host language/ABI is.
"which implies loading user code into a single process, unless I'm missing something"
I don't think so, right now OS's isolate memory using processes, so it makes sense to use them if you can't isolate dlls in another way. Although it's not very hard to imagine a feature to flag memory for access from dlls.
"Would you care to explain why native code would survive past ten years while scripts would not?"
It's not about being native to the OS architecture, it's about being native to your own system. The extreme added complexity in your runtime environment and tooling cause systems to rot more quickly. For example, systems that require multiple debuggers rot faster than systems that can make use of a single unified debugger.
If your game is in Python (god forbid), extensions to it should come in the form of Python modules that interact with your existing api. If your game code is Lua dynamically loaded into the Unity C# CLR, that gets loaded from the Unity C++ framework. Then your whole toolchain and future is very shaky compared to unified projects where you just dump a million lines into rustc.
The value of scripting language is not its performance, but in community making the game content. I can provide some games where modding gave more to the game then devs themselves
There's no reason you can't make mods without scripting languages. Counter Strike is probably the most well known mod ever created, but it did *not* use a scripting language.
@@sasuke2910 He's probably not talking about the possibility of making mods, but the ease of a modding community being formed around the game
I still think that Blow's point that modding it with the same language that the game is built in solves many many problems.
But I think you also have a solid point that a _community_ forms and grows much much better when it's even a little bit easier or more accessible. If the goal is quality community mods, excitement about modding is extremely beneficial, no matter how bad the actual experience of modding is. Most people (unlike Blow) get excited about the surface level and not the little details that matter in the long run.
If your own team members can't use the tools very well, how good a game can you possibly make? The point JB was making was simply that as a tool scripting language is always a worse choice compared to real programming language (for coders) or a custom made tool (for other members of dev team) like Blueprints. If your team has good tools, you can always provide those for modding.
@@sasuke2910 sure, you CAN, but the barrier to entry is much higher than just edit text file and rerun game
0:06 2020? Jo Blow living in the future?
I am living in the future (hello)
if so, jon could've fucking told us about the thing
@@slash213That would've been spoilers!
A problem with compiling is it often means rebooting the game/editor and reloading your map, which can make tweaking gameplay numbers a chore.
You can store static variables in a config file and implement a way to hot reload them
@@damonpalovaara4211
You can hot reload only the bits you want in several languages. Lisp and Java being perhaps the most famous ones for it.
It CAN mean that, but it doenst HAVE to mean that. You can compile to a dynamically linked library and reload it at runtime. This way you can write that C++ code in the editor and compile it, then bring it into the game as the game is running. If it fails to compile, for any reason, then you dont and the game keeps running without problem.
When working in Unreal Engine, I make such things a editable property (e.g. public UPROPERTY) so they can be edited in a editor. I don't see any reason why any game shouldn't be able to support such functionality.
You can hot reload C++ if you know what you're doing
If only people would let Jon get past the first parts of his discussion so we would be able to have someone as experienced as him discuss the more interesting part underneath this which is where do you draw the line between how much dynamic you let the data for you game become between how much you keep in gameplay code. If you make your data dynamic enough (let it define complex behavior) you could easily end up with having almost a badly implemented scripting language. But you still want a data oriented design and have things be dynamic through data. That is a balance act and I would love to have Jon discuss how he approaches that problem.
This is a trash take, it's undefensible... he makes generalizations that are total BS, talking about scripting languages as a whole, where there's scripting languages with type checking, for example... you can definitely have a full blown debugger, for example Python has a full debugger... etc. It is just an awful take.
@@davidgildegomezperez4364Python is also 100x-180x slower than C++ with the exact same code (simply due to its interpreter), so that'll instantly be your game's bottleneck
@@Muskar2 not necessarily, there are many people programming games in interpreted or bytecoded languages (C# in Unity, for example)
@@davidgildegomezperez4364 What are you even saying? Do you agree that an instruction takes cycles for the CPU to do?
Take *LEA C,[A+B]* (c = a+b), which is an instruction that takes at worst 1 cycle to complete (uops dot info). Comparing that to 180 instructions that average out to 100 cycles, with cache misses etc. - do you agree that it's only logical for it to take longer? You can go measure and get the same result like I did, but my statement should be obvious and logical even without measuring.
In C# it just turns into 1 LEA instruction. But in Python the same LEA turned into:
mov qword ptr [r11+38h],r14
add r14,2
jmp _PyEval_EvalFrameDefault+5872h
mov rdi,qword ptr [r12-8]
lea rax,[__ImageBase]
mov rsi,qword ptr [r12-10h]
sub r12,8
mov rdx,rdi
mov rcx,rsi
call qword ptr [rax+r13*8+3E7A70h]
mov qword ptr [rsp+8],rbx
push rdi
sub rsp,30h
xor r8d,r8d
mov rdi,rdx
mov rbx,rcx
call binary_op1
mov qword ptr [rsp+10h],rbp
mov qword ptr [rsp+18h],rsi
mov qword ptr [rsp+20h],rdi
push r14
sub rsp,20h
mov rsi,rdx
movsxd r9,r8d
mov rdx,qword ptr [rcx+8]
mov rbp,rcx
mov rdi,qword ptr [rdx+60h]
test rdi,rdi
je binary_op1+2Fh
mov rdi,qword ptr [rdi+r9]
mov rcx,qword ptr [rsi+8]
mov qword ptr [rsp+30h],rbx
cmp rcx,rdx
je binary_op1+55h
xor ebx,ebx
lea r14,[_Py_NotImplementedStruct]
test rdi,rdi
je binary_op1+0ADh
test rbx,rbx
je binary_op1+90h
mov rdx,rsi
mov rcx,rbp
call rdi
mov rax,qword ptr [rcx+8]
test dword ptr [rax+0A8h],1000000h
je long_add+24h
mov rax,qword ptr [rdx+8]
test dword ptr [rax+0A8h],1000000h
jne _PyLong_Add
sub rsp,28h
mov r8,rdx
mov rdx,qword ptr [rcx+10h]
lea rax,[rdx+1]
cmp rax,3
jae _PyLong_Add+3Eh
mov r9,qword ptr [r8+10h]
lea rax,[r9+1]
cmp rax,3
jae _PyLong_Add+3Eh
mov ecx,dword ptr [rcx+18h]
mov eax,dword ptr [r8+18h]
imul rcx,rdx
imul rax,r9
--> add *rcx,rax*
add rsp,28h
jmp _PyLong_FromSTwoDigits
push rdi
sub rsp,20h
lea rax,[rcx+5]
mov rdi,rcx
cmp rax,105h
ja _PyLong_FromSTwoDigits+2Fh
lea rax,[rcx+3FFFFFFFh]
cmp rax,7FFFFFFFh
jae _PyLong_FromSTwoDigits+48h
add rsp,20h
pop rdi
jmp _PyLong_FromMedium
mov qword ptr [rsp+10h],rbx
push rsi
sub rsp,20h
movsxd rsi,ecx
mov edx,20h
mov rcx,qword ptr [_PyObject]
call qword ptr [_PyObject+8h]
push rbx
sub rsp,20h
mov rbx,rdx
call pymalloc_alloc
sub rsp,28h
lea rax,[rdx-1]
cmp rax,1FFh
jbe pymalloc_alloc+17h
mov qword ptr [rsp+30h],rbx
mov qword ptr [rsp+38h],rsi
mov qword ptr [rsp+40h],rdi
lea edi,[rdx-1]
shr edi,4
mov qword ptr [rsp+20h],r14
lea r14,[__ImageBase]
lea eax,[rdi+rdi]
lea rsi,[rax*8+4C7120h]
mov rdx,qword ptr [rsi+r14]
mov rcx,qword ptr [rdx+10h]
cmp rdx,rcx
je pymalloc_alloc+9Fh
mov r9,qword ptr [rdx+8]
inc dword ptr [rdx]
mov rax,qword ptr [r9]
mov qword ptr [rdx+8],rax
test rax,rax
jne pymalloc_alloc+1C1h
mov r14,qword ptr [rsp+20h]
mov rax,r9
mov rdi,qword ptr [rsp+40h]
mov rsi,qword ptr [rsp+38h]
mov rbx,qword ptr [rsp+30h]
add rsp,28h
ret
test rax,rax
jne _PyObject_Malloc+46h
add rsp,20h
pop rbx
ret
mov rbx,rax
test rax,rax
jne _PyLong_FromMedium+4Ah
mov qword ptr [rsp+30h],rdi
mov eax,esi
cdq
mov rcx,rsi
sar rcx,3Fh
mov edi,eax
and rcx,0FFFFFFFFFFFFFFFEh
lea rax,[PyLong_Type]
xor edi,edx
mov qword ptr [rbx+8],rax
inc rcx
sub edi,edx
mov qword ptr [rbx+10h],rcx
test dword ptr [PyLong_Type+0A8h],200h
je _PyLong_FromMedium+88h
cmp dword ptr [_Py_tracemalloc_config+4h],0
je _PyLong_FromMedium+99h
mov dword ptr [rbx+18h],edi
mov rax,rbx
mov rdi,qword ptr [rsp+30h]
mov qword ptr [rbx],1
mov rbx,qword ptr [rsp+38h]
add rsp,20h
pop rsi
ret
mov rcx,rax
cmp rax,r14
jne binary_op1+0D9h
mov rbx,qword ptr [rsp+30h]
mov rbp,qword ptr [rsp+38h]
mov rsi,qword ptr [rsp+40h]
mov rdi,qword ptr [rsp+48h]
add rsp,20h
pop r14
ret
mov rcx,rax
lea rax,[_Py_NotImplementedStruct]
cmp rcx,rax
je PyNumber_Add+35h
mov rax,rcx
mov rbx,qword ptr [rsp+40h]
add rsp,30h
pop rdi
ret
sub qword ptr [rsi],1
mov r15,rax
jne _PyEval_EvalFrameDefault+58AFh
sub qword ptr [rdi],1
jne _PyEval_EvalFrameDefault+58C6h
mov qword ptr [r12-8],r15
test r15,r15
mov r15,qword ptr [rsp+30h]
je _PyEval_EvalFrameDefault+161h
add r14,2
jmp _PyEval_EvalFrameDefault+59FCh
@@davidgildegomezperez4364*C#/C++:*
lea
*Python:*
mov
add
jmp _PyEval_EvalFrameDefault
mov
lea
mov
sub
mov
mov
call
mov
push
sub
xor
mov
mov
call
mov
mov
mov
push
sub
mov
movsxd
mov
mov
mov
test
je
mov
mov
mov
cmp
je
xor
lea _Py_NotImplementedStruct
test
je
test
je
mov
mov
call
mov
test
je
mov
test
jne _PyLong_Add
sub
mov
mov
lea
cmp
jae _PyLong_Add
mov
lea
cmp
jae _PyLong_Add
mov
mov
imul
imul
→ add *rcx,rax*
add
jmp _PyLong_FromSTwoDigits
push
sub
lea
mov
cmp
ja _PyLong_FromSTwoDigits
lea
cmp
jae _PyLong_FromSTwoDigits
add
pop
jmp _PyLong_FromMedium
mov
push
sub
movsxd
mov
mov _PyObject
call _PyObject
push
sub
mov
call
sub
lea
cmp
jbe
mov
mov
mov
lea
shr
mov
lea
lea
lea
mov
mov
cmp
je
mov
inc
mov
mov
test
jne
mov
mov
mov
mov
mov
add
ret
test
jne _PyObject_Malloc
add
pop
ret
mov
test
jne _PyLong_FromMedium
mov
mov
cdq
mov
sar
mov
and
lea
xor
mov
inc
sub
mov
test
je _PyLong_FromMedium
cmp _Py_tracemalloc_config
je _PyLong_FromMedium
mov
mov
mov
mov
mov
add
pop
ret
mov
cmp
jne
mov
mov
mov
mov
add
pop
ret
mov
lea _Py_NotImplementedStruct
cmp
je
mov
mov
add
pop
ret
sub
mov
jne _PyEval_EvalFrameDefault
sub
jne _PyEval_EvalFrameDefault
mov
test
mov
je _PyEval_EvalFrameDefault
add
jmp _PyEval_EvalFrameDefault
I think it's not so much a criticism on scripting language generally. This is more about scripting language in the context of game making. Basically it's a bad idea to use a different language for different teams to build the same program
It is near impossible to make a game using a single language tho. At least Cpu and Gpu (shaders and compute) will use different languages and if it is online or multiplayer the backend server program will often be different from the frontend.
@@esbensloth Yeah you're describing programming different services for a game. But even gl shader language forces you to enforce single responsibilities. Your code can get messy otherwise. For Lua scripting, it's basically a hook for existing gameplay code. The problem here is that you're using two languages to code the same mechanism at the same time, which can get messy. It's the same if you use GL and high order languages at the same time to draw the same shapes.
So I am not in the gaming industry, so when I think of scripting languages I probably think about it a bit differently than Jon. I use scripting languages when I am debugging problems that are larger than one specific corefile. When you have to gain quick insight from a lot of data (logs, counters, ...). When you need to pipe together some output from some small programs - that kind of stuff. For most other stuff I am really hesitant about using a dynamic / scripting language. I understand why people use them in build systems (since that problem looks like the same thing I mentioned before - connecting together the output of a few smaller programs) but to me it feels really scary how shaky everything is. If you need something to last long you should build it with robust parts. My small observability one liners only live until I understand/solve that specific issue. I only use a dynamic language because atleast it is saner than Bash, and in a perfect world these small programs would get replaced by some real piece of code that would provide real and more ergonomic observability of our system.
(btw, I know it is an old clip and I have already commented here ages ago - but I like coming back to these clips and reviewing how I feel about them)
can you mention an example of when using a scriping language might be a bad idea? also "If you need something to last long you should build it with robust parts" can you explain more, i can see a lot of companies using Javascript/Typescript (scriping language) to create desktop apps and web apps, for example VS Code was made using Electron.JS and for me its been great to write programs in.
Scripting languages might be the single biggest reason for losing my sanity as a programmer. For the 10 years of me writing code primarily in scripting languages, I've tried solving the problem of good design without compromising things like performance, readability AND MODULARITY. I'm starting to think this is not possible with scripting languages. Maybe scripting languages would solve problems of compiled languages only if they had zero-cost abstractions, idk...
My own personal opinion(borne out of experience, but just an opinion nonetheless) I beleive the reason why Scripting Languages aren't particularly suited for non-trivial projects is that they simply were not designed for such tasks, but because of their low barrier of entry, they are often selected for every task imaginable, and then as time goes on, the same people who where told Python or JavaScript weren't suited for in the first place then go on to try to make Python and JavaScript into a poor man's Java, C#, C++, etc without gaining any self awareness whatsoever.
@@thecollector6746 yet there is something to be said for usability, user base and ecosystem health. The cutting edge of web dev is what it is for a reason.
@@BusinessWolf1 That's fair. I think we are at a place now where we can achieve both via compiled languages that provide the option of "scripti-ness" like Groovy Kotlin, Scala, Go, and Rust, and their quasi derivatives like Odin, and Zig.
I mean, Emacs Lisp has a full blown IDE, debugger and more built right into it. I don't think Blow is correct on the difficulty on debugging scripting languages.
The integration tests running in the background 👁️👄👁️
I feeling like to making my own compiler after watching this. LOL
Just do like terry, and make your own OS too...
Or even better, your own computer and parts ... Your own tools, like the guy of that channel doing a iron knife from the mud, wood and jungle...
I hear C compiler is easy to make. Why not give it a try?
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'
Late to the game here but was Jon running some kind of end-to-end testing on his game here? Seems like wouldn't be something he'd be super thrilled about doing, but I can't tell what else could be doing.
Integration tests != Unit tests
@@sasuke2910 Ah fair enough. I thought maybe that his spite towards testing was universal. Fun to know he's fond of those in particular.
@@sasuke2910 He's not against unit tests either. He's just against strict TDD
I've been working in a mainstream game studio for 2 years now and we use lua for gameplay code. I was apprehensive at first but honestly it is very convenient.
As with all scripting languages that I know of there IS a debugger, I don't know what John was talking about on that one.
The dynamic type system does sometimes cause type-related bugs but honestly its just a lot more convenient. Things that would be a 100 lines in c++ are only a few lines in lua because of a lack of boilerplate.
All the lua code hotreloads in 1 second making iteration times really quick.
The thing that John said about having to write hooks to c++ and back is true but the bulk of that work is just done once and any future hooks can be added in seconds.
We don't allow artists to write code, that is silly. We make editors that generate code for them.
The only real issue is performance. We don't jit our lua, we interpret it in the most basic way. That being said the number of times things have had to be rewritten in c++ for adequate performance I can count on one hand. 98% of the time lua does the job, 1% of the time we export 1 or 2 functions to c++ to avoid frequent memory allocations and the other 1% is a full refactoring in c++.
Something that John didn't mention is just how far you can take the flexibility of a dynamic language (I assume because he hasn't used one too much). Lua doesn't have a class system but we have made an in-house one that ia significantly more flexible than any class system in mainstream static languages. Classes frequently inherit more than 50 other classes and it works great. We have a system that automatically resolves complex inheritance of methods by calling them all and accumulating their result in some way.
The UI and many other systems are all in lua and are easy to work with.
There are many other nice things about lua that I can't fit inside a single youtube comment.
TL;DR There are many things that I agree with John about but scripting languages is not one of them.
Python codding time is like 1/10 of c++ codding. Python debuggers are better than c++ ones.
I don't think he'd disagree in the current landscape if you're trying to get stuff done fast, but you're suck thinking in current C++. There's nothing about compiled languages that mandate lots of boilerplate and very slow compile time with no hotloading. If C++ compiled and hotloaded in under 1sec would you still have that opinion?
Also, I wouldn't insult Jon, by implying that he hasn't worked extensively with Lua and been writing interpreters for 30+ years.
"Classes frequently inherit more than 50 other classes and it works great. We have a system that automatically resolves complex inheritance of methods by calling them all and accumulating their result in some way."
Oh my god that sounds like a nightmare to understand/debug. Reminds me of Tom + JDSL.
I was with him until he mentioned visual scripting. It's everything he complained about but worse. Blueprints in unreal on large projects turns into an absolute shitshow. It's just code except you can't search it, tracking it with version control is annoying, it's binary so it's unmergable (you can kind of do it visually but it's an absolute pain, and merging across diverging branches is literally impossible). The last game I shipped had networking code implemented in blueprints. The fact that any of that is the case absolutely blew my mind in the worst way possible. Oh, and it runs like absolute shit. The exact same naiive implementation in c++ runs literally 10 orders of magnitude faster in almost every case, but since it's a proper language there's all sorts of better tricks you can do, too.
ive heard the refrain often that with a scripting language you dont have a debugger and im confused what everyone means by that? you *can* write a debugger for a bytecode vm
You can, but Lua and many other systems don't ship with one because it kinda needs to be custom to properly interact with your own engine code. The time and complexity cost of building/maintaining/using a internal debugger and toolchain is almost certainly higher than building an "in-game editor" equivalent that serialized level data directly.
i think a scripting language has it's place in making a game extensible by giving the end user ability to add levels, missions, puzzles, etc. i wouldn't expect the end user to understand compilers and a complex language (not even one like lua) nor would i want to ship an entire compiler with the game. the scripting language should be something simple that hooks directly into the game by specific functionality.
I agree with this, but that's pretty much the only case in which a scripting language makes sense. Problem is that too often developers have used them with this notion that you could have "non programmers" doing scripting... as if scripting wasnt programming. It is, and like Jon says, you actually get more complexity, not less. Instead of one language, now you have two. Maintainability suffers. Debugging suffers. Optimization suffers. And you divide your programmers by language, so you segment your engineering effort and who can look at what code and who cant.
A user who can't figure out how to download a compiler shouldn't be modding a game to begin with.
Dlls do exist?
Edit: To clarify, you could probably implement a moding system that can load a user DLL.
@@zeejenkins making a DLL requires the end user to understand compilers and a complex language.
sure the user could use plugins, but that requires someone else to make the plugin.
@@dinobotpwnz Uh, depends on who? The world isn't about your idealistic views. Someone not knowing anything about programming should be able to make mods because that means potentially more content, potentially more enjoyment, potentially more profit for the company. Simple as that.
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)
You are thinking of Mun.
The game I am writing uses a scripting language, in the form of WASI.
It's only for user-generated content, the two issues for why I am using it is because:
1. It's really hard to properly sandbox native code, yes I know there's a billion ways to do so but they always sacrifice something.
2. Cross-platform is really hard, by using WASI I can let users bundle a sandboxed multiplatform module that other users can safely execute.
I do honestly really hate the syntax and the garbage collectors of most scripting languages though, so even when I write modules I tend to do them in Rust haha.
15 second compile times are still too much for me (outside of games), who has instant (sub-second) turnaround time for changes I make in the code I work on.
You can get the same without a scripting language. Like, instead of a script you can have a separate C++ compilation unit that builds a DLL and then you can hot reload that
@@kim15742 you still have to compile that
@@monomere Okay, but that part will be only a couple hundred lines of code and compile in a second or less. WIth better languages like Jai that will be much faster anyways
This. I work in lua mainly. I have a sub second recompile & run time. Lua part of the game is ~1.4 million lines of code over 5k files. I can sit all day without restarting the game. Just doing instant code changes. So does the other 20 gameplay devs over here.
I have worked at other companies, and the turn around time working with C++ as gameplay code is just ludicrously slow. I always hear people saying "you can setup C/C++ to get super fast instant reload" But I have never seen it in larger code bases.
So you want the Java solution with a smart compiler that only recompiles the things that needs to be recompiled?
I dunno. Naughty Dog, Valve, Blizzard and many other studios seems to be doing pretty well with scripting languages. Most of their titles are purely written in some form of scripting language, whether it being Lisp (Naughty Dog), Squirrel (Valve), Statescript (Blizzard)... you name it.
I think the points the Jon brings up are very valid. But some of the pitfalls he mentions, such as designers writing bad code, can be solved with teaching, communication, team management and documentation. Things you should have in any company, even if you don't use scripting languages for your games. Being able to iterate on design choices quickly is what can make a game better, because decisions can be made in less time.
Regarding speed; sure it's not as quick as your inline assembly code which runs quicker than any compiler can fathom. But there are ways, using static analysis, to provide information about complexity and warn about it. Depending on your scripting language of choice, you can introduce linting and formatters which can help clean up your diffs for the team to review.
I once worked with multiple designers who had been briefed about code commit guidelines from the company. They usually write the initial code and commit it once and never touch, fix or refactor the code ever again. As long as it works, and looks the way they want it to, its good enough - which causes hassles down the line. Its not about them writing bad code, since they can fix that problem if they give it enough attention, its usually the attention they give it - the good old "if it works, it works"
@@araa5184 thats a management problem in the company. This doesn't only apply to code.
@@dealloc maybe it is a management problem, but that's how policies prohibiting designers from touching code get implemented. Same as how security departments aren't allowed to touch or look at code. Well, in most of the companies in my country that is.
You have no idea what you're talking about. None of these titles are "purely" written in a scripting language, they all use a mix of compiled languages and a bit of scripting languages.
@@michaelzomsuv3631 There's a distinction between gameplay (99% of what you do in a game) and engine-most gameplay is written in a scripting language which uses underlying systems. Everything from AI, dialogue, missions, cut scenes, etc. can be executed effectively through scripting, whether it being high-level (i.e. node graphs) or not (code).
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.
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 kinda love working with LÖVE2D and LÖVR, but if the project gets big enough, refactoring does become a pain. Still, seems WoW used Lua in a pretty decent way for UI plug-ins, wonder what Jon's opinion is on that. Also, Warcraft 3 and Starcraft 2 have used Lua to script AI and such, if I am not mistaken. Again, seems to me a pretty decent approach, allowed easier level/scenario creation by 3rd parties it seems.
I'm an addon developer for wow (AuraBreak Notify and others) and I would have had a much easier time with static types
But relaunching the game for every change? Reconnecting? Relogging, loading? Fuck that, Jonathan
C# is a scripting language for Unity
While performance, accuracy and strictness are important aspects, he misses the fact that moddable games become WAY more popular than non moddable ones.
Terraria, Minecraft, Warcraft 3, World of Warcraft (UI, mostly), Skyrim, etc. Massively popular *also* because they're moddable.
Sometimes you just have different goals.
Consider that Counter Strike and Dota are both mods of games that do not have scripting systems, scripting is not a requirement for modding.
Also, isn't Minecraft a counter example? Most Minecraft mods are implemented in Java, the same language as Minecraft, not a separate scripting language.
@@user-ti3od9qf5y > it’s written in java which you can easily decompile and modify it’s code.
That wouldn't be a scripting language... "Scripting language" in this context means using a **different** language than what was originally used to create the game.
"Scripting" does not mean "interpreted" or "non-C++".
@@user-ti3od9qf5y Maybe spend some time researching what these terms mean before trying to have a conversation about them.
You really don't know even the basics of what you're talking about if you think The Witness and Braid didn't require a powerful machine to run when they were released.
You don't need scripting languages for things to be moddable.
@@sasuke2910could just use C++ and have the engine load libraries (.dll or .so) as and you have the benefit of high performance code and installable mods
It took me 2 secs to go from rust to C. Then as soon as i try to do smtg in lua its sooo painful because of unintuitive syntax, other abstractions etc. If i wanted a specialised language for specialised tasks then fine, script me. But for anyhting general C is sooo easy
Why not do the Id Software thing and do both? Id Software, for Quake III, used C as the scripting language! Thing is, Id Software implemented a compiler that outputs stack-based bytecode. Perhaps in this case, a regular C interpreter reading source code would be more beneficial.
Great idea, but while we're at it, why not precompile it? And why not C++? Same reason, the compiler and toolchain are heinously complicated. But this does seem like the general solution. We just need a nicer language that compiles faster, is less memory error prone, has a simpler toolchain, and strong metaprogramming facilities.
@@sasuke2910 that's not a bad idea, problem is that it makes modding more difficult. More complex the programming language, the more people you turn away.
Why not C++? Because C++ is way more complex than C, especially when doing game logic, and its simplicity makes C alot easier to debug compared to C++.
IMO, the perfect language would've been Golang but if only Golang didn't have trash ABI to where it's really slow to interface with C libraries.
Toolchain for using a C interpreter isn't hard either. If I had my own game company + active game project, I'd most likely pick the latest Python or Lua for scripting since they're both very widespread. I'd lean towards Python since that's used alot more than Lua IMO.
There is one use for scripting languages, writing scripts, as in dialogue or story. While you can use ini or other formats it is more convenient to write branching dialogue with a more code like syntax, that said you don’t need a full language. Logical storage format I suppose.
Your right. That is what I did for my dialogue tool for Unreal.
This isn't programming, this is data entry. We really should start seperating the two
That's more a task for a DSL (domain specific language). Which is comparable to the visual scripting he talks about in the video: they're limited so there's less room to do stupid things and less complexity that may degrade performance.
If you use javascript these days though, granted your rendering isn't heavy, you can deploy to pretty much everything very easy using an embedded browser. With that said, for 3D games, heavy rendering, and consoles that's no good.
Blow would be interesting in a debate, but he's too one-sided to do interesting monologues.
"...too one sided...", I think that's what it means to have an opinion on something. 😂
meanwhile bash and powershell hold up the world
🤔 can a workflow engine be considered as a sort of scripting language interpreter?
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 disagree with jon here. If done well and you have a solid and fast API, scripting languages can be monumentally helpful in developing your game even if it's a standalone game with a bare bones engine. It allows for extremely fast iteration, it abstracts away game logic from the engine which is crucial for debugging and code maintenance and it allows you to actually focus on the GAME development rather that messy c++ engine code
Its so convenient to have scripting languages along with engine.
There's nothing wrong with initially developnig your game using a scripting language. As long as there's that final step of saying "now that the logic has been prototyped, we will convert it back to a language that isn't slow and hackish".
@@dinobotpwnz if you are willing to go through all that trouble for an extra 10fps, kodus to you.
I really disagree with a lot of what he says - it's hard not to be inflammatory toward him. Even when he makes a good point, it's buried in so much bull, it's ultimately pointless.
Edit: OK, after a Socratic discussion with a friend, I've come to the conclusion that my reaction might be too strong - he's basically dissing on something that I've spent a lot of time developing, so it hits a little too hard.
I think the most useful thing about scripting languages is to store some value that need to be changed frequently, and sometimes you need a data markup language like XML or JSON, but you want them to have some programming ability like simply generating a table, which is quite convenient. People think scripting language is bad, it's because some people decide to use it to do complicate things as Jonathan Blow mentions.
what does emacs 4:50 has to do with all this?
Emacs is 100% Lisp, any customization will have to be done in Lisp... For a C programmer that must be very painful :) IMO his development style would probably be served best by vanilla vim, tbh.
@@berkano_plays I thought Blow hated editors that don't have a sufficient "W" per minute...
@@berkano_plays pedantic correction: Emacs itself is almost entirely C, including a lisp interpreter. It's still customized and extended using lisp however, similar to the games jon's comparing it to.
What abour code injection? I mean you compile your objects and then the engine load this obj and inject it into the "gameplay zone code"
Malware.
@@profande Nop is not malware is game loading
He is extremely biased here, since he has not worked in a big game studio... Generally, there are gameplay programmers that work on the scripting, and engine programmers that work on the C++ codebase. Yes, it's a lot more work for the engine programmers to support the script language, but it pays off during the gameplay testing and codding. You can generally hire people with lower language understanding, or even give the script to the designers. It's hard to find competent C++ programmers for everything. It's good idea to not mix the languages, since scripting requires completely different approach then wring in C++. Yes, there is extra work, but the engine lifecycle is much bigger then the game lifecycle. So the investment pays off. It's far from a "failed paradigm". But there is a right way to do it, and many wrong ways. It's like saying - JavaScript failed, which is absurd. It's something very handy, but yes, it can also get very messy if you are doing it wrong.
whats a scripting language? like python, bash/ powershell, lua, lisp, gdscript; what else?
is mojo, julia, kotlin, zig, octave a scripting lang?
why not? just 'cz of type checking?
I imagine he means anything that's not ahead-of-time compiled?..
It's not black and white. It's a combination of features, and every language makes different choices on the tradeoffs. You could say a scripting language is really just anything people happen to use to write scripts rather than applications. But then there isn't a hard line between a script and an application.
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.
What engine is he talking about at the beginning?
Godot I'm pretty sure.
@@sasuke2910 I mean, the scripting language is optional, just recommended.
The utter disregard for the end user is absurd. I can't just send them my code if my engine is encumbered by third-party middleware like so many engines are.
Where does C# with Unity and Godot fit in ?
Things would be a lot simpler if Unity was written in C# and Godot in Python/GDScript. Hybrid systems introduce many complexities.
Late to the party, but this is tricky. Having the engine built on a different language introduces a lot of complexity for both the Unity team and for us. The Unity team has to make sure every new feature plays nice with the C++ editor/player, while also making sure nothing breaks or bugs out on the C# side. We, on the other hand, have to deal with the technical quirks that comes with that interop, from writing lots of boiler plate to compensate for stuff like poor encapsulation (thanks to serialization), a lack of constructors (since the engine has to create our objects), and to jumping through hoops to make sure we don't over or under use the main thread (since the update loops is single threaded on the C++ side).
On the other hand, C# is a powerful full on industry language, and since C# can be JIT compiled, we don't have to compile the entire engine or editor every time we modify our game logic, and with the IL2CPP compiler, it all compiles down to C++ in the final build when we do so C# performance isn't a concern.
So its a give and take with Unity.
lol, i came here after watching a whole gdc talk by naughty dog on the combat system of the original the last of us game, which, news flash, was built completely using scripting, written by designers, not programmers
Jon Blow probably thinks the folks at Naughty Dog aren't "serious programmers" for not using "real" (seriously, wtf?) languages
Thank you so much for your comment. Not sure why Jon Blow is so opinionated and can't acknowledge technical progress...
He's just a boomer who doesn't have any experience working on anything modern, I don't doubt his skills but his mindset is something else.
@@ducksoop.x He’s no boomer, which is easy to find if you bothered.
Besides, just because X does something, doesn’t make it the wisest choice. Just because X doesn’t do it doesn’t have anything different: they both have tradeoffs, and the question is, what tradeoffs are you willing and able to make? Context matters.
I say the same and everybody hates me for it! :D
I enjoy Jon's opinions, but I've made several games that run fine in JavaScript with very few bugs 🤷♂
Or, the thinking goes "We'll give them a scripting interface so they can customize it to suit their tastes" except they never do know what it is they want and they want YOU to customize it, not them. So it ends up making more work for you that's mostly not needed.
normally i think jblow mostly talks nonsense but this snippet is so true and makes me miserable day in day out, scripting is such a pandoras box that has caused nothing but trouble on projects i've been on.
hard disagree on the visual scripting take though, i'll let it go cause it was relatively new when this clip was made but visual scripting has become as bloated and load bearing as ye olde scripts were, is just as annoying to debug and has exactly the same problems as scripting languages do.
So basically its a skill issue on his part
Why is he using emacs if he doesn't like the tool?
He'd probably say "There's nothing better enough to be worth switching to."
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.
How can Jonathan Blow be such a pompous ass with every take he has?
In my opinion, this demonstrates his passion and concern for the future of game programming. Taking a more holistic perspective, it also reflects his worry about the broader software ecosystem. These factors contribute to his evident frustration.
First of all, scripting languages are used so game developers don't have to go through the pain of writing their entire game in C++ (which is already a messy complex language to work with). It also lessens development time, and the performance really depends on how you implement the code so that it doesn't get affected by things like garbage collection. It's also possible to write an entire game in C++, but have completely bad performance because of bad coding style.
Second of all, how do you define a "real programming language"? I define a programming language as one that solves problems and expresses a solution in which a computer system can understand and execute. If your definition of a "real" programming language is interfacing with the computer hardware, then the only "real" programming language is Assembly. Assembly is the only language where it allows users to completely interact with machine instructions, complete manipulation of memory, etc. Compiled languages such as C and C++ only generate machine code, but you never actually interface, nor completely control the code actually generated by the C/C++ compiler.
EDIT: Also, just a history lesson, C++ wasn't always the "lingua franca" of video gaming. Back then, Assembly and C (though in many engines, C was mainly used for scripting while the entire engine was made in Assembly) were pretty much the dominant languages of video gaming until games got more complex and hardware got more advanced, then C++ started becoming dominant, especially around 2005. After that, C++ became hard to work with because of its complexity, thus game development took longer. That's why scripting languages are used in the first place, to ease development time.
The assumption here is that the only alternative is to write their entire game in C++ when that patently isn't true. Java, C#, and D(Remedy Games are among the very few outfits that have used D in their games) are all compiled, strongly typed languages that are demonstrably and significantly fasters than scripting languages and prehaps more importantly...THEY SCALE
2:14
YOU KNOW WHO ELSE TENDS TO HAVE SEDUCTIVE PROPERTIES
MY MOM!
🤨
Are unmanaged languages the only legitimate kind of language to build games with according to this guy or did I misunderstand?
You misunderstood.
He's not talking about legitimacy, but efficiency and reducing programming errors.
So Unity named C# programs as "scripting".
With the way C# is structured we really shouldn't be calling it a scripting language. I only ever heard it being called scripting back in college when we were taught server-side scripting in C# with ASP. NET. and my professors called C# files as scripts, but I think that's from the legacy of programming anything server-side being called "scripting".
because it is. any language can be a scripting language it only depends on the context. everyone in here is missing the point
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.
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.
I was using lua on my engine. Not any more. Next PR will remove that HAHAHAHAH
the xi text editor allows extensions in any language using ipc
aaand it's dead
xi jingping xiao puao sisidlo
wtf hahaha
This is very reassuring for a newbie trying to make a simple game in lua, lol thanks John :/ not everyone is a computer genius, us dummies need scripting languages
I think he's mostly talking about hybrid systems. Where your system has 2+ different languages. If you build entirely in Lua then you don't face a lot of the complexity he's mentioning.
@@sasuke2910 ohhh got yah, I'm no programmer so forgive my ignorance
Don't worry about what this guy says, he's just as pretentious and narcissistic as his games.
Lua has the same complexity as C with slightly fewer pointer-related footguns. It's neither easier no harder than C, they are nearly the same language in terms of functionality, except Lua is more limited and weird in the way it achieves low-level programming
One of the problems with Lua in learning is it doesn't make you think about types ahead of time, which feels easy but gives you a lot of headache with typing issues that are stupid easy to solve in languages that force you to type your variables. (hint, put assert(type(arg) == number)) or whatever your type is everywhere
Embedding a scripting language is very Unixy but a terrible idea if you have to cross the programmer / artist barrier. Don't make programmers do art and don't make artists write code. It's just not the way they're wired. Bad results inevitably ensue. "The Art of Unix Programming" is by programmers, for programmers. Visual scripting is good for artists and gameplay programmers. You can have issues with performance. I'd treat it as a prototyping tool.
Is he a big proponent of the Suckless software community?
"today in the year 2020" *uploaded jun 2019*
Lua is great, what you talking bout willis
I see a lot of C# comments, probably because Unity uses it. But how often is Unity used for triple A games? UE4 is much more prevalent in AAA and only provides (hot reloadable) C++ and Blueprint. I think the whole flow of creating the engine in C++ and hooking up Mono is only done because computers have gotten very fast and we can get away with unoptimized solutions.
I mean. A lot of popular titles have used Unity and been very successful. While it's true most AAA games don't, that doesn't mean popular games don't
Not sure why everything is measured in terms of how many "A"s they have. Plenty of games, created by independent studios, have been made (written in C# either XNA or Unity) that feels like AAA. AAA titles is not a good measurement for how good an engine is, nor even how good those games and studios are.
Unreal is super annoying to learn for me due to blueprints and the elitist community. I learned Unity super easily because of the amazing documentation and the plentiful tutorials that still mostly work.
Unreal I find it hard to find good tutorials in c++ because most are in blueprints (why even use unreal if you are using blueprints?) and the documentation is laughable compared to Unity's.
I'd say about 60-70% of my steam library games are made with Unity and many of them are very popular and large games
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.
For gameplay I couldn't imagine using a scripting language, but for cutscenes, a scripting language is much better than using some tool provided by an engine for making cutscenes, you can go way way faster.
I've been saying this ever since I first encountered a scripting language, honestly
#honest 🤣
Welcome to 3 hour long Unreal Engine 4.26 game builds outputting 300GB of binary data. And assets are all binary because why should someone actually want to edit assets outside of a fullblown GUI game editor with thousands of buttons 😂
thank you- i needed this lol
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
Convince an AI dev
Overwatch uses a scripting language
...You just type some stuff...And it works! 🤣🤣🤣 Amazingly insightful perspective!
I have a friend who plays a wargame called "Dominions 5" and writes extensive mods using their scripting language, it's quite impressive and people seem to be happy with it.
Personally if I had to build a (2d) game with a non-programmer and that this person needed to be able to add content, I'd give them the possibility to add stuff using json or something like that but it would be really constrained.
Making a GUI tool would better their own "DX" but the constraints would be the same... It's not scripting per say because I could very well compile everything once we ship a beta/production build and keep it as "scripts" only for the dev build... Just talking outta my ass, tho.
Imagine how good would Emacs be if it didn't use a toy language like ELisp for everything.
What do you consider the deficiencies of Emacs Lisp to be then?
it should have adopted VimScript
Is C# ok??
www.quora.com/Why-do-game-companies-all-use-C++-rather-than-say-Lua-or-Java-Are-they-shifting-away-from-C++
Seems like we are all scrubs. This would explain however why I'm running into performance issues coding in C#. Basically scripting laguages have automated garbage collectors. You cant control the gc so you get unpredictable performance spikes. While in C++ there is no gc - so no unpredictable behaviour. But you have to take control of the lifetime of your object in memory yourself.
It seems you only can code in c# when using unity. Sooo i'll stay with c# for a while i guess.
@Scholar of the first sin I promise you that there is nothing fundamentally different between a Python "interpreter" and a Java or C# "virtual machine". You are just wrong trying to see C# as a compiled language.
Everything you just said is plain wrong and it shows you know nothing about the CLR.
@@nandoflorestan the plain ignorance of not explaining yourself is showing. @scholar please don't listen to this fool. Here is a better way of explaining it cs.stackexchange.com/questions/23951/are-java-and-c-also-purely-interpreted-languages
@@nandoflorestan moron
javascript is a scripting language and it has debugger.
He said "real debugger" wich Javascript doesn't have
...The problem with Starfield.
I've been coding for half my life and I don't even know what makes a language a scripting language, I just assume the ones with script on the end are scripting languages
It is not about programming language it's about how it's used, for example Javascript is used to manipulate browser objects so it's used as a scripting language in that context, VBA is used to manipulate Word, Excell, AutoCad and so on, so VBA is used a scripting language.
Most of early implementation of programming languages that wear designed to be used for scripting like Javascript are built as an interpreters but recent versions are usually generate machine code, but due to semantics of Javascript it may be harder to produce machine instructions, for example function add(a, b) { return a + b; } may operate on strings, numbers, dates so compiler may need to add checks to ensure that compiled block operates with correct types.
Its a scripting language if its interpreted and not compiled. Simple.
@@noahfletcher3019 this assumes I know the difference between interpretation and compilation lol
@@VolcanicPenguin Haha, you know what? I was gonna say something about the fact that you've been coding half your life and you don't know that. But, it's refreshing to see programmers who don't pretend like they know everything. Anyways, I guess the main difference is, compiled code is turned into machine code whereas scripted code is fed into a sort of virtual machine that performs all the instructions. That's a very brief overview but I definitely recommend you read about it, it's an interesting topic.
@@noahfletcher3019 That can be a problematic distinction because even interpreted languages often have preprocessing, compilation to bytecode etc. going on in the background to improve performance.
How I understand it "scripting language" means it's used as a secondary language for configuration or extensions for some software that doesn't require recompiling the whole thing. I think it makes sense in many situations, but Jonathan Blow is also correct in that properly implementing a scripting language in an engine may not be worth the trouble.
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.
The dumber the language - The better
The lesser interpretation by the language - The better
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 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.
The point is, you could do the same and just not use the scripting language, just use the real language, like how gmod was made. It's an HL2 mod, but wasn't made with scripting, same with Portal and Counter-Strike.
@@sasuke2910 yes but scripting adds ease of use. Source engine takes AGES to compile and it would mean that you will have to remake a game for modding... but Lua here saves the day.
@@alphenex8974 Compiling being slow is a fixable problem. I'm not sure what you mean by needing to "remake a game", you can use the same api that any Lua system uses.
@@sasuke2910 Yes, stuff can escape from sandbox environments, but can't a c/c++ DLL have malicious stuff implemented easily? Putting that responsibility on the players and not providing a safer way of modding feels treachery to your players imo.
@@yokunjon It might be slightly easier, but any sufficiently advanced mod system will be able to exploit or crash the host game in some way.
Sandboxing helps, but doesn't require you use two different languages. You can sandbox C++, C#, or whatever your main language is.
I think, main benefit of scripting languages that they allows players make mods to the games. Mods often improve base game experience (see Paradox Games, Warcraft 3, Skyrim or Dwarf Fortress for examples). With scripting languages is it even possible for players to fix bugs themselves (for example, there is a bugfix mods for Dragon Age Origins that fix combat, AI and/or quests).
If you ask players to use write a DLL in some serious programming language to make mod, that would not happen.
I despise the idea of using a language the engine is not built in to make the game. Indie devs (usually) do not have experience in code architecture and maintenance, they dont realize how much maintenance goes into bindings, upgrades, etc. You are essentially managing 3 things: language A, language B and translation between the two. That involves context, threading, exposing of interfaces. If you make a engine in C++, bite the bullet and learn how to add hot-reloadability. Scripting languages are not easier, more performant or simpler than exposing hot-reloadable files using the same language as the engine. I also seen a lot of indie programmers adding Lua because they think learning a 2nd language is easier than just cleaning up their engine's interface and making it simpe to use. 😔
Do you propose that we we also write programs in the language the the OS we use is written in?
The point about scripting languages not being easier, isn't true. This is why they exist in the first place, whether you like them or not. They make it easy for beginners to get started programming something without having to learn each and every compiler and linker and their billions of build systems.
@@dealloc I dont get your point. What is the purpose of a scripting language? If you already know C, why would you take your C engine and add Lua to it when you could just create an easier interface with the C you already have? What is the point of adding Lua? I dont know any programmer out there in the wild that only knows Lua for instance, so what is the point? The only option is that people have to learn Lua to use the scripting. Makes no sense, just learn the language of the engine and you can do both scripts and engine code. We're not talking scripting for modders that's irrelevant. Scripts as in scripts for the developers, so "beginners" are a non issue
@@Terszel Most people, who are serious about their engine/game, add scripting languages to make simple logic quicker to iterate on for designers.
If you were to build your game by yourself or with people who _know_ the language, a scripting language would just be a bottle neck. But you can't expect every game designer to know your flavor of C and build system and to keep up to date with how you change your APIs. Providing a stable API through a scripting language can help mitigate this.
@@dealloc it really isnt a challenge to learn build systems, thats part of onboarding which is standard and brings me back to my earlier point that devs shouldnt integrate scripting languages because their engine seems too complex for designers to use, if it is then the engine needs more work and you can have a visual layer rather than forcing useless languages down designers throats
@@Terszel Complexity is relative. There are no one true build system in C/C++..Each project and maintainer has their own flavor of API and build system, because there are no constraints in these languages.
I disagree that a scripting language is the result of a badly designed engine. Modern engines are more complex than your average indie developer's home-made engine and are very well designed.
I agree that visual scripting can work to some extent. But there are limitations where it breaks down. The more complex your logic gets, the harder it is for anyone to scan and follow the flow. This is already a problem with a lot of state machine-based animation tools for complex animations.
Designers should definitely learn to use the tools they work with, but teaching them C, because that is your favorite language, is not going to fly for most and will not be a cheap hire.
i disagree.. you don't use scripting language to code your gameplay or whatever. you need to use scripting languages to create content. core mechanics can remain in the core, be it C++ or any other language. the content is really entity scripts, world events, interactions, and all things that won't be executed constantly, most likely just once
Type checking. The one reason I never use python again :)
I dont use python because of its awfull oversimplified syntax, its slowness and as you said, type checking.
@@reinhold1616 Caring about syntax is a fallacy. *insert Wadler's Law
@@lincolnsand5127 I do care about it because things like if statement or loops openings are ended depending on the space
@@reinhold1616 If you aren't indenting code normally in C based languages, you're probably the issue. While I'm not a huge fan of whitespace significant syntax, my current stance is caring about it is bikeshedding
@@lincolnsand5127 Good point
Scripting languages make possible for some of the game logic to reside outside the compiled binaries. Which is critical for mods. Any game which must have robust mod support would always need to give some way to the mod makers to create game logic, conditionals and scripts to use in mods. So, yeah not gonna agree to Mr.Blow's hypotheses there at all.
How is that different from compiled languages? Dynamic libraries exist, not all of your code has to reside in the main executable, mods can ship dynlibs just fine. As a matter of fact, if you are shipping the compiler with the main game modders can also ship text files so the game could compile them during loading.
Dynamic libs for the rescue!
At least two quite major differences. 1) Security, scripting environments are easily sandboxable 2) if you ship dynlibs you'd have to be able to cross-compile them for every platform the game runs on
@@digitalspecter Youre already compiling the game for all the platforms it runs on so if youre shipping dynlibs, it would simply be another target for the build system. One wouldnt need to ship an x86 dynlib on an ARM platform I wouldnt think.
@@digitalspecter One has to consider tho that sandboxed environments are not 100% safe
modding tho
You don't need scripting for modding. You could interface with the engine with some development library, compile and drop that in the game.
he is so one man show indi game... and from his perspective he is absolutly correct...
it just doesn't work out on bigger teams
Problem is they used the easiest scripting languages. Kinda shows that some game developer coders aren't that great software programming or at least the ones making tool choices or more correctly more human than we think. If they used lisp it would be better but then you'd need real coders to understand lisp so it doesn't make it much easier at first. Emacs is the exception. Agree it needs an upgrade. Lisp is not that bad but can see why it's not popular with game developers. But it depends on how it's architect. Multiple exe example
Real coder is who can write machine code directly. Or write assembler.
Other are just giving pattern what they want to do .
One of the reasons Lisp would be good in this context is precisely that you DON'T need "real coders" due to Lisp's malleability. Honestly, I'm not sure why Lisp (and I mean Common Lisp) isn't popular among game developers, but garbage collection is probably one reason.
Also, CL is very pragmatic, easy to learn (as in; get results), facilitates refactoring well due to its simple syntax and semantics, and infinitely extensible due to the programmable reader and macros (functions processing code as data). Just because the language is so ingenious that people can write code that is difficult to understand even if you are an intermediate lisper, doesn't mean the language itself is difficult to learn and do useful stuff in. I probably would've never grokked programming if it weren't for Lisp, which I accidentally stumbled upon in a bookstore, and bought the book without having a clue about this unknown hipster language. It just looked interesting. Now, many years later, I'm writing a game engine in C, and I owe it all to Lisp.
the Andrew Tate of programming