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

341–350 of 387 posts

Re: The Verse Programming Language [pdf]

#341

Post by chowells »

charcircuit wrote: post #330
chowells wrote: post #306

Earlier quoted context omitted.

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

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

So... You have some meaning there, don't you? Something beyond the values true or false? Does true mean "is safe" or "is taking damage"? Wouldn't something that actually says what you mean be a lot clearer? More direct? Fewer ideas between the expression and the meaning? Less abstract?

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

Why do you think it's more complex to eliminate a semantic step?

Your last paragraph is... very weird. Do you think languages are required to privilege Boolean over any other 2-type, such that only Booleans are allowed to map to those values in machine code? Not every language is as poorly designed as C. You're not wrapping Booleans, you're creating new types which the compiler gives the exact same representation as Booleans get.

And for what it's worth, processors don't understand zero and one. They're mechanistic circuits that operate on combinations of high and low voltages. Zero and one are interpretations added on top of what's going on. If it's easier to think of high voltage as one and low voltage as zero, maybe it's even easier to think of them as "safe" and "taking damage".

Re: The Verse Programming Language [pdf]

#342

Post by charcircuit »

chowells wrote: post #341
charcircuit wrote: post #330

Earlier quoted context omitted.

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

> 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. So... You have some meaning there, don't you? Something beyond the values true or false? Does true mean "is safe" or "is taking damage"? Wouldn't something that actually says what you mean be a lot clearer? More direct? Fewer ideas between the expression and the meaning? Less abstract? >…

>Does true mean "is safe" or "is taking damage"?

You could name a function that returns a boolean isInSafeZone. From the name it would be clear that true means safe and false means that it isn't.

>Wouldn't something that actually says what you mean be a lot clearer

No, compare "if (player.isInSafeZone())" to "if (player.getSafeZoneState() == SafeZoneState.SAFE)". Endure is extra verbosity that isn't giving you value.

>Fewer ideas between the expression and the meaning?

I don't know what you mean by this. You are creating extra types for every possible condition is introducing more ideas. Why have 1000 boolean types when you can have 1 that interopts with itself.

>Why do you think it's more complex to eliminate a semantic step?

There is more steps in creating a new type, maintaining it, and having to convert it into what you want when you could just use booleans from the start.

>Do you think languages are required to privilege Boolean over any other 2-type

No, even C has typedef. I never implied there was wrapping going on. I meant that you are introducing layers of indirection. It's a case of everything in programming can be solved by creating an interaction except having too many indirections. Indirection is not always the answer even if there is no performance impact.

>processors don't understand zero and one

By the interface that is exposed to programmers they do. Read the manual. For the purposes of making a programming language there is no benefit in going down to the level of voltages. It is an implementation detail that is the processor creator's job to worry about.

Re: The Verse Programming Language [pdf]

#343

Post by haliq »

deterministic wrote: post #338
haliq wrote: post #320

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

It is nothing new. See Dependent Types. Used by most formal proof assistants (Coq/LEAN/…) and languages like Agda and Idris. I highly recommend the book “Type Driven Development” if you want a great introduction to the power of DT.

Oh this is new because our notion of expressions; thus functions, are different.

Sure you can have terms in types in dependent types; thus functions in types is nothing new. But again, we have a much different notion of function here.

And if anything I would say types in Verse are much closer to refinement types because of its ability to apply constraints. But they are still not the same thing.

Re: The Verse Programming Language [pdf]

#344

Post by grose »

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…

Thank you for the detailed explanation, much appreciated.

Re: The Verse Programming Language [pdf]

#345

Post by galaxyLogic »

valenterry wrote: post #155
galaxyLogic wrote: post #76

Earlier quoted context omitted.

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

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…

> you can't differentiate between an actual empty array or an error

Empty array in this pattern does not represent an error. It represents the fact that no values you asked for can be found. It is like querying a database. It is not an error if your query finds no values.

The calling code that receives the empty array might decide it is an error or that it is not. And of course you can always throw an error, that can be done with the "throw" keyword.

Getting rid of using nulls by using arrays instead is not about handling errors, but about preventing errors, by changing the semantics of your functions slightly so they never need to return null.

Re: The Verse Programming Language [pdf]

#346

Post by galaxyLogic »

eyelidlessness wrote: post #97
galaxyLogic wrote: post #76

Earlier quoted context omitted.

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

I guess one reason is that it takes more code to return an Array when in most cases what the caller needs is always just a single value. Many such functions never return null so it is overhead to make them return an array.

But returning an array also makes your functions more general. Maybe in the future you want to modify it so that it does return arrays of length > 1. Evolving the program to that state is then easy if you didn't lock yourself into assumption that this function will never ever need to return more than a single value.

Re: The Verse Programming Language [pdf]

#347

Post by galaxyLogic »

lelanthran wrote: post #195
galaxyLogic wrote: post #76

Earlier quoted context omitted.

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

I agree it often makes for more readable code to return a single value instead of an array. But it makes for more maintainable code to return an array.

Whatever you can do with a single value you can also do with an array containing just that single value. How practical that is depends on the language used. In JS after ES6 arrays are syntactically quite nice and easy to use.

Re: The Verse Programming Language [pdf]

#348

Post by galaxyLogic »

schwartzworld wrote: post #337
galaxyLogic wrote: post #76

Earlier quoted context omitted.

> 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 think this pattern is so useful that I've been working on a library to use it for more types of things. https://www.npmjs.com/package/schtate 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.

Keep us posted

Re: The Verse Programming Language [pdf]

#350

Post by justinhj »

Throwaway23459 wrote: post #193
justinhj wrote: post #189

Earlier quoted context omitted.

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.

> [Paraphrasing] Is Verse supposed to be an easy language for beginners ? Yes! Well that was the point of my comment. Maybe you have a different interpretation of 'Learnable as a first language' from the article, which is fine, not interested in arguing about that.

I guess that part of my comment could have benefited from reading the article, which I have done now. Oops.
Post reply on HN