aturley / pony-workshop Goto Github PK

Material for a workshop for learning about the Pony programming language

Pony 100.00%

ponylang workshop actor-model concurrent-programming race-condition-prevention

pony-workshop's Introduction

Pony Workshop

This is the repo for the Pony workshop. There are numbered subdirectories under steps, each of which contains a small program that demonstrates some Pony ideas.

If you are presenting this workshop, please see the README for presenters.

Preparation

Pony is a fast actor-based programming language that guarantees that programs will not have data races. This workshop will teach participants about some of Pony's core ideas and patterns by having them write a series of small programs that culminate in a simple chat server. Topics covered will include Pony's actor system, reference capabilities, and working with the compiler. Attendees should bring a laptop with the following software installed: the Pony compiler via ponyup, and a telnet client. They should also clone the workshop git repository.

Useful Materials

As you work through the parts of this workshop it may be useful to refer to the following sources of information:

pony-workshop's People

Contributors

Stargazers

Watchers

Forkers

aozgaa enixdark tonyle9 i-ky

pony-workshop's Issues

01 - Q3 suggests that local variables could start with a `_` (but they can't?)

; ponyc --pic
Building builtin -> /usr/lib/pony/0.24.3-1/packages/builtin
Building . -> /home/jamesh/a/learn/pony-workshop/steps/01
Error:
/home/jamesh/a/learn/pony-workshop/steps/01/main.pony:3:9: local variable name "_msg" cannot start with underscores
    let _msg = "hello world"
        ^

provide more details about errors

Make it clear that:

must either catch an error or propagate it out of a function
errors cannot escape behaviors

These two points came up when giving the workshop, I'm not sure they're clear from the READMEs.

illustrate methods (functions vs behaviors) better

Talk more about

calling (calling a function and a behavior look the same)
what actually happens (functions use the stack and happen synchronously, behaviors are initiated by putting a message on a queue and the actor gets scheduled and they happen asynchronously)

Should there be a step after step 02 that makes this more clear? Change one of the steps?

link to class documentation

The README files should have links to the online documentation for the classes that are used in the example code. This will make it easier for users to follow along with what is going on.

Workshop in a web browser

There are services offering cloud based development environments, e.g.:

I have some positive experience with the latter one, I can help you configuring it for this repo.

As a result workshop attendees will need to bring laptops with just web browser installed, no need to install ponyc themselves.

show examples of class, actor, primitive early

Have an example that uses classes, actors, and primitives to make the similarities and differences clearer. Probably do this somewhere around step 02.

Possibly related to #6.

Add documentation for the person running the workshop

Document how the workshop should be run so that someone else can do it and not have to make the same mistakes I did.

Include information about preparation (print out copies of the cheat sheet, etc), the order and pacing of parts, important points to emphasize, room requirements to communicate to the hosts, etc.

Consider me pitched

Love the idea of a PITCHME page... never seen that before.
The sections in it are very well written.

Have you considered rearranging them so that “How a Pony Program Works” section is just after “Why Pony”? Someone new to Pony but aware of actors and messages may feel more grounded having that knowledge right away, prior to introducing the rest of the concepts.

Step 2 sometimes doesn't have syntax highlighting

The first example in the readme for the second step doesn't have syntax highlighting.
I assume the problem is that ponyc isn't a valid keyword for syntax highlighting but pony is.

```ponyc

Add suggestions for things to try at the end of each step

There should be a section at the end of the README for each step that suggests things for workshop participants to try.

For example, in a recent workshop someone asked what would happen if instead of String val we used String box in step 02 (since they're both read-only). So I changed the code, we saw the error, and I explained what happened.

This would be useful because controlled "breaking" of the code can be used to reenforce the ideas that are covered in the step.

Add a README.md to the `steps` directory

Right now there's nothing here. There should probably at least be text that describes what you'll learn in each step.