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

291–300 of 387 posts

Re: The Verse Programming Language [pdf]

#291

Post by bmitc »

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

That’s probably a stretch because the study is probably more about the brain being able to fill in if needed rather than it being the same cognitive load. There’s no point in testing the brain in a programming language, and as far as I can tell, programmers are really the only ones that are obsessed with word length. It’s as if authors would just shorten “the” to “th” or “t” since it repeats a lot.

Re: The Verse Programming Language [pdf]

#292

Post by cryptonector »

imtringued wrote: post #232
cryptonector wrote: post #198

Earlier quoted context omitted.

Correct, but "non-determinism" is a misnomer used in programming language theory to refer to generators and pervasive backtracking. Prolog, Icon, jq, etc. -- all fully deterministic, but known as non-deterministic owing to the pervasive generators and backtracking.

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.

Re: The Verse Programming Language [pdf]

#293

Post by bodhiandphysics »

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 least theoretically produce two different answers to the same input. Verse has a defined denotational semantics (prolog has most of a defined operational semantics, but that's a different kind of thing). c). Verse an be type checked at compile time! It seems typechecking verse is undecidable, so presumably some type checks will be moved to run time, but lots of type checking can be done at compile time.

Re: The Verse Programming Language [pdf]

#294

Post by JD557 »

danpalmer wrote: post #267
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 slides need a lot of work. I'll read the paper later, but the slides really lack context and motivation. SPJ is an exceptional public speaker, but that involves a lot of talking, a lot of context, audience participation, and a lot of wild gesticulating at slides. I'm not sure if this talk was recorded, but I am sure if it was the recording will be much better than the slides, the slides are not really designe…

Looks like it just went online: https://youtu.be/832JF1o7Ck8

Re: The Verse Programming Language [pdf]

#295

Post by moloch-hai »

bmitc wrote: post #225
tinco wrote: post #83

Earlier quoted context omitted.

In Python the standard library is fairly easily traversed and understood and if there's a better way of doing something it's usually linked I think. In C++ we have.. this.. https://en.cppreference.com/w/cpp/algorithm/transform_reduce

I know supposedly "harder to learn" languages (i.e., functional languages), but my god does that example and C++ look impenetrable.

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

Re: The Verse Programming Language [pdf]

#296

Post by moloch-hai »

Throwaway23459 wrote: post #103
bibanez wrote: post #74

Earlier quoted context omitted.

In my uni they still teach C++ as a first language, that's why the "don't learn it as a first language" got me confused. The core language is very useful for learning programming, it is actually very clean.

My lecturer in second year, > 20 years ago mind, said we are learning C, because C++ is C with an ugly object oriented graft on top.

Your lecturer did you a disservice; clearly he only knew C, and didn't want to learn any more.

The more your C++ code resembles C, the worse it is.

Re: The Verse Programming Language [pdf]

#297

Post by moloch-hai »

Silhouette wrote: post #106
tinco wrote: post #83

Earlier quoted context omitted.

In Python the standard library is fairly easily traversed and understood and if there's a better way of doing something it's usually linked I think. In C++ we have.. this.. https://en.cppreference.com/w/cpp/algorithm/transform_reduce

Python's standard library includes many modules for specialised applications and yet it's surprisingly lacking in fundamental data structures and algorithms. Personally I think that's the wrong way round. Simple things like building dicts from different data structures or working with optional values that can be something or None just aren't there and you always seem to end up with some kind of utils.py full of hand-…

That example is not how C++ is used. It would not pass code review.

Re: The Verse Programming Language [pdf]

#298

Post by bmitc »

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

Earlier quoted context omitted.

I know supposedly "harder to learn" languages (i.e., functional languages), but my god does that example and C++ look impenetrable.

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.

Re: The Verse Programming Language [pdf]

#299

Post by qayxc »

benji-york wrote: post #268
qayxc wrote: post #77

Earlier quoted context omitted.

I didn't understand "false?" as a NULL value but more of a "Nothing"/"None" in the context of a Maybe monad. Since the language doesn't even have a Boolean equivalent, it makes sense to introduce a value for a failed condition or zero values. The problem with SQL's NULL are its properties (comparison and arithmetic in particular), which doesn't seem to apply here (e.g. "42 + false? === false?, just as with monadic fu…

I don't quite follow the second paragraph. You say > The problem with SQL's NULL are its properties (comparison and arithmetic in particular) [...] Which I follow, then you say that those unfortunate properties don't apply and give a counterexample (I think it is intended as a counterexample) of > 42 + false? === false? But that seems to be the same as SQL's NULL: benji=# \pset null NULL Null display is "NULL". benji…

The problem with SQL is that this behaviour is inconsistent when it comes to NULL values.

Consider a column with values (10, 20, NULL, 30).

In SQL the AVG() function would return 20, i.e. ignoring the NULL value entirely. COUNT(*) on a table, however, would happily include NULL values, whereas COUNT(col_name) wouldn't. The behaviour is all over the place, especially when different dialects and settings are considered.

Re: The Verse Programming Language [pdf]

#300

Post by bodhiandphysics »

dhdgrygev wrote: post #124
frozenlettuce wrote: post #119

Earlier quoted context omitted.

The approach of using a function to describe a type where success is the identity is a very simple way to implement dependant types

But how does it help me implement a gameplay mechanic for the "metaverse"?

Logic programming and games actually go well together... inform (probably the most important text adventure engine) is notably a logic programming language. And many game engines have moved to an architecture in which game assets are represented in a database, and changes to game state are represented as queries on the database (which is canonically what logical programming does).

For instance this might be super mario... mario moves forward or the gumba moves forward or mario hits the gumba and mario enters death animation and the gumba stops or mario hits the gumba from above and the gumba enters death animation or mario hits a coin box and a his coins increase and mario stops and the box enters coin animation.

Post reply on HN