Live data from Hacker News

Introduction to the Pony programming language

opensource.com

61–70 of 77 posts

Re: Introduction to the Pony programming language

#61
post #3

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.

Hi spooneybarger. I'm curious: why is 1/0 == 0? Is it because there is no way to panic/kill the current actor with an error?

BTW, I recently opened an RFC (the way substantial changes to ponylang are introduced and discussed publicly) that introduces partial versions of basic arithmetic operators. The partial division is going to error on division by zero. This would allow the programmer to chose between what kind of behavior is most desirable for the use case.

https://github.com/ponylang/rfcs/blob/partial-arithmetic/tex...

Re: Introduction to the Pony programming language

#62

Earlier quoted context omitted.

Looks like JS crossed with Python (not a bad thing at all)

We've heard the Python comment before, never the JS one. That's a new one to me. What brings JS to mind?

Nothing specific! Just a general impression.

I’m primarily working in JS these days and it felt very familiar and approachable so...

Re: Introduction to the Pony programming language

#63
post #58

Earlier quoted context omitted.

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 .

You are right, but the question is what most programmers want. It is certainly reasonable to believe that most want some special treatment of division by zero. Assuming the program is connected to some actuator (even a screen) -- as most programs are -- while not wrong mathematically, this results in something that is wrong "physically," and doing so silently, without a mechanism to later recover, from the result alo…

Right, though there’s nothing intrinsically better about throwing an error - it’s just the idiom programmers are more familiar with.

If it’s raised and documented well there’s no reason it wouldn’t work as undefined (could throw type errors on usage after that for example).

Re: Introduction to the Pony programming language

#64
post #58

Earlier quoted context omitted.

You are right, but the question is what most programmers want. It is certainly reasonable to believe that most want some special treatment of division by zero. Assuming the program is connected to some actuator (even a screen) -- as most programs are -- while not wrong mathematically, this results in something that is wrong "physically," and doing so silently, without a mechanism to later recover, from the result alo…

Right, though there’s nothing intrinsically better about throwing an error - it’s just the idiom programmers are more familiar with. If it’s raised and documented well there’s no reason it wouldn’t work as undefined (could throw type errors on usage after that for example).

> Right, though there’s nothing intrinsically better about throwing an error - it’s just the idiom programmers are more familiar with.

Well, it can be argued that physics dictates an error is intrinsically better than 0, and that programs care about physics at least as much as about mathematics.

Re: Introduction to the Pony programming language

#65

> it's compiled to efficient native code When people say this, do they mean that it's compiled to assembly? So what's native about it is the instruction set, yes?

"native code" insofar as i've ever seen it, means something "natively understood" by the cpu. the typical alternative is "byte code" which must be interpreted (or jit'd, etc).

Re: Introduction to the Pony programming language

#66

> Pony's reference capabilities and Rust's borrow checker both provide data safety; they just approach it in different ways and have different tradeoffs. Would like to see a summary of what those tradeoffs are. Very curious!

I think one of the core differences that informs a lot of the other trade-offs is Rust has minimal runtime (e.g. no garbage collector, works in bare metal environments), whereas Pony (I think) is willing to have a heavier-weight runtime with garbage collection.

Re: Introduction to the Pony programming language

#67

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.

Since there are no exceptions, in a try-else how can you tell what the error was?

Re: Introduction to the Pony programming language

#68

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.

Since there are no exceptions, in a try-else how can you tell what the error was?

If you need to distinguish between different errors than a union type like (Result | ErrorA | ErrorB) should be used.

Re: Introduction to the Pony programming language

#70

Earlier quoted context omitted.

Since there are no exceptions, in a try-else how can you tell what the error was?

If you need to distinguish between different errors than a union type like (Result | ErrorA | ErrorB) should be used.

I mean like

  try
    if not x() then error end
    if not y() then error end
  else
    // which error happened?
  end
Post reply on HN