Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introduction to the Pony programming language

opensource.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: Introduction to the Pony programming language

#51

Post by sargun »

hellofunk wrote: post #5

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

So, as someone who has only dabbled in Pony, and Rust, I'll try to give an answer. With Rust, you have to fight the borrow checker, and either work out lifetimes manually, or just copy stuff around 'by hand' -- In reality, the whole set of traits to automagically copy stuff around doesn't work. In addition, the mental overhead of Cells, mutable cells, Rcs, and ARCs, is a lot.

Pony normally works out of the box, because quite a bit can just be passed by value. You can pass by reference using reference capabilities, but there's a lot less cognitive overhead there, and a lot less fighting the compiler. I think, in the future, Pony could even derive the capabilities required automagically in many cases.

I'd say the biggest issue is less around safety, but around the I/O, and FFI models.

Re: Introduction to the Pony programming language

#52

Post by kulibali »

Hamcha wrote: post #50
spooneybarger wrote: post #2

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.

Any plans to make the compiler on Windows work with clang/msys rather than Visual Studio? I played with the flags and somehow managed to get an Hello world compiled to .exe, but it would crash upon start. I know it's kind of stupid, but relying on such a huge behemoth was my biggest turnoff.

There's an issue for that: https://github.com/ponylang/ponyc/issues/2079

Also you can use the Visual C++ Build Tools, which is just the compiler without the IDE.

https://github.com/ponylang/ponyc#windows-using-zip-via-bint... http://landinghub.visualstudio.com/visual-cpp-build-tools

Re: Introduction to the Pony programming language

#53

Post by anthonybullard »

spooneybarger wrote: post #49
cobythedog wrote: post #48

Earlier quoted context omitted.

Yep! I suppose I didn't notice the hamburger navigation at the top left.

The tutorial is hosted on Gitbook. I'm finding that it updates very slowly on mobile for me. Even if it isn't broken, it feels broken. Hadn't noticed that as an issue previously.

This is an issue I've noticed with GitBook in general. I think I began to notice it in 5.0

Re: Introduction to the Pony programming language

#54

Post by pron »

OskarS wrote: post #19
pron wrote: post #14

Earlier quoted context omitted.

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…

You'd think that in these kinds of dependent type systems you would have to use the type system to prove that when doing a/b, b is never equal to 0.

Well, designing a language (even a mathematical one) is an art, and you need to trade off measures of convenience. The mathematical axioms that define division by zero to be equal to zero are consistent and so "correct" (if unconventional), and it turns out to be more convenient to define things in this way in those particular formalisms (rather than having to prove each time that you're not zero). You can define different theories in those systems that leave zero outside the domain of division or define it to be some value that means "undefined", but that's how it's done in the default arithmetical theories in those languages (and, BTW, Isabelle/HOL is not based on dependent types; Coq and Lean are). Other proof systems, like TLA+, do it differently.

For a recent discussion about this on the Isabelle mailing list, see here https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2018-Mar... (search for 1/0)

Re: Introduction to the Pony programming language

#55

Post by spooneybarger »

anthonybullard wrote: post #53
spooneybarger wrote: post #49

Earlier quoted context omitted.

The tutorial is hosted on Gitbook. I'm finding that it updates very slowly on mobile for me. Even if it isn't broken, it feels broken. Hadn't noticed that as an issue previously.

This is an issue I've noticed with GitBook in general. I think I began to notice it in 5.0

that's good to know and somewhat depressing.

Re: Introduction to the Pony programming language

#56

Post by kjeetgill »

coldtea wrote: post #7

> "A programming language is just another tool. It's not about syntax. It's not about expressiveness. It's not about paradigms or models. It's about managing hard problems." —Sylvan Clebsch, creator of Pony Well, isn't that a zero content statement? Sure, if you can't help in managing problems (and hard problems) the language is not that good. But I'd argue a language succeeds or fails in helping you manage problems…

My hunch is Sylvan was just trying to moving conversations about Pony language past some of the "shallower" topics that swirl around new languages.

The amount of times new language conversations nitpick c-style semicolons and curly brace blocks, lisp's parentheses, prolog ending statements with a ., or Python's significant whitespace ... It's exhausting. If I never have to read the words "visual line noise" causing "cognitive load" again I'll be happy. It's not that those aren't occasionally interesting but they are over trodden topics.

I've found myself steering conversations like this: "It's not the language it's the runtime!" Whats interesting about erlang, go, and pony are the runtimes. The languages play a role in how they expose those goodies but that's a conversation well beyond whitespace and semicolons.

Re: Introduction to the Pony programming language

#57

Post by pron »

wafflebear wrote: post #23
pron wrote: post #14

Earlier quoted context omitted.

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.

You are correct that the requirements are different, but not exactly for the reasons you mention. Users of those languages use them to prove theorems, and the theorems you get are correct with respect to the arithmetical theory used. Programmers may want some error condition when dividing by zero, because that's what they believe their users expect (say, the program drives some actuator, and bad things may happen if division by zero is not detected). So yeah, the justification for this behavior needs to be different.

Re: Introduction to the Pony programming language

#58

Post by pron »

abritinthebay wrote: post #29
philipwhiuk wrote: post #12

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 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 alone, whether division by zero occurred.

Re: Introduction to the Pony programming language

#60

Post by spooneybarger »

coldtea wrote: post #7

> "A programming language is just another tool. It's not about syntax. It's not about expressiveness. It's not about paradigms or models. It's about managing hard problems." —Sylvan Clebsch, creator of Pony Well, isn't that a zero content statement? Sure, if you can't help in managing problems (and hard problems) the language is not that good. But I'd argue a language succeeds or fails in helping you manage problems…

Context is here: https://www.infoq.com/presentations/pony about 5 minutes in.
Post reply on HN