Live data from Hacker News

Introduction to the Pony programming language

opensource.com

21–30 of 77 posts

Re: Introduction to the Pony programming language

#22
post #9

Hi all, In addition to being the submitter, I'm also the author and a member of the Pony core team. I'll check the comments here from time to time and answer what I can.

I understand that its actor model pursues very different ideas from Erlang and is therefore very limited and bare bones, basically allowing only per actor event handlers (behaviors in Pony terms). How does it work in practice, do you use higher order functions to construct basic flows? Like doing something, then entering receive loop for certain messages and making sure no other handler gets called to mess with the s…

Pony's model is different than Erlang's, so trying to think of it in terms of Erlang's model ("entering receive loop") may not be helpful when trying to understand it.

The Pony runtime takes care of scheduling an actor to run when there is a message for that actor. The actor runs through the behavior and then waits to be scheduled again by the runtime when another message is available. If you want to filter messages you need to arrange a way to do that in your code. There's no way to inspect the message queue.

Re: Introduction to the Pony programming language

#23
post #14

Earlier quoted context omitted.

It's better to be wrong and functional than correct and complicated? PS: This is the approach PHP took in the early days too.

BTW, this is the same approach taken by the Coq, Isabelle and Lean theorem provers. In all of them, 1/0 = 0. It is certainly unconventional , but whether this is wrong is a matter of philosophy. Basically, division by zero is undefined, but you can define it to be zero and so extend the definition. This is consistent with the rest of arithmetic. You get more theorems (like for all a, b and c, a/c = b/c), but no incon…

The users of Coq and Isabelle are generally people with mathematics degrees who check their work. Not your average programmer.

Re: Introduction to the Pony programming language

#24

Earlier quoted context omitted.

That's covered in the Pony tutorial. https://tutorial.ponylang.org/gotchas/divide-by-zero.html I can elaborate a bit on what is in the tutorial. With the current semantics, you as the application programmer can check for division by zero and throw `error` if you want. Otherwise, every division operation would be partial which given that pony forces you to handle all partial functions, can get to be very painful. We a…

It's better to be wrong and functional than correct and complicated? PS: This is the approach PHP took in the early days too.

It's an intersting philosophical conversation. Take floating point for example. I just fired up a Python interpreter and did:

>>> 0.3 * 3.0

0.8999999999999999

There's are a lot of areas of computer science that touch on these sorts of problems. And people love to do Wat! talks for all those fun edge cases where how computers work and how programming languages work run up against our expectations of what we expect to be correct.

Re: Introduction to the Pony programming language

#25

Earlier quoted context omitted.

It's better to be wrong and functional than correct and complicated? PS: This is the approach PHP took in the early days too.

It's an intersting philosophical conversation. Take floating point for example. I just fired up a Python interpreter and did: >>> 0.3 * 3.0 0.8999999999999999 There's are a lot of areas of computer science that touch on these sorts of problems. And people love to do Wat! talks for all those fun edge cases where how computers work and how programming languages work run up against our expectations of what we expect to…

[deleted]

Re: Introduction to the Pony programming language

#26
post #22
post #9

Earlier quoted context omitted.

I understand that its actor model pursues very different ideas from Erlang and is therefore very limited and bare bones, basically allowing only per actor event handlers (behaviors in Pony terms). How does it work in practice, do you use higher order functions to construct basic flows? Like doing something, then entering receive loop for certain messages and making sure no other handler gets called to mess with the s…

Pony's model is different than Erlang's, so trying to think of it in terms of Erlang's model ("entering receive loop") may not be helpful when trying to understand it. The Pony runtime takes care of scheduling an actor to run when there is a message for that actor. The actor runs through the behavior and then waits to be scheduled again by the runtime when another message is available. If you want to filter messages…

So kind of like the RabbitMQ worker/message/job dynamic?

Re: Introduction to the Pony programming language

#27

Hi all, In addition to being the submitter, I'm also the author and a member of the Pony core team. I'll check the comments here from time to time and answer what I can.

The website does not show any code in the first or second page. Only a cheatsheet after 3 clicks - which is a pdf.

Re: Introduction to the Pony programming language

#28
post #22
post #9

Earlier quoted context omitted.

I understand that its actor model pursues very different ideas from Erlang and is therefore very limited and bare bones, basically allowing only per actor event handlers (behaviors in Pony terms). How does it work in practice, do you use higher order functions to construct basic flows? Like doing something, then entering receive loop for certain messages and making sure no other handler gets called to mess with the s…

Pony's model is different than Erlang's, so trying to think of it in terms of Erlang's model ("entering receive loop") may not be helpful when trying to understand it. The Pony runtime takes care of scheduling an actor to run when there is a message for that actor. The actor runs through the behavior and then waits to be scheduled again by the runtime when another message is available. If you want to filter messages…

I get it, it's like event driven programming with static event handlers per actor. Where you can't express a wait for a specific message directly in the body of the function. But you still have to do it somehow, which is what my question was about, how do people do it in Pony. Typically in event driven systems to do this either nested callbacks are used or higher order programming (futures/promises, etc).

Re: Introduction to the Pony programming language

#29

Earlier quoted context omitted.

That's covered in the Pony tutorial. https://tutorial.ponylang.org/gotchas/divide-by-zero.html I can elaborate a bit on what is in the tutorial. With the current semantics, you as the application programmer can check for division by zero and throw `error` if you want. Otherwise, every division operation would be partial which given that pony forces you to handle all partial functions, can get to be very painful. We a…

It's better to be wrong and functional than correct and complicated? PS: This is the approach PHP took in the early days too.

It’s not wrong. It’s just a definition issue. The result is undefined in mathematics.

Throwing an error is actually “wrong” as the result should actually be undefined/null but most languages throw for practical reasons.

So in fact it’s most languages that are being “wrong but functional”. Pony is just functioning differently.

Re: Introduction to the Pony programming language

#30
post #22

Earlier quoted context omitted.

Pony's model is different than Erlang's, so trying to think of it in terms of Erlang's model ("entering receive loop") may not be helpful when trying to understand it. The Pony runtime takes care of scheduling an actor to run when there is a message for that actor. The actor runs through the behavior and then waits to be scheduled again by the runtime when another message is available. If you want to filter messages…

So kind of like the RabbitMQ worker/message/job dynamic?

Pony uses a queue for storing messages that have been sent to an actor, so that's probably a reasonable way to start thinking about it. I'm not sure how far I would stretch this comparison, though. :)
Post reply on HN