1. 24

General overview with code samples of the Pony programming language

  1.  

  2. 7

    Seems like a pretty language. The whole anything divided by zero is zero thing means it’s probably not great for anything math heavy as it will pave over legitimate errors.

    1. 7

      That seems like such a bizarre design decision - I wonder what motivated it. It’s definitely something that would’ve caught me off guard.

      1. 3

        Division by zero should at least be inf if not going to be an error :P

        1. 2

          You could easily define a division function that checks if you’re dividing by zero and emits an “exception”. (I put it in quotes because exceptions must be handled in at some point in the stack.)

          So I guess if you want to do heavy math you’d do that?

          1. 2

            The official tutorial has a “gotcha” page for division by zero that explains their thinking a bit. It originally used a partial function that would throw an exception if you divided by zero. They later changed it to a total function that returns zero in the case of division by zero.

            From a mathematical standpoint, it is very much insane. From a practical standpoint, it is very much not.

            From a practical perspective, having division as a partial function is awful. You end up with code littered with trys attempting to deal with the possibility of division by zero. Even if you had asserted that your denominator was not zero, you’d still need to protect against divide by zero because, at this time, the compiler can’t detect that value dependent typing.

            Here’s a recent discussion on Reddit of this decision.

            To me it seems like the language makes you do something with all possible errors but when it came to actually programming that way, the authors found it exhausting. There are a lot of people that find Go’s error handling or Swift’s optional handling similarly tiresome.

            1. 2

              Oh geez, this really grinds my gears. I’m trying not to be nasty about this, but the only explanation of this is in a sentence that’s not finished:

              Even if you had asserted that your denominator was not zero, you’d still need to protect against divide by zero because, at this time, the compiler can’t detect that value dependent typing.

              It’s literally “blah blah dependent typing”!

              I’m sure that they can correct this sentence to at least be grammatically correct. However, the more serious error is a philosophical one.

              I call this “the map is not the territory”, which is an old idea in philosophy [1]. The type system is a MAP to the territory. The territory is your PROGRAM – i.e. its runtime behavior.

              The map is supposed to HELP you with your program. In this case, they’ve got it precisely backwards: the map is making your program wrong.

              You should not make your program wrong to satisfy the type system. That’s like demolishing a house because someone misprinted a map of your town. No – somewhere lives there and there are real world consequences to it.

              Also, somebody else mentioned stack overflow and heap allocation failures on Reddit, which are two other things that can happen everywhere (at least in C programs).

              [1] https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation

              1. 1

                Couldn’t there be an option for the compiler inserting the checks automatically with it crashing and dumping the state into a log on a divide by zero? Anything that keeps it from running and running with potentially-bogus data.

              2. 1

                I think it’s an interesting idea. I wonder whether a separate coalescing division operator would be good? Or, have pony have its semantics for division by zero but supply a separate operator for traditional semantics.

              3. 6

                I’ve been playing with Pony a bit over the last few weeks. I think it’s an above average language, but somethings about the language which grinds my gears:

                • I don’t understand why it has classes and actors. Why two ways to manage state?
                • I don’t like that a + b is syntactic sugar for a.add(b). That means I have to know a lot of information to understand if a + b is the same as b + a. (which is already not true for strings because + is abused for concat. I understand a lot of people are used to this and have come to terms with it, but my mind really does not like this. I does not make sense to me that the binary operator you get is the one associated with the left object, it seems so arbitrary and confusing.
                • I wish it had free-functions. Even in a lot of the code examples, it’s really unclear what value classes are offering.
                • I don’t understand why it has these special constructor function (designated with the new keyword). I think a regular function that just allocated an object would have made more sense. But I understand ctor’s that run code is a common thing in OO, I just think it’s stupid because in every OO language I’ve used it’s considered bad practice to do anything other than just assign data.

                That being said, Pony does have some really cool features. In particular, things I like about it are:

                • The type system is trying new things, particularly with capabilities.
                • It really values being correct.
                • It produces binaries. I really like binaries. As much as I love Erlang, I find deploying it annoying.
                • It’s trying to stay small and tight.
                • It’s clear about it’s design philosophy (get-stuff-done).
                1. 4

                  Beautifully designed!

                  1. 4

                    Nice language, but despite the explanation I obtained recently over irc, its error management still seems unsafe to me.

                    The problem is that since errors do not carry any value, the programmer must be careful to ensure each partial function can only fail for one reason. The compiler does not enforce this, but if it happens, the caller cannot know what went wrong (and will probably manage the error incorrectly).

                    This design of errors has clear performance advantages in some use case, but it seems to risk safety for performance.

                    The only workaround I see for this is to always surround each partial function with a try/else, effectively ensuring that (iff the partial function is actually failing for a single reason) you can identify such reason and react accordingly. But since the compiler does not enforce you to do that you have to trust your diligence.

                      1. 3

                        If i understood your question correctly, then yes.

                        Here is a simplistic example: http://playground.ponylang.org/?gist=7736a05aadb95c7d4d070ab54e2891de