Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Verse Programming Language [pdf]

simon.peytonjones.org

Post reply on HN
Print view View original

321–330 of 387 posts

Re: The Verse Programming Language [pdf]

#321

Post by moloch-hai »

bmitc wrote: post #298
moloch-hai wrote: post #295

Earlier quoted context omitted.

That is not idiomatic C++. The author is showing off esoterica.

Thanks for the heads up. From the outside looking in, my perception of the difficulty of learning C++ is knowing what is idiomatic or not, with the understanding that that differs depending on who you work for and with.

It is the same as in other languages: you do the simplest thing that gets the job done. Loops, particularly C-style "for" loops, often do not count as simple, despite their familiarity: std:: algorithms leave less scope for error.

Re: The Verse Programming Language [pdf]

#322

Post by mark_l_watson »

I might as well start with: I was disappointed to get near the end and see that ShipVerse would not be available until sometime in 2023.

Other than that I like a galactic scale transactional memory and trying to make Haskell simpler for the masses while still supporting professional programmers.

I worked hard to understand the slides (BTW, I am an enthusiastic but not skilled Haskell programmer) and in 6 months or so when they drop ShipVerse I wonder how much I will remember.

Re: The Verse Programming Language [pdf]

#323

Post by DuncanMak »

mikelevins wrote: post #182
stefano_c wrote: post #29

Earlier quoted context omitted.

> - 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. This is similar to how Icon works: https://en.m.wikipedia.org/wiki/Icon_(programming_language)

Yes, I noticed that, too. I used Icon to process a big pile of code at Apple in the late 80s and found it pleasant to work with.

This article seems like a nice overview of the pros and cons of the Icon expression evaluation system:

https://tratt.net/laurie/research/pubs/html/tratt__experienc...

Re: The Verse Programming Language [pdf]

#324

Post by tgbrtjds »

bmn__ wrote: post #283
vcxuhyij wrote: post #242

Earlier quoted context omitted.

The code shown in those images is not in the programming language that is being introduced/created now by SPJ. It is clearly a separate (and not functional) scripting project.

https://nitter.lacontrevoie.fr/pic/orig/media%2FEpeZMhDUwAAY... The screenshot says "BoxFight.verse". Either Unreal has two separate new programming languages both called Verse, or you're plain wrong.

I don't know why I bother, but:

The screenshot you linked to shows boolean variables being defined ("bool") while the new SPJ language being discussed here very conspicuously lacks a boolean type. That fact alone is enough to convince me that there is an "old", less cool, less ambitious Verse language, with different syntax etc. which is about to be replaced by (or as Tim says in tweet, get "converged with") the new SPJ Verse.

They apparently like the name/branding so much that they want to keep using it, even though the fundamental principles of the language are going to be different. That does seem potentially confusing but it's their business. After all, the old verse never got released to the public.

So it seems totally clear to me that a previous, less complex and ambitious, scripting language called "verse", which has been around for a while and never really gone anywhere, is going to be replaced by the new SPJ functional language "verse".

Re: The Verse Programming Language [pdf]

#325

Post by Iceland_jack »

bmitc wrote: post #234
chombier wrote: post #187

Earlier quoted context omitted.

> This is a very funny question, "Why use Comic Sans?" So, all my talks use Comic Sans and I frequently see remarks like 'Simon Peyton-Jones, great talk about Haskell but why did he use Comic Sans?' but nobody's ever been able to tell me what is wrong with it. It's a nice legible font, I like it. So until somebody explains to me ... Ah, I understand that it's meant to be a bit naff, but I don't care about naff stuff,…

He is asking for reasoning when he doesn't provide any, so his use of it is just idiosyncratic and stubborn. It is a noisy language that is hard to read in bulk and takes up a lot of space. It was invented for what was basically a computer game for kids, so why does he insist on using it for presenting technical material? Using fonts beyond their originally designed purpose with no reason is asinine and actually fash…

What's the big deal, using a font outside of its narrowly designed purpose is certainly not it. Some people venture outside the box

Re: The Verse Programming Language [pdf]

#326

Post by gergo_barany »

haliq wrote: post #319
gergo_barany wrote: post #289

Earlier quoted context omitted.

This definitely isn't Prolog, but in some ways it seems to be closer to Prolog than some other things. One thing you can do in Prolog is build partial data structures: `X = tree(Left, Right)` builds a tree node with two "holes" `Left` and `Right` that you can fill in later -- or, crucially, might choose not to fill in. You can pass this "partial" data structure around, and other parts of the program may or may not in…

