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

311–320 of 387 posts

Re: The Verse Programming Language [pdf]

#311

Post by moloch-hai »

tinco wrote: post #307
moloch-hai wrote: post #304

Earlier quoted context omitted.

The library function is fine, although the long name is unfortunate. The apparatus around applying it, in the example, is aggressively weird.

I agree that the example is crazy. But the function is not fine, it's a testament to how unhinged the C++ standards committee is. Its existence is proof that the problems of C++ are not just with its history, but that it is an ongoing snowball of incompetence and bad decisions.

It is hard to know what you are talking about. It applies linear operators to an input sequence, defaulting to + and x, or whatever you specify. It is like inner_product, but sequence order is not specified.

There is a "range" version in C++20 that in use looks more like in other languages. (It is technically C++23, but appears in libraries shipped with C++20.)

Re: The Verse Programming Language [pdf]

#312

Post by FullyFunctional »

cryptonector wrote: post #292
imtringued wrote: post #232

Earlier quoted context omitted.

It is not a misnomer. You can use generators and backtracking to simulate non determinism. That means the simulator plus non deterministic algorithm are deterministic but the algorithm is not.

The idea in Prolog and such is that you write "goal-seeking code" and it "magically" obtains the correct answer by brute force but without the brute force being syntactically/lexically apparent. But it's still brute force. It's a catchy name, but it's not accurate. It might be more accurate if "simulation" were part of the name.

As presented in the slides it's obvious that it's a generator-paradigm, thus like Icon etc. It's really just a way of making iterators very fundamental in the language. It's deterministic and you are assume to understand that. The "PROLOG style goal searching" is probably less relevant here.

Re: The Verse Programming Language [pdf]

#313

Post by bmitc »

vrotaru wrote: post #303
bmitc wrote: post #218

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

`fst` and `snd` possess a symmetry which `first` / `second` lack Personally I've got used to them like in no time

Why is symmetry in word length needed?

Re: The Verse Programming Language [pdf]

#314

Post by bmitc »

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.

I rather strongly disagree when it comes to programming. Programming is as much communication between humans and domain modeling as it is instructing a computer to do something. Shortening names seems to be a cultural holdover when name length had some real effect or constraint, and now there’s highly subjective and debatable constraints like being shorter, faster to type, length symmetry, etc.

Mathematics uses symbols because there is usually no specific context for an abstract concept, and on other cases it relies on convention to provide context. Shorter names are additionally a side due to the density of information and the ability to write complex symbols on a chalkboard and in LaTeX. The symbols are the meaning and not some shortened version of it.

Re: The Verse Programming Language [pdf]

#315

Post by grumpyprole »

astrange wrote: post #58
grumpyprole wrote: post #33

Earlier quoted context omitted.

Most mainstream programming languages are designed as if we are all targeting 70s von Neumann machines. When applying these languages to e.g. highly distributed or concurrent architectures, they are no longer a good fit. It's great to see at least an attempt at innovation rather than just a Java clone, which is all Google and Microsoft have ever offered so far.

I’ve never seen a program that would magically be better on a distributed architecture if it was written in a different language. Programs run on a single core because they have a single core’s worth of work to do. Autoparallelization, like autovectorization, doesn’t work.

> Autoparallelization, like autovectorization, doesn’t work.

