- There are no booleans in the language! Conditionals can still succeed or fail, but failure is defined as returning zero values and success is defined as returning one or more values.
- Verse uses a so-called 'lenient' evaluation strategy which is neither strict nor lazy, but somewhere in-between ("Everything is eventually evaluated, but only when it is ready")
- an expression does not evaluate to a value (like in Haskell), but instead to a sequence of zero or more values
- tries to bring functional logic programming into the mainstream
- Verse uses an effect system for I/O instead of monads
- A type in Verse is "simply a function". E.g. int is the identity function on integers, and fails otherwise
This all looks very mind-bending to me (in a good way). Perhaps Verse will one day be as influential for PL design as Haskell has been.
You can try this type of programming at home, say in JavaScript Make any result or argument be an Array. The problem with nulls goes away because "not there" is represented simply by an empty Array (a.k.a "sequence").
And you will not get null-errors because you can write:
newValue = someValue.filter(...) . map(...) ;
You don't need to test whether filter() returns an empty array or not, the map() will work for empty arrays too but simply do nothing.
This is in a sense "generalized programming" because you don't deal with individual values but always with collections of them. I sometimes wonder why I don't use this pattern more often.
Because now you can't differentiate between an actual empty array or an error. That's horrible.
Or, you actually have to use nested arrays to describe that the result might be an error or an array. But now you have to deal with an array which might contain... zero errors or even multiple ones.
That's really not a great way of doing things. Instead, do it the other way around and make null treatable in the same way as arrays are. And if you do that, you end up with what languages like Haskell do.
I had similar thoughts (I do JS/TS dev daily but I’m very interested in a lot of what this language appears to offer). But I’d caution trying this with JS for anything more than exploring the ideas presented by the pattern. The reality is that even adding a type checker like TypeScript, and as many lint rules as you can throw at a project, it’s still too easy to end up putting nullish values into your null-safe arrays.
And I similarly wondered why I don’t use this sort of pattern more often, but that wondering is what led me to add this caution. It’s a really compelling idea, but probably extremely hard to debug when it goes wrong in a language and idiomatic ecosystem designed for it to go wrong at any time.
> I sometimes wonder why I don't use this pattern more often.
Because while handy, it's not universally applicable (just like everything else :-))
I (C programmer, mostly) use sequences more often than you'd expect for parameters[1], but that does not mean that it makes sense to always return sequences.
In a lot of cases, sure, a function should return a sequence of values. In many other cases, it makes no sense - `if (canProceed(x,y,z))` reads more sensibly than `if (canProceed(x, y, z)[0]`.
[1] My string functions mostly lend themselves well to unlimited number of parameters. For example concatenation takes unlimited parameters and concats all of them, which it returns. Same with substring searching - take a source string and an unlimited number of substrings to find.
This includes a state monad that allows you to apply .map just like an array and a maybe monad that let's you do the same on values that might be nullish.
> This all looks very mind-bending to me (in a good way). Perhaps Verse will one day be as influential for PL design as Haskell has been.
I'm not convinced. Making non-determinism a first-class feature in the language might be good if you simply care about logical specifications that might enable you to prove something correct, but a real-world program implementation has to make heuristic choices for efficiency as to when to evaluate what (and perhaps where, especially in a parallel/distributed setting), and just stating that evaluation is "lenient" isn't really saying anything worthwhile. So this kind of design choice will ultimately be expressed with ugly hacks, as with e.g. Prolog where the 'cut' feature is used to override the default search strategy.
Icon had (has!) "failure is falsity" / "value production is truth", and pervasive generators / backtracking. In Icon a function ("procedure") either: fails, returns a value, or suspends (yields) a value.
jq is very much like this too, as it has pervasive generators and backtracking, but unlike Icon jq does not distinguish between "returning" a value vs. "suspending" (yielding) a value.
The jq way kinda means you have to have booleans, and so jq does.
I'm suspicious of the no-booleans approach. After all, one could also have no integers (the Lambda Calculus doesn't have integers, having only function values!). Boolean values are just useful to have, and being able to obtain boolean values from predicates is useful too. One could do the Icon/Verse thing of failure is false / anything is true, but provide an adapter function that produces actual boolean values for when you need them.
I was suspicious of javascript where number replaces int and double. The fail in verse is a way to replace boolean and null values. I think it is the direction of evolution.
> - There are no booleans in the language! Conditionals can still succeed or fail, but failure is defined as returning zero values and success is defined as returning one or more values.
> so-called 'lenient' evaluation strategy which is neither strict nor lazy, but somewhere in-between
Sounds like we are still clinging on to laziness in some regard, I wish we could get shod of it entirely. Although laziness makes doing Leetcode problems in Haskell really fun, Idris got it right when they opted for strict evaluation for predictable memory performance.
I am not convinced because far more pressing aspects have been ignored. One million programmers means program structure is more important than the syntax used to write the algorithms.
Does the language address common pain points like modifying data structures? Does it make it easy to extend existing code even without having the ability to change it?
It's definitely the most influential of the statically typed functional languages. All other statically typed functional languages or libraries inherit a lot from Haskell implementations, type system and type class concepts.
The first language to implement type classes. The first language to structure computation with monads, which are now omnipresent in functional languages.
These slides need a lot of work. I'll read the paper later, but the slides really lack context and motivation.
* I'm a little disheartened to see "Objectively: no. All languages are Turing-complete" in the context of the question of needing another language. It's a throw away comment and largely irrelevant when considering the actual use of programming languages. If one has to state this platitude, it is more accurate to say "theoretically" rather than "objectively", as I think the latter is actually debatable.
* The utility of the choice syntax over comprehension syntax is not clear at all. The choice thing seems neat, but I don't understand why comprehension semantics weren't just extended. Every example of choice seems to refer to sequences and comprehensions anyway to make the meaning clear. Will have to see more examples. Right now, the syntax seems a bit quirky, especially with `false?` thrown in.
* Why is `fst` not named `first`?! The shortening is maddening to me. It saves two characters (negligible savings), decreases readability, and first is probably just as fast to type.
* I'm still not sure why they're creating this language, what problems it solves, and what any of it has to do with a metaverse.
These are professors and language experts, so I'm a bit surprised by the presentation. Also, the idea that this language will be learnable as a first language is ambitious, if not naive.
> These slides need a lot of work. I'll read the paper later, but the slides really lack context and motivation.
SPJ is an exceptional public speaker, but that involves a lot of talking, a lot of context, audience participation, and a lot of wild gesticulating at slides.
I'm not sure if this talk was recorded, but I am sure if it was the recording will be much better than the slides, the slides are not really designed for consumption outside of the talk context, but rather as a reminder rather than taking notes. At least that's my experience having seen a number of his talks over the years.
I see using the choice syntax as PROLOG-esque, rather than Python-esque.
When you are building simple structures to iterate upon, it makes sense to use the more readable comprehension syntax, where you define a list or set of items and their desired properties.
Yet this terse syntax makes more sense for logic programming, where a lot of the domain logic is built upon generate-and-test patterns; you define a combinatoric search space which is the enumeration of all base value in pairs (or tuples), and check which ones are kept for the next processing steps. When using this pattern, it's clearer to be able to express the space with the shortest syntax rather than the verbose one.
As for the adequacy and need for the language, I have my own ideas on what's needed for the stated use case, and I do agree with the authors that this kind of language will really be easier to learn for people without a programming background; it looks much more like mathematics than the traditional von-Neumann-architecture, continuation-based languages, and its declarative nature may make it easier to approach without having a full understanding of runtime behavior.
> These are professors and language experts, so I'm a bit surprised by the presentation.
I am not surprised by this at all. If they really want to create something practical, I would rather employ the creator of Turbo Pascal, than one of the creators of Haskell. To me it seems as SPJ et al. are taking the money to do something fun and interesting, and scratching an itch they had for some time. Nothing wrong with that, but don't expect something that will be useful anytime soon.
Labeling someone who's had an immense impact on making strict static functional programming mainstream and relevant in the industry as unfit to developing such a language seems quite out of place.
SPJ has been implementing features that the industry and real world users wanted in Haskell for decades and yet you expect his cooperation with another great dev and business person like Sweeney to be fooling around and not produce "anything useful anytime soon"?
I recommend you reading the transcript of one of the latest SPJ's podcasts, he speaks both about the role of languages in the real world and about Sweeney's project:
I am not sure that fst and snd decreases readability. There was studies that showed that at least for alphabetic languages humans recognized words by the first and last characters initially ignoring the middle. So these abbreviations nicely play on that.
That’s probably a stretch because the study is probably more about the brain being able to fill in if needed rather than it being the same cognitive load. There’s no point in testing the brain in a programming language, and as far as I can tell, programmers are really the only ones that are obsessed with word length. It’s as if authors would just shorten “the” to “th” or “t” since it repeats a lot.
When did the L in FLP enter into the vision? I heard SPJ talk about the project a couple of times in interviews, but don't recall him mentioning anything about Curry or logic programming. I'm thrilled they seem to be taking that path!
Very interesting slides. As someone not very acquainted with game programming it helped me better understand the logic behind it.
As a sidenote, I found funny his predictions for 2009, because they're not far off from what we currently are aiming for:
- 20+ cores
- 80+ hardware threads
- GPU's with general computing capabilities
I honestly fail to see what properties of the language has anything to do with the metaverse, or millions of devs, etc...
At first I though the "choice" construct would be a way to distribute code execution among multiple computers (using the fact that in a grandiose metaverse, everything would be a connected computer with lots of compute time to spare ?) but there is not much detail.
Also it's not obvious from the slide if there is already a compiler / exécution env at the moment, or how far they are from it.
Now, the names behind this aren't exactly bozos, so I suppose we'll get to know soon.
> I honestly fail to see what properties of the language has anything to do with the metaverse, or millions of devs, etc...
They're pushing transactions straight from the beginning, which I think is the sanest way for multiple actors to all try to interact with the same world.
And for the compiler to stay sane in dealing with transactions, it's necessary to mark effects, which is also in the slides.
The inclusion of effects & transactions already puts it way outside of the mainstream, even without the Logic stuff (which I admittedly don't understand yet)
I guess I sort of see where it's coming from - the context is that hundreds of devs have to write code that has to preemptively cooperate with other code. So I think the lenient evaluation might be key for this.
Suppose you wander into a new environment, it contains some object x, and it has some capability f(x). Suppose your avatar or whatever has some code that already integrates with this f(x). You could just call f(x) in advance, and once you enter that environment, it lazily executes f(x). Or maybe I'm way off base here.
I don't know enough about Fortnite, but at some point if the metaverse wants to escape the "it's just a video game" trope, it's going to have to be... More than a video game, I guess ?
Can epic do that ?
Facebook a least "invented" a form a "passing time" (I'm being generous not to call it wasting time) that doubled as an advertising and marketing platform. And even that only took aff with the advent of smartphones, which enabled "using Facebook / twitter on the go" (and, more accurately, "on the loo").
When there's a VR helmet attached in every toilet, though... I'll sell hemoroid creams :)
Some of this reminds of me a combination Icon and Mozart. (And happened to just come across my old Icon book a few days ago.)
Maybe the backtracking concepts are "too built in?" - e.g., (1|2) is not a first-class/reified "amb" object, right? - so if I want to introduce a different search than depth-first backtracking (breadth, dependency-directed), etc., I couldn't directly.
Seems like there could be some confusion between multiple, backtracked values and actual sequences -- this often leads to sub-optimal/confusing Prolog code as well, deciding when you have an explicit control structure vs. backtrack, when to "harden" results using setOf/bagOf/findAll, etc.
For context, Prolog had a culture of "the built-in search is less than wonderful... but good for crafting a problem-appropriate search". II(fuzzily)RC, Mozart/Oz decoupled nondeterministic code (explicit amb, spelled "dis") specification from search, and allowed managing search over nested spaces of unification constraints and threads. With (very fuzzy) less use of backtrack-driven implicit sequences than in Prolog? I so don't remember Icon.
In Icon a function ("procedure") can: fail, return a value, or "suspend" (yield) a value (and then again and again). The difference between returning and suspending being that a generator that returns cannot be resumed again. That difference was needed (IIRC) because the alternative would be to end the generator with failure, which could be confused with failure in a boolean sense. jq gets this better by saying that a function can produce zero, one, or more values (just like Verse), but unlike Verse, jq does have booleans.
I prefer the jq approach to the Icon approach, which I think means I am suspicious of this aspect of Verse :)
Also, boolean values are inherently useful, and while checking that an expression is empty or not is a boolean predicate, it should be a predicate that produces a boolean value. Otherwise if we have no boolean values then we shouldn't have integer values either and just go back to the Lambda Calculus!
I was wondering if they are planning to use some datalog-style compilation strategy, where all choices are dumped into b-trees and nesting is replaced by indexed tables which are joined.
But I think mixing this with unification vars is sort of an open research problem?
Plus Haskell had a `data-parallel` mode which used a similar compilation strategy. It was dropped for being very complex and having virtually no users. Plus using too much broadcasting and compiling higher order functions into vectorized code had a serious performance tax.
> Like strict:, everything gets evaluated in the end
> Like lazy: functions can be called before the argument has a value
FYI, jq is just like that. In jq in `def f(g): ...;` `g` is a function value that will be applied to some input of `f`'s choice, and `g` is not evaluated unless `f` invokes it. The actual argument to `f` will be an expression which is wrapped in a closure named `g` while `f` is executing.
Lazy evaluation really is just hidden closures.
Lazy evaluation raises questions like:
How obvious shall the syntax make it that
you will be passing a closure instead of a
value?
Closures of dynamic or indefinite extent?
Can you choose which? How intrusive in the
syntax is that choice?
Does the use of lazy vs. strict infect
callees?
I.e., if I define a function `f` of one
argument of type `T`, must it be able to
take an argument that is a closure that
produces values of type `T`, or must that
be declared separately?
If the latter, does that mean I end up with
two `f`s, one which takes a value of type
`T` and one which takes a closure that
produces (a) value(s) of type `T`?
If so, does that happen automatically or
must I request it?
If the latter, what is the default, and
what happens if some library I want to use
one option doesn't provide it?
Finding a happy medium with some flavor of lazy evaluation but also which doesn't make it hard to understand the performance considerations of it is just very hard.
That sounds interesting to me. Part of why I don’t like GADTs in OCaml is that it feels like you’re trying to fit a programming language within the syntax of the type system.
No programming language is obvious to someone who doesn't know any programming. This particular example is even less clear because it's purely abstract; it literally doesn't do anything.
> I'm not sure about the "learn it as a first language" bit.
I think this is very subjective. Our minds have been "poisoned" - or rather trained over years - into a very specific way of thinking about expressions like in the example.
A first programming language, however, assumes that the learner hasn't been preconditioned in any way into a certain paradigm. So just keeping the two rules in mind that 1) evaluation is strictly from left to right and 2) an expression evaluates to a sequence of zero or more values immediately makes sense of the example.
Unfortunately it's incredibly hard to "reset" your mind into a state that doesn't know about variable assignments and thinking of variables as singular slots as is the case in Haskell and most other programming languages.
That's why "intuition" is a very subjective thing - your intuition changes with knowledge and experience and both are hard to suppress.
I remember struggling to understand the x = 7 syntax for storing a value in x. My young self was like “so if x is equal to 7, how come we can write x is equal to 8 later? That doesn’t make sense”
I get that to some degree, but that code doesn't look like something most people are exposed to, whereas 'x = 10' or something that says 'foreach' seems like it'd make sense with a minimum of explanation to a lot of people.
I'll be the first to hate on C++, but the only reason C++ might be considered a "don't learn it as a first language" language, is because it's huge. It's got 40 years worth of baggage, and it's "standard" libraries are an absolute mess. Javascript has a super simple syntax, and it's standard libraries though sometimes a bit idiosyncratic are comparatively clean and pragmatic.
If you just removed like 90% of C++'s useless standard library, and restricted the syntax to purely what's in Strousup's "Tour of C++" book, then I'm pretty sure that would be a pretty acceptable "learn it as a first language" language. Of course in that imaginary world C++ would also not have been deprecated by Rust.
The Python library is even larger and doesn't seem to be a barrier. If you know `std::vector`, `<<`, and `std::sort` it seems you're set to contribute to most code bases.
> C++ would also not have been deprecated by Rust.
In my uni they still teach C++ as a first language, that's why the "don't learn it as a first language" got me confused. The core language is very useful for learning programming, it is actually very clean.
Has it got currying? Partially applied functions passed around in folds and traverses are horribly difficult to read for beginners. Example: an Advent of Code solution posted in r/haskell for Day 10 this year, tell me how long it takes you to understand the function cycleStrengths.
signalStrength cycle x = cycle \* x
cycleGaps = [19, 40, 40, 40, 40, 40]
cycleStrengths = foldr a (const []) cycleGaps . (\x -> (1, x))
where
a n r (i, xs) = signalStrength m y : r (m, ys)
where
m = i + n
ys@(y : _) = drop n xs
That kind of code is sometimes easier to write than read… you build it up incrementally. On the other hand it’s easy to refactor this to make it readable. Is Haskell supposed to be an easy language for beginners? Is Verse? Not every language should be.
I might be totally off, as I don't know any vercel. But the declarations look like "x can be 1 or 2, y can be 7 or 8, and let's declare a superposed tuple of these which could be any combination of the values". I don't see the point, but that's what I understand by reading raw syntax.
That's the usual way to read it, yes. The point is that you can then ask it e.g. to "find a tuple where x > y", and later expressions will be evaluated only for tuples that meet this condition.
In logic programming it's known as the "generate and test" pattern, where you declare the tuple and the program logically generates all its possible values, and then tests each value for compliance. The runtime usually will ensure to make this in an efficient way.
P.S. See the definition of the "amb" operator in typical logic programming languages:
It's the cartesian product. Think of it as a table with x labeling the top (x-axis) and y labeling the left side (y-axis). The cells of the table are the result of the product.
x 1 2
y |--------------
7 | (1,7) (2,7)
8 | (1,8) (2,8)
Except, as the slides indicate, sequences of values are not sets. They are ordered. You can also, as they mention, refer to "y" in the definition of "x". This is like set union, but it is, again, sensitive to ordering of elements.
I'm not sure about the "learn it as a first language" bit.
My university taught Haskell as its intro language to math and science students, and the people who had the most problems where those who already knew a bit of programming. People for whom Haskell genuinely was their first introduction to a programming language on the whole had no problem getting it. I imagine this might be the same.
The main downside with the approach was that when these people who had just learnt Haskell moved on to the next programming course, that was taught using Java, they had a really hard time understanding what was going on.
Contrary to what others are saying... From my time spent in MUDs/MOOs 30ish years ago and the languages we were playing with then, I can see plenty here that actually does relate to the problem of programming in a large scale shared-state world aka "multiverse" (hate the world)
Transactionality. Check. ACID type semantics are absolutely key to handling the concurrency issues created by a world with thousands of authors/programmers and concurrent actions. This is not the place for locks.
Declarative. Essential. This is going to be the only way to manage the complexity of interactions on a large scale. Though perhaps I don't jibe with the particular form described here and would instead encourage a more relational/datalog type approach, but that's my bias.
And management of mutable state / side-effects, through functional type approaches also seems key. Not just for expressing problems elegantly, but also for security / visibility management.
Some of the interesting things in here (approach to truth values etc) have a vibe similar to the approaches behind evaluation in a Datalog but also look similar in spirit to some of what's behind my employer's (RelationalAI) knowledge management programming language, Rel: https://docs.relational.ai/rel/primer/overview
Finally, people saying it looks difficult to learn, I think that for many people working in this kind of environment... it could be their first programming language. So they don't come with the same baggage & expectations about what programming languages are. Back in the 80s and 90s there were all sorts of "game builder" (esp for interactive fiction) type languages that often had what we'd now see as "odd" semantics. But this was part of the advantage. Heterodox approaches often bloom in domain specific locales.
Going to spend some more digging into this after dinner. Neat stuff.
Hi, fellow MUD/MMO person here with an additional background in blockchain.
Can you walk us through where you think a language like Verse really shines with transactionality versus the current server authoritative models we see implemented in [language here] using [framework/pattern] here (like C++ and ECS)?
I've done my fair share of FP (got into Haskell years ago) so I see value here, but I'm not sure I'm grokking your level of excitement and would like to understand better.
Readit News
- There are no booleans in the language! Conditionals can still succeed or fail, but failure is defined as returning zero values and success is defined as returning one or more values.
- Verse uses a so-called 'lenient' evaluation strategy which is neither strict nor lazy, but somewhere in-between ("Everything is eventually evaluated, but only when it is ready")
- an expression does not evaluate to a value (like in Haskell), but instead to a sequence of zero or more values
- tries to bring functional logic programming into the mainstream
- Verse uses an effect system for I/O instead of monads
- A type in Verse is "simply a function". E.g. int is the identity function on integers, and fails otherwise
This all looks very mind-bending to me (in a good way). Perhaps Verse will one day be as influential for PL design as Haskell has been.
You can try this type of programming at home, say in JavaScript Make any result or argument be an Array. The problem with nulls goes away because "not there" is represented simply by an empty Array (a.k.a "sequence").
And you will not get null-errors because you can write:
You don't need to test whether filter() returns an empty array or not, the map() will work for empty arrays too but simply do nothing.This is in a sense "generalized programming" because you don't deal with individual values but always with collections of them. I sometimes wonder why I don't use this pattern more often.
Or, you actually have to use nested arrays to describe that the result might be an error or an array. But now you have to deal with an array which might contain... zero errors or even multiple ones.
That's really not a great way of doing things. Instead, do it the other way around and make null treatable in the same way as arrays are. And if you do that, you end up with what languages like Haskell do.
And I similarly wondered why I don’t use this sort of pattern more often, but that wondering is what led me to add this caution. It’s a really compelling idea, but probably extremely hard to debug when it goes wrong in a language and idiomatic ecosystem designed for it to go wrong at any time.
Because while handy, it's not universally applicable (just like everything else :-))
I (C programmer, mostly) use sequences more often than you'd expect for parameters[1], but that does not mean that it makes sense to always return sequences.
In a lot of cases, sure, a function should return a sequence of values. In many other cases, it makes no sense - `if (canProceed(x,y,z))` reads more sensibly than `if (canProceed(x, y, z)[0]`.
[1] My string functions mostly lend themselves well to unlimited number of parameters. For example concatenation takes unlimited parameters and concats all of them, which it returns. Same with substring searching - take a source string and an unlimited number of substrings to find.
This includes a state monad that allows you to apply .map just like an array and a maybe monad that let's you do the same on values that might be nullish.
I'm not convinced. Making non-determinism a first-class feature in the language might be good if you simply care about logical specifications that might enable you to prove something correct, but a real-world program implementation has to make heuristic choices for efficiency as to when to evaluate what (and perhaps where, especially in a parallel/distributed setting), and just stating that evaluation is "lenient" isn't really saying anything worthwhile. So this kind of design choice will ultimately be expressed with ugly hacks, as with e.g. Prolog where the 'cut' feature is used to override the default search strategy.
jq is very much like this too, as it has pervasive generators and backtracking, but unlike Icon jq does not distinguish between "returning" a value vs. "suspending" (yielding) a value.
The jq way kinda means you have to have booleans, and so jq does.
I'm suspicious of the no-booleans approach. After all, one could also have no integers (the Lambda Calculus doesn't have integers, having only function values!). Boolean values are just useful to have, and being able to obtain boolean values from predicates is useful too. One could do the Icon/Verse thing of failure is false / anything is true, but provide an adapter function that produces actual boolean values for when you need them.
This is similar to how Icon works: https://en.m.wikipedia.org/wiki/Icon_(programming_language)
Deleted Comment
Sounds like we are still clinging on to laziness in some regard, I wish we could get shod of it entirely. Although laziness makes doing Leetcode problems in Haskell really fun, Idris got it right when they opted for strict evaluation for predictable memory performance.
I'm decidedly in the not convinced camp.
Does the language address common pain points like modifying data structures? Does it make it easy to extend existing code even without having the ability to change it?
Has Haskell really been that influential though? It seems to me that MLs, Lisps, Schemes, and even Erlang have been more influential.
* I'm a little disheartened to see "Objectively: no. All languages are Turing-complete" in the context of the question of needing another language. It's a throw away comment and largely irrelevant when considering the actual use of programming languages. If one has to state this platitude, it is more accurate to say "theoretically" rather than "objectively", as I think the latter is actually debatable.
* The utility of the choice syntax over comprehension syntax is not clear at all. The choice thing seems neat, but I don't understand why comprehension semantics weren't just extended. Every example of choice seems to refer to sequences and comprehensions anyway to make the meaning clear. Will have to see more examples. Right now, the syntax seems a bit quirky, especially with `false?` thrown in.
* Why is `fst` not named `first`?! The shortening is maddening to me. It saves two characters (negligible savings), decreases readability, and first is probably just as fast to type.
* I'm still not sure why they're creating this language, what problems it solves, and what any of it has to do with a metaverse.
These are professors and language experts, so I'm a bit surprised by the presentation. Also, the idea that this language will be learnable as a first language is ambitious, if not naive.
SPJ is an exceptional public speaker, but that involves a lot of talking, a lot of context, audience participation, and a lot of wild gesticulating at slides.
I'm not sure if this talk was recorded, but I am sure if it was the recording will be much better than the slides, the slides are not really designed for consumption outside of the talk context, but rather as a reminder rather than taking notes. At least that's my experience having seen a number of his talks over the years.
When you are building simple structures to iterate upon, it makes sense to use the more readable comprehension syntax, where you define a list or set of items and their desired properties.
Yet this terse syntax makes more sense for logic programming, where a lot of the domain logic is built upon generate-and-test patterns; you define a combinatoric search space which is the enumeration of all base value in pairs (or tuples), and check which ones are kept for the next processing steps. When using this pattern, it's clearer to be able to express the space with the shortest syntax rather than the verbose one.
As for the adequacy and need for the language, I have my own ideas on what's needed for the stated use case, and I do agree with the authors that this kind of language will really be easier to learn for people without a programming background; it looks much more like mathematics than the traditional von-Neumann-architecture, continuation-based languages, and its declarative nature may make it easier to approach without having a full understanding of runtime behavior.
I didn’t think otherwise. Many functional languages have comprehension syntax, and I prefer declarative programming.
> When using this pattern, it's clearer to be able to express the space with the shortest syntax rather than the verbose one.
How is
or more verbose than ? Also, the first and especially second are basically identical to mathematical syntax, but the first implies order better.I am not surprised by this at all. If they really want to create something practical, I would rather employ the creator of Turbo Pascal, than one of the creators of Haskell. To me it seems as SPJ et al. are taking the money to do something fun and interesting, and scratching an itch they had for some time. Nothing wrong with that, but don't expect something that will be useful anytime soon.
SPJ has been implementing features that the industry and real world users wanted in Haskell for decades and yet you expect his cooperation with another great dev and business person like Sweeney to be fooling around and not produce "anything useful anytime soon"?
I recommend you reading the transcript of one of the latest SPJ's podcasts, he speaks both about the role of languages in the real world and about Sweeney's project:
https://haskell.foundation/podcast/11/
No writer does this. Why are programmers obsessed with word length to such a degree?
Personally I've got used to them like in no time
Deleted Comment
Also they both seem to have a preference for using Comic Sans on slides ...
As a sidenote, I found funny his predictions for 2009, because they're not far off from what we currently are aiming for: - 20+ cores - 80+ hardware threads - GPU's with general computing capabilities
At first I though the "choice" construct would be a way to distribute code execution among multiple computers (using the fact that in a grandiose metaverse, everything would be a connected computer with lots of compute time to spare ?) but there is not much detail.
Also it's not obvious from the slide if there is already a compiler / exécution env at the moment, or how far they are from it.
Now, the names behind this aren't exactly bozos, so I suppose we'll get to know soon.
Wait and see, I guess ?
They're pushing transactions straight from the beginning, which I think is the sanest way for multiple actors to all try to interact with the same world.
And for the compiler to stay sane in dealing with transactions, it's necessary to mark effects, which is also in the slides.
The inclusion of effects & transactions already puts it way outside of the mainstream, even without the Logic stuff (which I admittedly don't understand yet)
Suppose you wander into a new environment, it contains some object x, and it has some capability f(x). Suppose your avatar or whatever has some code that already integrates with this f(x). You could just call f(x) in advance, and once you enter that environment, it lazily executes f(x). Or maybe I'm way off base here.
It is expected to release in January as part of Fortnight Creative (delayed from this month).
I honestly cannot wrap my head around how a programming language of all things should solve the "millions of programmers working on a thing"-issue.
Can epic do that ?
Facebook a least "invented" a form a "passing time" (I'm being generous not to call it wasting time) that doubled as an advertising and marketing platform. And even that only took aff with the advent of smartphones, which enabled "using Facebook / twitter on the go" (and, more accurately, "on the loo").
When there's a VR helmet attached in every toilet, though... I'll sell hemoroid creams :)
Maybe the backtracking concepts are "too built in?" - e.g., (1|2) is not a first-class/reified "amb" object, right? - so if I want to introduce a different search than depth-first backtracking (breadth, dependency-directed), etc., I couldn't directly.
Seems like there could be some confusion between multiple, backtracked values and actual sequences -- this often leads to sub-optimal/confusing Prolog code as well, deciding when you have an explicit control structure vs. backtrack, when to "harden" results using setOf/bagOf/findAll, etc.
For context, Prolog had a culture of "the built-in search is less than wonderful... but good for crafting a problem-appropriate search". II(fuzzily)RC, Mozart/Oz decoupled nondeterministic code (explicit amb, spelled "dis") specification from search, and allowed managing search over nested spaces of unification constraints and threads. With (very fuzzy) less use of backtrack-driven implicit sequences than in Prolog? I so don't remember Icon.
Curiously, https://www2.cs.arizona.edu/icon/books.htm includes a "newish" (2010) book, "Icon Programming for Humanists".
I prefer the jq approach to the Icon approach, which I think means I am suspicious of this aspect of Verse :)
Also, boolean values are inherently useful, and while checking that an expression is empty or not is a boolean predicate, it should be a predicate that produces a boolean value. Otherwise if we have no boolean values then we shouldn't have integer values either and just go back to the Lambda Calculus!
But I think mixing this with unification vars is sort of an open research problem?
Plus Haskell had a `data-parallel` mode which used a similar compilation strategy. It was dropped for being very complex and having virtually no users. Plus using too much broadcasting and compiling higher order functions into vectorized code had a serious performance tax.
--
Verse is a functional logic language (like Curry or Mercury).
Verse is a declarative language: a variable names a single value, not a cell whose value changes over time.
Verse is lenient but not strict:
Like strict:, everything gets evaluated in the end
Like lazy: functions can be called before the argument has a value
Verse has an unusual static type system: types are firstclass values.
Verse has an effect system, rather than using monads.
--
Verse is extremely ambitious
Kick functional logic programming out the lab and into the mainstream
Stretches from end users to professional developers
Transactional memory at scale
Very strong stability guarantees
A radical new approach to types [me: predicate functions]
Verse is open
Open spec, open-source compiler, published papers (I hope!)
Before long: a conversation to which you can contribute
Deleted Comment
> Like lazy: functions can be called before the argument has a value
FYI, jq is just like that. In jq in `def f(g): ...;` `g` is a function value that will be applied to some input of `f`'s choice, and `g` is not evaluated unless `f` invokes it. The actual argument to `f` will be an expression which is wrapped in a closure named `g` while `f` is executing.
Lazy evaluation really is just hidden closures.
Lazy evaluation raises questions like:
Finding a happy medium with some flavor of lazy evaluation but also which doesn't make it hard to understand the performance considerations of it is just very hard.That sounds interesting to me. Part of why I don’t like GADTs in OCaml is that it feels like you’re trying to fit a programming language within the syntax of the type system.
Looks interesting though; that's a really bright group of people. Be curious to see where their project ends up.
If it were
You would recognize it instantly.I think this is very subjective. Our minds have been "poisoned" - or rather trained over years - into a very specific way of thinking about expressions like in the example.
A first programming language, however, assumes that the learner hasn't been preconditioned in any way into a certain paradigm. So just keeping the two rules in mind that 1) evaluation is strictly from left to right and 2) an expression evaluates to a sequence of zero or more values immediately makes sense of the example.
Unfortunately it's incredibly hard to "reset" your mind into a state that doesn't know about variable assignments and thinking of variables as singular slots as is the case in Haskell and most other programming languages.
That's why "intuition" is a very subjective thing - your intuition changes with knowledge and experience and both are hard to suppress.
I remember struggling to understand the x = 7 syntax for storing a value in x. My young self was like “so if x is equal to 7, how come we can write x is equal to 8 later? That doesn’t make sense”
If you just removed like 90% of C++'s useless standard library, and restricted the syntax to purely what's in Strousup's "Tour of C++" book, then I'm pretty sure that would be a pretty acceptable "learn it as a first language" language. Of course in that imaginary world C++ would also not have been deprecated by Rust.
The Python library is even larger and doesn't seem to be a barrier. If you know `std::vector`, `<<`, and `std::sort` it seems you're set to contribute to most code bases.
> C++ would also not have been deprecated by Rust.
That's an overstatement, to say the least.
Personally I love this headscratching stuff, but I would not ever dream of subjecting it upon a beginner programmer.
In logic programming it's known as the "generate and test" pattern, where you declare the tuple and the program logically generates all its possible values, and then tests each value for compliance. The runtime usually will ensure to make this in an efficient way.
P.S. See the definition of the "amb" operator in typical logic programming languages:
https://rosettacode.org/wiki/Amb
My university taught Haskell as its intro language to math and science students, and the people who had the most problems where those who already knew a bit of programming. People for whom Haskell genuinely was their first introduction to a programming language on the whole had no problem getting it. I imagine this might be the same.
The main downside with the approach was that when these people who had just learnt Haskell moved on to the next programming course, that was taught using Java, they had a really hard time understanding what was going on.
It's just more explaining, boring and driving people away.
https://stackoverflow.com/questions/29451291/cartesian-produ...
Transactionality. Check. ACID type semantics are absolutely key to handling the concurrency issues created by a world with thousands of authors/programmers and concurrent actions. This is not the place for locks.
Declarative. Essential. This is going to be the only way to manage the complexity of interactions on a large scale. Though perhaps I don't jibe with the particular form described here and would instead encourage a more relational/datalog type approach, but that's my bias.
And management of mutable state / side-effects, through functional type approaches also seems key. Not just for expressing problems elegantly, but also for security / visibility management.
Some of the interesting things in here (approach to truth values etc) have a vibe similar to the approaches behind evaluation in a Datalog but also look similar in spirit to some of what's behind my employer's (RelationalAI) knowledge management programming language, Rel: https://docs.relational.ai/rel/primer/overview
Finally, people saying it looks difficult to learn, I think that for many people working in this kind of environment... it could be their first programming language. So they don't come with the same baggage & expectations about what programming languages are. Back in the 80s and 90s there were all sorts of "game builder" (esp for interactive fiction) type languages that often had what we'd now see as "odd" semantics. But this was part of the advantage. Heterodox approaches often bloom in domain specific locales.
Going to spend some more digging into this after dinner. Neat stuff.
Can you walk us through where you think a language like Verse really shines with transactionality versus the current server authoritative models we see implemented in [language here] using [framework/pattern] here (like C++ and ECS)?
I've done my fair share of FP (got into Haskell years ago) so I see value here, but I'm not sure I'm grokking your level of excitement and would like to understand better.
“To answer "what does this program do, or what does it mean?“ just apply the rewrite rules.”
Whenever a senior engineer* uses the word "just" you're about to have a bad time.
* Or an expert in anything, really…