Type system of Fortnite's Verse language
brianmckenna.org
brianmckenna.org
Everything being an expression should prevent a big trip hazard for new developers. As someone who teaches programming a lot, expressions vs statements vs special forms really confuses new developers.
In a lot of ways, this seems like a lot of good ideas from Haskell and Typescript, put into a straightforward syntax. I'd bet I wouldn't even think about the syntax after a week of cranking out code.
And the possibly to have dependent types down the road is very exciting! That would make things like STM so much easier, which would help immensely with scaling code.
The security implications of embedding a language like Python can be massive. Even the most basic libraries would be broken (e.g. a sandboxed script won’t be able to read and write files). And it may be just too much of a burden to try to enable decades of legacy cruft built with different assumptions than the host app (e.g. blocking vs async).
You end up with a halfway language that has the syntax but none of the ecosystem. And that’s a poor experience for a new developer who googles a Python tutorial, copy-pastes code into Fancy Metaverse App, and is immediately greeted by a horde of mysterious errors.
Consider the target audience - first time programmers. Verse has a syntax without the historical baggage of C, but still rather conventional. They avoided going off into functional strangeness land. ("Daddy, what's a monad?")
Define and initialize :=
Equality test =
Assignment set a := b
And and
Or or
More intuitive to complete beginners and definitely not unheard of.
In mathematics, I have seen both `:=` and `\equiv` for assignment. But Go and Pascal also use `:=`. Of these, I would consider Go quite widely used in the industry.
POSIX `[` is clearly insane so let's ignore that.
Which leaves Pascal and OCaml both of which are quite niche.
I think he's right. It's definitely not worth going against the grain with this syntax, and it's debatable if it's even that bad in isolation. I seriously doubt beginners struggle with it.
Yes there is - because almost every language uses the same convention, and it's a totally reasonable one. You have to have a really good reason to go against that and I don't see one.
> Go itself deviated from them
Go didn't deviate from the C convention. It just added an extra shorthand operator to simultaneously declare and initialise variables. The meanings of `=` and `==` are the same in Go as in C.
> or "clearly insane" to you
I wasn't saying the use of `=` for equality is clearly insane. `[` is clearly insane for other reasons.
A lot of style guides even had to include guards against the worst one:
‘if (variable = “string”)’
I think that putting guardrails there by making the assignment operator stand out was a smart move. Annoying to use, but smart.
Certainly not all. "=" is a poor choice for assignment as it has a totally different meaning in maths. Algol and Pascal got this right with ":=". Fortran got it wrong here.
> plus '=' is used for assignment in math just as often too
No it's a relational operator in math, so "x = x + 1" does not have the same meaning as assignment to a mutable variable.
In my university CS course, we start with FP (using Haskell), and in a course with one of the biggest number of dropouts un the first year, FP wasn’t really a reason for it, in fact, from the ten 1st year classes FP was in the top half in success.
BUT what I actually took from that experience was that the students having more trouble with FP (excluding dropouts that failed everything) were actually people that had programing experience before college. For the rest of the world pure functions are easy and “x = x + 1” is confusing as hell.
To note that even though we used haskell, monads were just a light touch at the end mostly to use IO. Haskell has an intrepeter, so you could have a language that mimics how you wrote functions before. It also helped that we learned recursion paralel with induction on a math class, so we where recursing over a Natural Int type on FP while difining naturals through induction on a math intro class (and proofs over inductive definitions are usually do e with recursion).
FP suffers from * unfamiliarity from the general programing community * bad tooling due to smaller community * people very vocal about a language like haskell which has research and teaching before production in its goals * no decent bridge from the academia ivory to industry.
Some languages like elm most issues but suffer from smaller community and weird dictator. Erlang was industry first but had a very small community (thus tooling), until elixir came aling decades later. And its focus get “solved” at a different layer/abstraction level by k8s. Ocaml has shit tooling F# is Microsoft ocaml, but suffers from most things you want to use with it are tailored for C#. Lisp derivatives seem to live in a world of their own. Closure seems popular, and i guess emacs will never be irrelevant. And in lisps you have to learn all the vocabulary as each project is almost its own language.
So we need an FP language doing what GoLang did to C++. Few features, very good tooling and libraries (as in golang has a formatter, builder, dependency manager, etc all on its “compiler”, and strong std lib), easy to read. Basically focusing on Developer productivity from hour 1. An “ML for the masses”, just like go was intended for devs straight out of college to be productive on day one.
It's not great for teaching due to not only being big, but tooling for first time usage is also not great, and it doesn't hit the nice things about FP for first time programers:
* functional syntax very similar to the way you defined functions in high school math class, or intros in college.
``` f : Z -> Z f(x) = x + 1 ``` is
``` f :: Int -> Int f x = x + 1 ```
in haskell (you can also omit domains/types/sets/signature in both). Familiarity is very important, which is why most programers do not like functional, and most people that haven't learned to program yet can start with it arguably more easily
just not having statements, and everything being immutable is really nice (x=x+1 is cancer).
Scala then has a whole lot of "class" stuff on top.
What we need is an FP language that doesn't pretend that outside world doesn't exist. A pragmatical one.
This is why Erlang/Elixir or even C# or hell even Javascript/Typescript are better FPs for the vast majority of programmers (and beginner programmers, too) than Haskell.
yes, anything focusing on devs being actually productive has to be pragmatic. So, yeah, real world exists, IO needs to be "easy/simple", just like compiling should be fast, good error messages, etc. Lots of constraints, Go is nice because it is "good enough" at everything. So it's productive general programming language.
> This is why Erlang/Elixir or even C# or hell even Javascript/Typescript are better FPs for the vast majority of programmers (and beginner programmers, too) than Haskell.
Disagree here. Fully agree those and pretty much all popular languages are better than haskell for the very mast majority of devs including beginner on actually delivering something aka work. I disagree that haskell is worse for somebody that never actually programmed to learn programming (which is fundamentally different than creating an working application or modifying one), specially at a CS college/university course, than any of the languages you listed.
"basic" Haskell is extremely simple. And it's syntax mirrors what you would typically use when are doing something with functions during your high school. Recursion is not harder than loops, the hard part is going from lots of familiarity with one to the other. I've seen people learning imperative first and functional first at different places, and I can tell you that the confusion first timers face getting to understand a loop is not smaller than recursion(again "x = x +1" hits hard against everything you see in school until programming, re-assigning is evil for teaching).
With recursion, haskell's enums/unions equivalent, and haskell's interface equivalent, you can get really far! So you won't hit haskell issues while teaching because: * problems/assignments can be self contained, you don't need to reach for libraries to make simple compiler for example, so you don't have the ivory tower of type category, all conversations about monads, someone else code using unfamiliar lingo/code * due to good interpreter, IO can be teached last, and can always be and should be only a layer over the rest of the code, and once familiar with the rest, writing some outer functions using do notation to pass to your core isn't troublesome to understand.
F# and Ocaml are not as nice for that purpose, as polymorphism/generics is better teached with haskell, and the language is more consistent without objects.
Racket and some lisps are nice, but i would say that Type checking is important for teaching, due to the whole concept of change data from one thing to another, gets easier to explain, the compiler gives some help as well.
Teaching 1st timers (assuming college) with Haskell Drawbacks IMO are only: * reaching for out of the class stuff, online discussions and public haskell libraries are hell due to academic mismatch. with too much * while type checking and compiler messages are a nice help teaching, they can also have the opposite effect with cryptic messages if for some reason there was some heavy polymorphic/generic code.
For a more general teaching, I'll add the drawback of not being able to do what the general crowd thinks of a "app" or "web app" etc, easily. JS just working on a browser is great, swift playgrounds are great, ruby has rails, etc.
There's also racket, which I think people give too much credit to as a teaching language, but is genuinely good and lets you easily separate FP from immutability semantics which tend to get conflated in this conversation. Janet, same, but with a different approach to that. Clojure, which is very practical and enforces the kind of constraints that make you think in a functional way.
If I was teaching programming from scratch to a beginner without a specific end goal I'd likely use one of these. I have taught total beginners and have observed a moderately functional style is intuitive to them. Rarely see a totally new programmer bust out the for loop once you show them map, etc.
Unfortunately when I've taught programming before it was with the specific goal of web development so JS was the only real choice.
x = x + y
y = y + 1
It's just due to notations; abusing the sacrosanct equal sign for something different. People otherwise have no problem with the idea of a datum being updated in place; it's part of everyday experience.
1) Go for a simple design, but having poor interop with existing ecosystems because the language lacks equivalent features. I see Elm in this camp, and it's hard to live in because the FP community has fewer people than other communities to build up another ecosystem
2) Go for a more fully featured design, integrating with some ecosystem (like F#, Scala), but you end up with multiple overlapping concepts and inconsistency in the native language's ecosystem
It seems like dynamic FP languages are the only ones to get away with a simple core and wide ecosystem by avoiding the need for features that are important for writing modular code in typed MLs. OCaml is probably closest to the sweet spot as a language+ecosystem, but the language tools are a bit weak coming from other platforms
Understand, this is a language for object behaviors. You don't write "a game" in Verse. You write behaviors for each type of object, and they interact to produce behavior. So it's a large number of little programs, reacting to events and talking to each other.
The main kinds of programs seem to be "devices" and "landscapes". Devices are entities within the scene, and "landscapes" are scenes. "Devices" will not usually have huge amounts of code.
There's a king of the hill game mode they used as a demo with a UI for class selection and all that. At first I thought that was impossible to do with the provided tools but Verse exposes a lightweight UI system you can use. So it's totally possible.
Playing with UEFN is definitely quite restricted but it reminds me of my quake/halflife modding days. I find I really excel in a restricted game development environment.
From the comments below I can see a lot of people are turned away by the idea of FP and this language was clearly meant to address those concerns. The type system is interesting from a high level view but for non-coders I can see how it would make sense.
For instance writing `if var = int` looks perfectly reasonable for someone who has never programmed before and it just works in verse.
So all in all while I was upset on a personal level at what Epic has released, I hope it is a stepping stone to their overall goal of verseMax. Furthermore I am excited at the idea of millions of people (kids) learning functional programming as their first language and think this iteration of verse may just be the perfect gateway drug.
[1] https://m.youtube.com/watch?v=832JF1o7Ck8 [2] https://simon.peytonjones.org/assets/pdfs/verse-conf.pdf [3] https://dev.epicgames.com/documentation/en-us/uefn/verse-lan...
Some history:
The Unreal Engine predates Unreal Tournament. Both Unreal and Unreal Tournament (UT99) ran on version 1 of UE. Its editor was UnrealEd, which was written in Visual Basic by Tim Sweeney but used the same renderer (Engine.dll IIRC) and shipped with the base Unreal game released in May 1998.
UnrealEd 2 was a C++ rewrite that came later with version 420 of UT99 and was then used for UE2 (Gears of War, Unreal 2, etc.) and beyond. It was first developed by ex-Legend Entertainment level designer Warren Marshall. I haven't really kept up-to-date with the Unreal Engine after v2, but I'm willing to bet there's not many lines of code left from that one in the current editor.
> Verse has been designed by some people who really know what they’re doing: Lennart Augustsson, Joachim Breitner, Koen Claessen, Ranjit Jhala, Simon Peyton Jones, Olin Shivers, Tim Sweeney
The listed people are all luminaries of the functional programming world (and adjacent, like theorem proving and software verification), particularly Haskell. Hell, Simon Peyton Jones is one of the creators of Haskell.
My point is, the creators of Verse aren't just a bunch of coders (pejorative) who felt like creating Yet Another Language.
It's still very early (while announced last year, it was only just shown at GDC last week!) so I expect we'll be hearing a lot soon.
Obviously, the association with Fortnite won't do it any favors. They claim they want
You might find the explanation in TFA helpful:
> "A battle royale lobby has just 100 players, which fit within a single compute shard.
> "But Fortnite is much more than just battle royale. A huge number of Fortnite players are on custom game modes made by people outside of Epic Games. It’s easy to imagine game modes having a few thousand players which can’t fit within a single shard. How do you scale to handle all that game state, correctly?
> "Software transactional memory is at the core of Verse. Computation is categorised by transactions and ability to rollback. The goal is to make it easy to write working software across multiple servers. A big goal; we don’t often see programmers do that successfully!"
SPJ spoke with disappointment about his lack of impact on Microsoft's products. Excel did end up adopting lambdas but that took a decade and a half. Inside Epic, he can roll out functional programming to a young audience that hasn't done much programming before.
And from what I can infer, Microsoft Research seems to be paying quite well. Do you have knowledge that indicates otherwise?
I mean he had lots of options, so the pitch from Epic must have still been pretty good.
On the other hand you have Erlang thesis from 1980s which is still true: https://erlang.org/download/armstrong_thesis_2003.pdf (updated in 2003)
The major problem being solved is that Fortnite did not fully control the fate of any other language.
What do you mean? I can't think of a better way to fast track a language to mass adoption.
When you type the words "the really know what they are doing" when talking about a language for game programming, I would expect people who know about game programming first, and about language design second.
There's a reason C/C++ and even C# are the go to languages for game programming, and not Haskell.
For example, the only presentation we've seen so far literally talks about Yet Another Language without mentioning a single problem it solves for game programming.
Perhaps fortnight is kind of a test.
As a result the only presentations these people do are about how great their new Yet Another Language toy is.
Compare this to, say, Jonathan Blow talking about design decisions for his language: https://www.youtube.com/watch?v=uZgbKrDEzAs
No, he doesn't. He lists what problems he's running into, the challenges he faces and what his language is trying to do to mitigate that.
The two presentations I've seen on Verse are: "look at this python-like language and its syntax" and "look at the types in this language!".
We've yet to see anything of any substance that actually describe the whys and the whats of the language beyond "oh yea we use STM to code for multiple servers" (which is a nonsensical statement)
"Fortnite Creator Economy 2.0 will share 40% of net revenue"
Well, one of the authors is Tim Sweeney.
> There's a reason C/C++ and even C# are the go to languages for game programming, and not Haskell.
It's interesting that you list those because none of them were originally designed for games. Well, C++ sort of was if you consider network simulations to be game-like.
I share your concern that this language looks like they packed a lot of functional programming candy in it and maybe not so much "actually reasonable for building a game" features.
But I think you're also underselling the expertise of the people involved. Also, my impression is that Verse is mostly intended as a game server language. I don't think you'll be writing physics or rendering in Verse. From that angle, a heavy focus on immutability, software transactions, etc. can make a lot of sense: it's trying to make it tractiable to author very large distributed systems with a lot of mutable state.
And yet, people are using those.
So, an introduction of a "programming language for game programming" should at least have:
- what are the challenges in game programming
- how they are solved or not solved by existing languages, and why people are using them
- what exactly this new language is bringing to the table, and how it solves those problems
What we've seen so far "loom at this amazing language that solves everything! Let's look at syntax and types".
> But I think you're also underselling the expertise of the people involved.
Or people are overselling the expertise and are blinded by the bright names
> Also, my impression is that Verse is mostly intended as a game server language.
See, you only have impressions and don't thinks, because there's really nothing about what the language really does, and what problems it aims to solve. Beyond some poorly executed marketing fluff.
And yet, none of those languages were pitched with a clear value proposition for games when they launched.
Not exactly sure why, but it really is.
- easy to embed
- good ecosystem (in particular needed Lua GObject Introspection for pangocairo)
- usable from C (not just C++)
- not white space sensitive
- skills translate to programming in the large
- it's fast
A lot of games let you write little snippets of code or what have you in a console or text box. Python is really bad at handling that because of its whitespace sensitivity. It's also the slowest popular language by far.
It’s also hard to stop python code from doing things it really shouldn’t, like calling os._exit.
Oh, you also have to deal with linking against the right crt on windows.
Lua started out life as a simple language for extending larger projects and then repeatedly broke backwards compatibility to make the language simpler. For example it's lexically scoped now but it wasn't to begin with.
Contrast with python, which started out life as a simple beginner friendly language, then added lots of complexity, then had the totally botched transition from 2.7 to 3 and is now growing a static type system.
Lua is also very easy to embed in other systems. Like sqlite.c levels of easy to embed.
1. Extremely permissive license.
2. Very simple embedding API.
3. Fairly efficient for a scripting language.
4. Simple and relatively easy to learn.
Not that it's bad, it just doesn't have any game or simulation specific features, manual memory management, etc.
Bar():int =
if (Foo[]):
1
else:
2
Find(X:[]int, F(:int)<decides>:void)<decides>:int =
for (Y:X, F(Y)):
return Y
false?I don't think so. TFA notes that Verse was created to support a non-trivial use case, which is to make it possible to write software that works across multiple servers in order to support thousands of simultaneous players.
https://dev.epicgames.com/documentation/en-us/uefn/verse-lan...
AFAIK at present time there’s no way of even using Verse outside of Fortnite mods.
It certainly seems that it’s best suited for the use case you described, but their site is trying to sell it as a “let’s all learn programming and mod Fortnite” thing.
And certainly I think they pulled it off. Go through the lessons here to see what I mean in nothing stands out as beginner unfriendly here, but it's also not black boxing much in the way Python would. https://dev.epicgames.com/documentation/en-us/uefn/learn-the...
For such a core pillar they are extremely light on details. All you can see in the docs is they basically have:
- green threads (maybe? no idea, no details on how async is executed)
- "async calls" are blocking. Literally the equivalent of `x = await y()`
- to have non-blocking calls you can use `Task = spawn(function)`, and then can optionally wait on it with `Task.await()`
- there are a few syntax sugars on top (like `race` aka `Promise.race`). And some of them make no sense (`branch` is literally `spawn`, why does it even exist?)
That... is not a "core pillar". It's a lazy minimal bare-bones implementation of decades-old ideas.
Edit. Compare with a language where it actually is a core pillar: https://erlang.org/download/armstrong_thesis_2003.pdf
Well, the opposite of that approach gives you Go.
I think Redstone in Minecraft are good examples of introduction to programming via visual programming languages. Something you can really feel and play around with. I'm not sure how Verse or Lua are integrated into their respective games but it's really hard to imagine kids being able to get into these languages without something that gives immediate visual feedback
Anecdotal, yes, but based on how popular Roblox has become, I would guess that its a fine enough intro language for even the next generation of software engineers
It's a really neat LISP. Yes, a LISP.
to factorial :number
if :number = 1 [output 1]
output :number * factorial :number - 1
end
to reverse :stuff
ifelse equal? count :stuff 1
[output first :stuff]
[output sentence reverse butfirst :stuff first :stuff]
end
And from https://dl.acm.org/doi/pdf/10.1145/3386329
Logo’s design drew upon two theoretical frameworks: Jean Piaget’s constructivism and Marvin Minsky’s artificial intelligence research at MIT. One of Logo’s foundational ideas was that children should have a powerful programming environment. Early Lisp served as a model with its symbolic computation, recursive functions, operations on linked lists, and dynamic scoping of variables.
....
In LCSI Logo, the if instruction above becomes a call to the if procedure, which takes three inputs:
if :x<0 [right 90] [left 90]
(if (< x 0) ’(right 90) ’(left 90))
The use of quoted instruction lists didn’t start with LCSI. From the beginning, the main looping facility has been
repeat 4 [forward 100 right 90]
----
LOGO was secretly introducing us to lambdas and thunks and closures... back in 3rd grade on the Apple][+.
One of my laments is "I wish that we had computer scientists teaching us LOGO back then rather than the librarian who just wanted some quiet while we played Oregon Trail."
So... the weird characters? We dealt with them as kids, that's no weirder than LOGO.
> So... the weird characters? We dealt with them as kids, that's no weirder than LOGO.
Most kids didn't learn much from LOGO. AIUI the best available research on learning programming (which is very limited) says that weird characters are a barrier to understanding, and so is case sensitivity.
> The first four years of Logo research, development and teaching work was done at BBN. The first implementation of Logo, called Ghost, was written in LISP on a PDP-1. The goal was to create a mathematical land where children could play with words and sentences. Modeled on LISP, the design goals of Logo included accessible power and informative error messages.
> Logo was a primary influence on the Smalltalk programming language. It is also the main influence on the Etoys educational programming environment and language, which is essentially a Logo variant written in Squeak (itself a variant of Smalltalk)
http://worrydream.com/EarlyHistoryOfSmalltalk/ for more on how LOGO influenced Smalltalk design.
I am saying that LOGO is old. It was written the same year that BCPL (the predecessor for C) was written. To say that LOGO is a member of {language family}, it should be restricted to languages that were in use at that time.
LOGO is a member of the LISP language family. From there, it also went on to influence many other influential languages.
I think in some ways we have become too afraid of some upfront complexity at the expense of beginners in order for more well engineered systems. I think a slightly higher learning curve is not always a bad thing.
we should strive to provide a better gateway than we had when we were young.
In general, lowering the entry barrier is good. But you are right that we may now be scared of anything that doesn't have a very low entry barrier.
Well, they have also inverted the usual capitalization conventions for seemingly no reason. Class names are lowercase_with_underscores and local variable names are UpperCamelCase.
aka snake_case
> UpperCamelCase
aka PascalCase
But yeah I agree it’s curious that they use these the other way around from what I am used to in Python and Rust.
PascalCase for variables reminds me of unification-based programming languages like Prolog.
More important question is if a language has a spec or just a default implementation, and if so if that's a compiler, interpreter, JIT etc.
For my money, we'd actually be better off if kids were still learning BASIC, for all its faults. I don't know Lua too well, but maybe that's best in breed. Don't even get me started on Python >:(.
One of the tensions is "make it learner-friendly" vs "align it with languages they're likely to use as professionals", aka "don't teach bad habits", but IMO this is grossly inflated as an issue because (a) many of these kids will not become programmers anyway, (b) they certainly won't if their learner languages put them right off by being full of counter-intuitive gubbins, and (c) the idea that learning BASIC, or Cobol, or whatever, fundamentally ruins your brain for "proper" programming is a manifest nonsense anyway.
Interesting to see some of the Skookum script async specific features in Verse such as the race keyword.
I worked with him briefly, and also talked over beers. Great chap!
It's a difficult problem to put it lightly, so as someone that dislikes new languages for only one tool, I consider this one of the cases where the benefits can outweigh the negatives
Interestingly this language has a concept of effect types that as far as I know has been only present in mostly research projects & a few general purpose languages like PureScript. Leaning on that to eliminate certain classes of bug from taking up your mental resources seems promising. Even in an ML I found myself wanting stricter guarantees about execution available while writing a PvP shooter for only a few clients, imagine 100! You can create DSLs to help with these things, but at that point I think it's asking to much for a beginner to learn both a new language and well enough to understand how DSLs can let you describe things with different semantics than you've already learned
I noticed they seem to have no mention of tagged enums/algebraic data types, which is unusual for a typed functional language, but there is an Optional type at least. I wonder if it has to do with the differences of their conditionals, which sound like they have far reaching implications, but I'm still not totally clear on how conditionals work in Verse
> but I'm still not totally clear on how conditionals work in Verse
To be honest, there's nothing clear about Verse at all. It promises to be everything for everybody, but is extremely light on details.
The talk sounded a bit unsubstantial, there being a lot of things he was not supposed to say yet. But still interesting.
Part of the problem is getting used to fortnight's device lexicon. Devices are kind of like code fragments or class instances you place in the world, they have a few events you can hookup and do various things.
It's certainly WAY more restricted than blueprints in terms of what is exposed. In fact the UEFN editor completely disables blueprint scripting. You can only compose blueprint classes. You can't write any blueprint logic.
Of course insecure middlebrow devs are gonna complain!
Lua would probably work just as well and been a better choice...
- this reduces fortnite’s audience to 12 year olds. the average age of a fortnite player is an adult
- fortnite custom mods / modes are nearly all developed by adults (the people who will write in this language)
- verse is designed to be used more widely than just fortnite in other games by other game develoment professionals (that are nearly all adults)
i don’t understand how anyone can see a game that makes billions each year and think “12 year olds” are the driving force. video games are not just for teenagers and adults are the primary revenue streams because they have the disposable income
62% of Fortnite players are 18-24
Yes, there are a lot of kids playing it, and it's very popular with them. But there's also a huge audience of adults.
Epic doesn't release specific numbers but they say in the T&C for creative that the content should appeal to 15-25 year olds I believe
They are ridiculously sensitive to their perceived age groups for games.
Kids' TV shows tend to have secondary audiences of their parents. I think this wouldn't apply to games as much but maybe there's some of that.
1. What does revenue have to do with target audience age? Roblox makes billions, right?
2. The only people I know that play fortnite are younger than 15.
3. "fortnite custom mods / modes are nearly all developed by adults" -> because the language is too difficult for new programmers?
4. "verse is designed to be used more widely than just fortnite" -> so is Lua and Python.
"I’m really excited that there will be 12-year-olds being introduced to programming by making Fortnite islands, using Verse and functional programming."
to which GP's comment is a valid response:
"It doesn't really look like the kind of thing I'd design for 12-year-olds to use?"
While one can agree or disagree, your response in that context is not correct:
"This reduces fortnite’s audience to 12 year olds."
Not at all. The discussion was about 12 year old players, not all players.
The examples they gave could have been improved with a bit of syntax highlighting.
People that are used to FP are most likely to find it easier to understand or pleasant to look at.