I think concurrency is more of an issue for games and was the example I gave (Haskell's transactional memory for concurrency is a great example of what pure-functional buys you). Nethertheless autoparallism can work, if you again are prepared to accept more constrained declarative languages. Apache Spark is a great example, it offers a constrained functional language with maps and folds, that is autoparallized across a cluster of machines. The research language NESL (nested data parallelism) is even more impressive.

Re: The Verse Programming Language [pdf]

#316

Post by TinkersW »

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 to run outside verse so they can be interpolated/smoothed, unless they have some magic to handle that also.

Re: The Verse Programming Language [pdf]

#317

Post by gergo_barany »

bodhiandphysics wrote: post #293
grose wrote: post #233

Very intriguing! Is there an explanation anywhere of how this is different from Prolog? It seems like almost the same thing. That is not a criticism BTW, I love Prolog. From what I can tell the main difference is it has functions with return values. It also looks like it has different semantics for the choice points, letting you nest alternatives in arguments and other expressions. I do like how choice points are see…

Major differences from Prolog seem to be as follows: Prolog always evaluates through unification (at least in theory). Verse is evaluated through reduction, including the unifications! This means a). there is a sublanguage in verse that doesn't do unification at all... it should have similar performance to a functional programming language like Haskell. b) verse is deterministic... the same prolog programs can at lea…

> Prolog always evaluates through unification (at least in theory).

What do you mean? The actual "computational" part of Prolog lies more in resolution than in unification. Unification does not "evaluate" in any sense of the word I'm familiar with.

> the same prolog programs can at least theoretically produce two different answers to the same input.

What do you mean? Do you mean through side effects, or are you suggesting that Prolog's evaluation order or something else is not fully specified and deterministic? You would be wrong about the latter.

EDIT:

> Verse has a defined denotational semantics

What do you mean? Verse (or rather the underlying calculus VC) has a rewrite semantics. Rewriting is pretty operational and not at all denotational.

Re: The Verse Programming Language [pdf]

#318

Post by mrkeen »

HelloNurse wrote: post #286
mrkeen wrote: post #215

Earlier quoted context omitted.

> Boolean values are inherently a sign of an insufficient data model. Booleans carry no inherent meaning. Would you say the same about Ints or Strings?

Practical language-agnostic example: a database for a business where some VARCHAR(34) columns are IBAN codes and others are messages to be displayed on a 2 by 17 characters LCD screen. They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model. For instance, it should be possible to turn an IBAN in…

> They are two completely different data types that happen to have identical approximate representations but should be distinguished very strictly in a sufficiently expressive model.

About bools: that's my problem with this. If-statements now operate on anything, instead of just bools. And I don't think that makes sense, unless cheese.

About strings: It's great you can statically differentiate between their types. But if strings don't exist, it makes it a little hard to write WHERE clauses.

Re: The Verse Programming Language [pdf]

#319

Post by haliq »

gergo_barany wrote: post #289
grose wrote: post #233

Very intriguing! Is there an explanation anywhere of how this is different from Prolog? It seems like almost the same thing. That is not a criticism BTW, I love Prolog. From what I can tell the main difference is it has functions with return values. It also looks like it has different semantics for the choice points, letting you nest alternatives in arguments and other expressions. I do like how choice points are see…

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.

Re: The Verse Programming Language [pdf]

#320

Post by haliq »

After reading the paper and watching the lecture, I think I know what it means that Types are first class values.

In verse `=` is unification and not assignment or comparison. Meaning its a constraint on the lhs and rhs. Unification is also an expression meaning it can be normalized to a value e.g. `x=3` normalizes to `3`

Expressions can be sequenced with `;` but note this is nothing like imperative programming due to unification. These sequences normalize to the last expression in the sequence but the unifications in all subexpressions apply to the whole sequence. Thus `=` appearing in subexpressions in any order does not change the resulting value (since the compiler uses normalization)

Now functions can be seen as lambdas or anonymous functions to these sequences of expressions where the arguments are also constraints! These functions themselves are values. Thus functions are first class.

Another key aspect of unification is that functions can run backwards. Thus `swap` will return `. But so will `swap(p) = ` constrain `p` to `. Thus the meaning of function is no longer just a procedure. But more of a specification or constraint.

And this is exactly what types are in Verse. Types are functions thus first class. When we say `i : Int` it is akin to saying `Int(i)` constraining the variable `i` based on the constraint `Int`.

Thus if you have a function that succeeds when given an even number, that function can be seen as a type of even numbers.

Post reply on HN