There's a lot of bummed out comments in here about the syntax, but to me it looks a lot like what someone might see in a reimagined Typescript. Maybe a little Haskell thrown in for good measure. I agree they probably would have been better served just using an existing language with loads of existing tutorials like C# or Python, but if they're going to make something totally from scratch, I think a lot of decisions will actually make the language pretty easy to learn.
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.
> There's a lot of bummed out comments in here about the syntax
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
Programming languages have settled on '=' for assignment and '==' for equality comparison. Teaching people non-standard syntax because you think it might be easier is just doing them a disservice. Everyone I know that started with Pascal was mostly pissed that they didn't learn a language actually used in industry and had to re-learn the syntax. It's not like mathematical notation is intuitive in some way either - humanity needed several thousand years before we came up with something ergonomic, plus '=' is used for assignment in math just as often too. At least I do not know of any mathematician who uses ':=' to denote assigning a value to a name.
> Programming languages have settled on '=' for assignment and '==' for equality comparison.
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.
Most programming languages but not all. Three prominent examples are Pascal which you mention, OCaml, and the POSIX `test`/`[` command which all use `=` for equality. (More specifically, for structural equality, in the case of OCaml.)
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.
Go only uses := for declare & assign. For simple assignment it's =, and equality is still ==. So I would say it is barely different to the norm.
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.
This is textbook bikeshedding. If you have a bias for C syntax, everything else will look niche, weird, or "clearly insane" to you. But there's no reason that we should prefer C's syntactic decisions for assignment and equality operators in a non-C language. Go itself deviated from them, and the authors were instrumental to C itself.
> But there's no reason that we should prefer C's syntactic decisions for assignment and equality operators in a non-C language.
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.
In Verse there's no such thing as equality comparison. Assignment is the only thing that = does.If you want to do something if two things are equal, you attempt the assignment and whether this is logically consistent with the rest of the program determines whether the other things are executed.
One thing I noticed when I was in college was that the basics of FP is not hard, in fact it seems way easier (from my data annecdote).
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.
True story: when I started programming at age 11, in the book I saw a pair of assignments like:
x = x + y
y = y + 1
(or whatever). I was thinking, what, that has no solutions!
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.
You got me thinking and I think part of what it comes down to for typed FP languages is that you can either generally
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
> So we need an FP language doing what GoLang did to C++.
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.
We have a few of those, they just aren't popular. Ocaml and F# both fit, as well as ocamlish langs like rescript, which is really underrated imo.
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.
> What we need is an FP language that doesn't pretend that outside world doesn't exist. A pragmatical one.
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.
In general it's a mess. Very big language, so C++ issues.
Different communities liking different subsets.
Plenty of people "having to" use it, causing annoyance/hate.
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.
The main problem with using an established language like C# or Python in an embedded context is that they come with an expectation that the existing library ecosystem is supported. And that’s often just not realistic.
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.
I don’t see it like that. Because most of the tooling and ecosystem will work fine. No need to reinvent linters, formatters and dependency infrastructure. Perhaps slightly, 20% of the effort. Also, a subset of a language that does not include the batteries/platform is what made Node (and JavaScript as a general purpose language) possible and eventually very popular. Pragmatic communities deal very well with problems like these. Blender uses Python as scripting language and has tons of amazing plugins. I understand that Epic wouldn’t prefer a dynamic language (everything is a mutable object) though.
Has anyone tried Verse in the Fortnite context yet? I haven't used it yet, but I've been reading the documents.
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.
I have. At first it seemed a little restrictive because you can only really access other devices but I took a look at some of the example projects and it's relatively powerful for all its restrictions.
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.
Coming from the paper on Verse Calculus and having watched Simon Peytonjones’ talk last year I was super excited to try Verse in UEFN last week. Much to my dismay instead of a rich functional language I was met with something that looked like a DSL with python inspired syntax. As I played with the language I couldn’t stop thinking about “choice” and the other feature of verseMax I felt I was missing out on but after making a few toy maps I realized that epic had released a language entirely meant for the public. Reading Verse can be accomplished by anyone who can write a python for loop. The language is VERY accessible.
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.
I really like FP, but I think most FP language designers are a little too enamored with cryptic symbols and abbreviations.
Tried f# but the abbreviations turned me off, e.g. seq instead of sequence.
I made this comment elsewhere, but does anybody else find it funny that Epic is releasing an editor for Fortnite, when Unreal Engine started off as an editor for Unreal Tournament? I'm predicting that at some point, Epic will make such a popular game in the new Fortnite editor, that they'll release an editor for that game.
> Unreal Engine started off as an editor for Unreal Tournament
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.
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.
For those wondering why they've created yet another language, keep this in mind: Fortnite content is running code on possibly 100 remote clients simultaneously, and code often has state that needs to be synchronized across clients, which can often require rolling back the system to a specific previous state (which is a context FP languages tend to shine, because of the first class support for working with immutable data giving you easy snapshots of a system and resetting state)
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
Just because functional languages have immutable data locally doesn't make them any more suitable for handling data across "100 remote clients simultaneously". You need a bunch of stuff on top to make it work. Even reacting to state changes on a remote client is a problem in itself, you you can't wave it away with "but immutability".
> 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.
Yeah I'm not saying immutability solves the problem, I am saying that having good support for immutability is helpful for building those synchronization and rollback systems. If I thought immutability was all you needed I wouldn't be bringing up the effects system & pointing out how current languages still fall short in my own experience.
I've spent about 8 hours with it. It's neat to play with but I'm not yet sure it's the greatest fit for fortnight modding.
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.
Yes, very new, I don't think much information at all about the language was public until just some weeks ago. First release was included in a recently released Unreal Engine update
I think I may have been misreading, I was assuming that these effects were meant to be composed, but I guess they're exclusive to each other and form a tower (the preceding line even calls them the "exclusive effects", but I thought it just meant that this was an exhaustive list of effects).
I like it personally. I find it weird that everybody seems to be getting caught up in the syntax and choice of naming conventions. The language itself is so interesting and people dismiss it because types are snake case.
I also don't like the syntax, and that's because I use a lot of languages that are C-like, hence it's easier to understand the syntax between C#, Javascript/Typescript, Rust, Java, etc.
People that are used to FP are most likely to find it easier to understand or pleasant to look at.
- 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
Average age is a pretty bad metric for most things because “not adult but still engaged in society” is a pretty narrow band. If you have five 14-year-olds and one 40-year-old, the average age is over 18 (i.e., an adult) even though 83% of that group are not adults.
"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.
I'm not necessarily saying you are wrong here in the case of fortnite, but do you have data to back up that the average fortnite player is an adult? It seems like in general it tends to be wildly more popular with younger people, generally kids and teens - although i don't have data for this either, just based off what I've personally seen.
I have no data but anecdotes. I'm in my 40s and whenever I played squads, trios, or duos, I was playing with people in their 20s or 30s. Also, it's one of those rare online games where you can queue in at 3am or in the middle of a school day and almost instantly get into a game, and it's a game requiring 100 people per match. Other online games I've gotten into, 15 player games, essentially died out late at night or during schooldays. Fortnite doesn't.
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.
My anecdata, my teenagers won't play it, despite liking it [privately], because it's for "little kids" -- by which they mean Primary School (7-11yo) children.
They are ridiculously sensitive to their perceived age groups for games.
The game acts like it is designed for kids. It follows all the obnoxious gen Z trends, everything is in superbright colors, and speaks their design language. Hard to imagine that its userbase isn't mostly kids.
I dislike Verse, but also have experience with Lua, and Lua is horrible. There are very few built-in things, lots of strange decisions like indexing from 1...
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.