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

251–260 of 387 posts

Re: The Verse Programming Language [pdf]

#251

Post by TuringTest »

bmitc wrote: post #220
rkrzr wrote: 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…

> Perhaps Verse will one day be as influential for PL design as Haskell has been. Has Haskell really been that influential though? It seems to me that MLs, Lisps, Schemes, and even Erlang have been more influential.

Haskell has been enormously influential in the study of types; modern high-level type checkers are built using knowledge from these studies.

Re: The Verse Programming Language [pdf]

#252

Post by TuringTest »

asimpletune wrote: post #244

I was looking at something and wasn't sure if I understood it. There's this part of verse: x:int; y:int; if (x=0) then y=1 else y=2; x=7; y Ok, so here, y=2. And then it goes on to say that the equal operator within a "conditional scrutinee" is "rigid" and can only be read, not unified. Does that mean if we take out the "x=7;" line, and then evaluate "y", that "y=(2|7)"? Or how exactly does that evaluate?

I would expect "y" to remain unbound, as in "not enough information".

When evaluated, the "if" expression is added to the "knowledge store", so that it will be evaluated when "x" is bound elsewhere, giving "y" the corresponding value (just "1" or just "2", never "(1|2)") only after that.

P.S. See the definition of the "amb" operator in typical logic programming languages:

https://rosettacode.org/wiki/Amb

Re: The Verse Programming Language [pdf]

#253

Post by dan-robertson »

cmrdporcupine wrote: post #94
dan-robertson wrote: post #86

Earlier quoted context omitted.

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.

I think one must squint a lot to see Julia as a fortress descendant. They seem much more like siblings trying to solve similar problems. Like fortress, Julia does have a reasonable amount of CL/Dylan ancestry with multimethods, etc, but didn’t try any of the fortress style efforts around typeclasses and writing varied code that magically parallelises – you can still get good perf doing typical vectorised stuff like numpy/APL/R, and you get decent perf in loops etc due to the jit and aggressive monomorphisation, and there is fancy stuff for clusters or gpu arrays, but it doesn’t try to achieve the things fortress wanted like making it easy to write code that can be more magically parallelised.

Re: The Verse Programming Language [pdf]

#254

Post by auggierose »

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…

If you rename `fst` to `first`, then `snd` becomes `second`, which is much much (much!) longer.

Re: The Verse Programming Language [pdf]

#255

Post by dan-robertson »

WillPostForFood wrote: post #114
dan-robertson wrote: post #86

Earlier quoted context omitted.

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

This doesn’t strike me as a very serious attempt to predict the future and design a programming language based on that prediction I don't think it is trying to predict, it is purpose built to be the Unreal engine scripting language. I hate the word metaverse, but it will be a highly relevant, important language to online multiplayer worlds as soon as it is released (as soon as a month from now).

The implication of the argument that the above comment was responding to was that the design of the language was driven by predictions for what the metaverse would be like and what that would imply about the needs of a programming language. I agree that the OP doesn’t seem to really try to predict that. I’m sceptical that a language like this will catch on in Unreal but maybe if that is the motivating use-case it will drive some interesting and practical language features. Will have to wait and see.

Re: The Verse Programming Language [pdf]

#256

Post by auggierose »

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…

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

Re: The Verse Programming Language [pdf]

#257

Post by cmrdporcupine »

dan-robertson wrote: post #253
cmrdporcupine wrote: post #94

Earlier quoted context omitted.

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.

I think one must squint a lot to see Julia as a fortress descendant. They seem much more like siblings trying to solve similar problems. Like fortress, Julia does have a reasonable amount of CL/Dylan ancestry with multimethods, etc, but didn’t try any of the fortress style efforts around typeclasses and writing varied code that magically parallelises – you can still get good perf doing typical vectorised stuff like n…

I think in the constellation of languages there's still more intersection of "feature dots" between the two than there is disjunction. Multimethods & numerics emphasis alone makes them uniquely similar, as the latter especially is not a feature that has been mined well in other languages.

Some of the influence is quite conscious, too, from my reading. Though as you mention is obviously a lot of common influence from Dylan and Common Lisp.

And here's a talk by Guy Steele about the Fortress experience, at JuliaCon:

https://www.youtube.com/watch?v=EZD3Scuv02g

Re: The Verse Programming Language [pdf]

#258

Post by _0w8t »

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…

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.

Re: The Verse Programming Language [pdf]

#259

Post by epolanski »

_0w8t wrote: post #258
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…

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.

It's still mental overhead for a subset of users, thus an unnecessary shortening.

Re: The Verse Programming Language [pdf]

#260

Post by TuringTest »

nurettin wrote: post #179
davidw wrote: 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 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:

https://rosettacode.org/wiki/Amb

Post reply on HN