I think false is sugar for the empty tuple / array. `?` is an operator that turns tuples / arrays back into choices. Thus `false?` can be seen as an expression that returns no values, which is semantically falsy in the language.

Ah, that makes sense. Thanks! It should still not be the default name for this construct.

Re: The Verse Programming Language [pdf]

#327

Post by agumonkey »

auggierose wrote: post #305
bmitc wrote: post #282

Earlier quoted context omitted.

Why does that matter though? No writer does this. Why are programmers obsessed with word length to such a degree?

Writers do something different from programmers. What programmers do is often more akin to mathematics, especially the type of stuff language creators do. And mathematical notation likes to be short.

so much so that I think "differently" in good old car/cdr lisp. even though car/cdr means nothing on any cpu architecture, are cryptic as can be .. they embody the structural inductive step perfectly in my mind. when in clojure or sml I write slower :)

Re: The Verse Programming Language [pdf]

#329

Post by cottenio »

TinkersW wrote: post #316
cottenio wrote: post #262

I think mathematicians are going to love Verse. I'm concerned about hoping "millions" of Metaverse devs will use Verse when, right now, the biggest problems with Metaverse are more about frameworks/netcode than the underlying language. An open framework for handling interpolation, client & server space simulation (w/ physics), forecasting/prediction for events, and handling at least 30 ticks/s for a connection target…

Sweeney commented on twitter "The aim is a transactional programming model with no visible networking or multithreading: you write normal code, and the system distributes the simulation across cores, servers, and servers by running updates speculatively, then committing or aborting them" Seems vaguely similiar to how Unreal networking already works, but I guess more automatic. Some parts of the game will perhaps have…

There comes a point in any massively scaling networking project, and here I speak with some experience, when you realize that your goal, while admirable, has no bearing on the lessons learned over the last few decades of MMO development.

I fear this is a handwave.

What I mean by that is that its addressing the wrong problem for the Metaverse. Being able to implement an ECS model, for instance, where different platforms have common system requirements but because they're both built on Verse they can easily glom/reduce/map components and functions so entities in one ruleset can interact in the other... that's neat, but not a technology problem.

It's a combinatoric problem. And a game design problem.

By the time Verse is built up enough and has enough market penetration to try to take on this sort of role as a bedrock foundation layer for the Metaverse I think we're going to see two major shifts that make it obsolete:

1. The rise of AI-aided design and programming (think ChatGPT on steroids) that makes it pointless to worry about having One Great Solution when the AIs can just interop/translate and all the platforms (even competing corporate interests) can be "Metaversy" with their entities/players.

2. Either the combinatoric problem gets solved or it doesn't. Game designers have strong opinions on NFTs, for instance. The majority recognize them as incapable of solving the item portability problem (or as Raph Koster says, is it even desired?). Either novel ways emerge to do so and it's solvable, or they don't. I suspect either way the heavy lifting is not a programming technology problem, but a contractual/API one.

Re: The Verse Programming Language [pdf]

#330

Post by charcircuit »

chowells wrote: post #306
charcircuit wrote: post #227

Earlier quoted context omitted.

Pattern matching is just syntatic sugar over using booleans and extracting values from data types. This is an exaggerated problem with a cherry picked solution. See what happens when the condition is if a number > 100. Are you expected to convert the integer into a church encoded integer and then write 100 S types? Are you expected to adopt a language with refined or dependent types? Adding a ton of abstractions to f…

Why do you care if a number is greater than 100? That has to actually mean something to you. What does it actually mean? Is it a validation error? Is it a warning trigger? Why not have a data type that actually expresses that meaning? Wait, are you hung up on implementation nonsense? Sure, there's a low-level operation that returns a 0 or 1 that you convert into your actually-meaningful data type. But that doesn't ne…

>Why do you care if a number is greater than 100?

You could make a battle royal game well where people start taking damage when they are 100 units away from the center of the map.

>Why not have a data type that actually expresses that meaning?

It would add unneccessary complexity.

>Wait, are you hung up on implementation nonsense?

The base of what it being abstracted over is not nonsense.

>But that doesn't need to have a surface language boolean type that's privileged by the language design.

If exposing booleans lets people write simpler code then it makes sense to expose it instead of forcing complexity onto everything.

>Boolean is the abstraction.

No, booleans are a concept that the processor understands. Zero is false and nonzero is true. The processor has instructions like like logical and that can operate on these booleans. Branches can happen based off a bit in the status register. A bit has two states which maps to true and false. Booleans are a fundamental concept that is being built upon. The processor has a limited number of data types that it understands. Creating new data types is creating abstractions because those data types do not actually exist. You are simply hiding an actual data type in the new one you are creating.

Post reply on HN