Live data from Hacker News

The Verse Programming Language [pdf]

simon.peytonjones.org

91–100 of 387 posts

Re: The Verse Programming Language [pdf]

#91
post #65
post #8

I'm not sure about the "learn it as a first language" bit. x:=(1|2); y:=(7|8); (x,y) This stuff just doesn't seem intuitive to me. It's not verbose enough to be obvious to someone who doesn't know what's going on. Looks interesting though; that's a really bright group of people. Be curious to see where their project ends up.

> 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…

+1 to this

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”

Re: The Verse Programming Language [pdf]

#92

No offense, but: does this actually relate the metaverse, or was that part added in so Epic Games would fund it? I don't see any first-class features that would be specific to that use case.

It doesn't. This presentation contains absolutely nothing of value for a real programmer trying to actually make stuff.

Hopefully we'll get more useful info soon, once it can be used in Fortnite.

Re: The Verse Programming Language [pdf]

#93
post #53

For those wondering if there's actually something relevant to the Epic's approach to the metaverse: there's not beyond slide 3. Everything after slide 3 is a description of the semantics of a novel functional logic programming language, the sort of which you'd expect you'd get if you paid the world's premier Haskell core contributor a large sum to design a new language. Of course its intended audience is Haskell acad…

Simon my boy.

The "View from 100,000 feet" slide does highlight the kind of experience SPJ would have in identifying where Haskell lacks a bit in pragmatism as a basis for a new, but not super different language. Hopefully the tooling is much better though.

Re: The Verse Programming Language [pdf]

#94

Earlier quoted context omitted.

I think it makes more sense if you don't think of it as an angle but a motivation. We've all been attacked with stuff like "shopping lists but on the blockchain!" for so long. This isn't like that. It's that they're foreseeing a technical problem of a shitload of concurrency and extra pain of API changes (metaverse) and this is meant to help.

I didn’t find the metaverse stuff to be a compelling motivation for the programming language features described. It felt to me more like ‘I had some ideas about programming languages after 20+ years of Haskell and research. Here’s my plan to unify logic programming with more normal functional programming (also we’re getting rid of monads). By the way my boss cares about the metaverse.’ But maybe that is too cynical.…

I followed Fortress eagerly at the time. I'd say if you want to see what eventually came of it, look at Julia. It's a pretty clear descendant.

Re: The Verse Programming Language [pdf]

#95

Reading half of it I'm struggling to see why they chose the semantic 'false?'. How do you read it? It sounds like a question, why not just 'false'?

AFAICT: Just "false" would be a regular boolean value. The question mark turns it into a logic value so it can be used in conditionals.

Re: The Verse Programming Language [pdf]

#96
post #26

This looks incredibly ambitious: - 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 n…

> 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.

Re: The Verse Programming Language [pdf]

#97
post #26

This looks incredibly ambitious: - 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 n…

> sequence of zero or more values 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…

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.

Re: The Verse Programming Language [pdf]

#98
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.

Re: The Verse Programming Language [pdf]

#100
post #48

This looks like a language designed for language designers and not for language users.

Wouldn't a language designed for current language users not bring much new to the table and mostly focus on familiarity and interop with existing la.guages?
Post reply on HN