> 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.
At the same time… the language is interesting, and I’m sure it’s technically very well designed, but I’m not sure it’s a good fit for the task they’ve got. The apparent goal is for this to allow anybody to democratically contribute to Fortnite (a game most popular with a fairly young audience), but the language feels very technical and not-beginner-friendly to me. For example, it’s fairly symbol-heavy (making it intimidating and hard to read), uses inverted pascal case, and has some tricky semantic whitespace (it has indent-based comments!).
Bar():int =
if (Foo[]):
1
else:
2
Find(X:[]int, F(:int)<decides>:void)<decides>:int =
for (Y:X, F(Y)):
return Y
false?
+1 to this. If anything, you have a language that looks like it was made by luminaries, for luminaries. If you want something that would get kids that wanted to get into programming to create custom Fortnite modes, you want something that looks closer to Scratch or Python. I want to say Roblox has made programming quite accessible to children iirc
Why does it have to be either extreme? It certainly looks much easier than Agda or Coq. As someone without a CS degree, I applaud them for not racing to the bottom and creating an ad-hoc dynamically-typed soup, which still needs an instruction manual, if only to figure out how the equality operator works.
Programming has been going for a while, and there's a very wide variety of programming languages. I think one of the reason people have gone for things like Logo, Python, Lua when teaching kids is that there's a wide range of capabilities so you need to make sure they all can learn the basics without leaving others behind. If you try to teach anything too complicated the geek kids that are into computers and videogames will love it, but a third of the kids will just hate it. Maybe since Verse is a language expressly for Fornite, kids will self-select and it won't be as much of an issue, but if the question is whether it's a good language for kids to learn, it doesn't look very promising at first glance.
Having worked with a team building new programming languages and consisting of Haskell creators, I can confirm this was a near-fatal issue in those projects too.
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
Minecraft redstone is a terrible example. The idea of it is great, the implementation, not so much. It's super non obvious for a lot of thing, have got behaviour that changes based on location in the world, etc... It' not uncommon for people to dive into the code to figure out how redstone works or watching tutorials from people who have done so.
The only people who can use redstone are those who just memorize the standard gates and treat them as black boxes. That's no longer redstone then, that's just normal boolean logic stuff.
Maybe I’m revealing my youth here, but I played Roblox waaaay back as a middle-schooler around 2009/2010 or so (it existed in 2006!), and it was my first introduction to programming. The Roblox editor was _rough_, but Lua probably got me interested in the field of software in the first place.
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
I mean I was writing C++ in junior high and I am by no means that bright. Just persistent.
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.
On that topic, see the reaction to Rust. Rust has pros and cons, but perhaps the fairly high entry barrier shouldn't be considered a real issue for people who deal with very sophisticated abstractions and requirements all day long?
> The apparent goal is for this to be a “now everybody can contribute to Fortnite, democratize content” thing…
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.
Epic’s very first design goal for Verse is “simple enough to learn as a first-time programmer”, and all of their intro docs are framed around making content for Fortnite.
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.
Yes, but it's not an exclusive design goal. Other goals are listed on that page and you can see how design tradeoffs happened. You don't prioritize simplicity over all and make concurrency a core pillar!
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.
Disagreeing with some of the decisions they've made in regards to concurrency doesn't negate it from being a core pillar. Neither does wanting more information on why they've made the decisions that they have. This is common sense.
A lot of this type-system stuff is not really relevant to the Fortnite modder audience. If you look at the kind of code used in more practical examples (https://dev.epicgames.com/documentation/en-us/uefn/learn-cod...) it doesn't do very much of this -- it's basically Python crossed with Java.
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.
I'm just guessing, but snake_case might be inspired by dependently typed programming languages, where there's no strict boundary between terms and types.
PascalCase for variables reminds me of unification-based programming languages like Prolog.
I still make mods in Unreal Tournament. Unrealscript has its warts but does the job admirably. I can't look at Versescript without thinking that Unrealscript was better.
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]
The first input is a Boolean value, reported by the < procedure. The second and third inputs are instruction lists, only one of which will be evaluated by if depending on the value of the first input. Square brackets both delimit and quote a list, so [right 90] is equivalent to ’(right 90) in Lisp. The entire expression is therefore equivalent to
(if (< x 0) ’(right 90) ’(left 90))
in Lisp notation. How can Logo represent a thunk as merely the text of its body, without wrapping it in a lambda expression to capture its closure? See Dynamic Scope below (Section 3.7).
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]
with the instructions to be repeated inside square brackets.
----
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.
Sounds more like TCL than LISP. (Of course there are those who consider TCL part of the LISP family).
> 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.
LOGO was written decades before TCL and even half a decade before Smalltalk (which Wikipedia lists as one of the languages that LOGO influenced).
> 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)
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.
"Family" perhaps, but calling it a LISP is going too far when it doesn't have true macros (indeed most implementations have no macros at all). And to my mind the close similarity with TCL as a language is a lot more interesting than the details history, even- especially - if it's a point in the design space which both languages discovered independently rather than a case of one influencing the other.
I’m curious how much of this is due to examples coming from people who already are interested in programming languages and therefore a focus on language features or semantics. It’s not obviously hopeless to me for it’s intended purpose.
This is a valid point, but on the other hand we don't seem to have solved the problem of deciding the sweet spot of language features that are the best on-ramp for kids to get into coding.
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.
The typical perspective with functional programming, if you buy it, is that it is a little more investment in getting going, but once you have something compiling and working you spend less time on bugs and refactoring.
I think the problem with this claim is that "functional programming" (or "object-oriented" "procedural") aren't actually distinguishable kinds of languages but are more like social groups or aesthetic movements.
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.
Or they might be just creating a Yet Another Language precisely because they are luminaries of functional programming. Those often tend to chase a yet another unattainable dream of "the one true functional language".
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.
> I would expect people who know about game programming first, and about language design second.
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.
> It's interesting that you list those because none of them were originally designed for games.
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.
C/C++/C# are indeed often used for game programming but when it comes to gameplay logic scripting there's a lot more options. Lua, blueprint, lisp, angelscript, unity's graph language etc..
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.
I think that's definitely the reason from my talks with the engine programmers who added lua support to our bespoke engines. Lua binding is quite easy.
Long ago I evaluated a few scripting languages to add to a Doom engine, I think I considered Ruby, Lua, Python, JavaScript, and Squirrel. I ended up choosing Lua because:
- 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.
Slowest in runtime performance I'd guess as the CPython runtime isn't really known for its performance. Other projects such as PyPy implement a much faster interpreter/JIT compiler but there are some compatibility quirks to use them.
Runtime; there are things you can do, but generally Python takes more time and memory to do things than other languages/platforms. It got better in 3.11 but AFAIK it's still the slowest.
It’s not super difficult to embed python, but it ain’t easy. It is also very slow and insists on stat’ing a million files all over the disk when starting up.
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.
Sure, but my point was that some such YALs are just overgrown DSLs (cough UnrealScript) that find themselves facing the same kind of design problems that have been solved decades before by more forward-thinkers. In this case, these are good designers with decades of deep experience, and who I expect to have solved many design issues already.
C# is uniquely good at being a GC language that can easily interop with C/C++ code whilst also being quite performant itself. This is why it’s used for so many game engines.
There are some very obvious influences from Skookum script in Verse and that was designed for gameplay programming. I’d be surprised if Verse turned out to be a poor fit for games.
Why would Epic, owners of the primary reason why C++ is gravitated towards in game programming, spend time and money creating Yet Another Language just to satiate luminaries?
I'm confused by this example, Jonathan Blow sounds identical to LANGUAGE EXPERTS here. If anything the difference stems from humor, but they're both doing the exact same thing - arguing Yet Another Language is better.
> I'm confused by this example, Jonathan Blow sounds identical to LANGUAGE EXPERTS here.
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)
Generally speaking that's true. But I'm not entirely sure many luminaries would be satisfied being relegated to being the "Fortnite language". Surely they have larger goals here and it's why Epic is bothering when so much of their ecosystem relies on C++ currently.
I suspect they intend to roll this out the unreal engine some time in the future. Many people have been asking for a text based approach to game scripting (often it's ex-unity people asking for C# support.
> Nevertheless, I've yet to see an explanation of what problem Verse aims to solve that isn't solved by other languages out there.
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!"
The pitch for SPJ to leave MS research on Haskell for a video game company must have been pretty compelling so I’m very interested to see how this evolves.
From what I've heard, Microsoft wanted to downsize the research department in Cambridge. By UK labour laws it was possible to lay off basically everyone in a department, but would have legally been much harder to cherry-pick a few people to keep.
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 was playing with UEFN quite a bit the last week. As far as I can tell there is no way to make the player limit larger than 100 currently. Maybe it's a plan for the future.
it's also well known that if you put a bunch of functional programmers in a room and let them marinate its only a matter of time before they make another functional programming language
They forgot to include Conan Reis who has been at epic working on that stuff for a long time. He authored a game-specific scripting language called Skookum Script. I have used it a small amount on a couple projects. It's an interesting language but I didn't get deep enough to really have a strong opinion.
Interesting to see some of the Skookum script async specific features in Verse such as the race keyword.
> 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.