Pyret – A language exploring scripting and functional programming

Post by davexunit » Thu, Dec 15, 2016, 6:17 PM UTC

AstralStorm wrote: post #50

davexunit wrote: post #40

Earlier quoted context omitted.

Judging from the red/blue colors in the logo and that the website was generated with Frog, I assume that once you feel too big for Pyret's shoes you'll discover that you've actually been using Racket all along and will start using the Racket language directly.

But why? Best languages are truly general. This should aim to replace Racket, not be bait for a switch.

Post by emidln » Thu, Dec 15, 2016, 6:20 PM UTC

adjkant wrote: post #42

mattangriffel wrote: post #4

As someone who teaches coding to beginners for a living (I founded One Month and I teach Python to business students at Columbia University), this language looks really intimidating to beginners. Maybe Pyret isn't for beginners, and it's intended to teach people who already have some basic knowledge more advanced concepts like functional programming. That's fine. But to a total beginner, the syntax of Pyret is defini…

Pyret is inspired from Racket, which starts at step 1 with functional programming. It's not about readability or getting people to learn as fast as possible to write basic code, but to try and teach core program design principles easily and build a solid base within a single semester. The syntax is not as clean as Python, but it offers much more clarity in terms of testing, signatures, and offers a very interesting m…

    (define (sum a b) : [-> Integer Integer Integer]
      (where (= (sum 0 1) 1)
             (= (sum 2 2) 4))
      (+ a b))

Post by jpolitz » Thu, Dec 15, 2016, 6:21 PM UTC

AbrahamParangi wrote: post #51

I strongly believe that people who are learning to program should learn in a language that can actually be used to make things. This may run counter to the 'work smarter, not harder' ethos I see here but I feel that programming competency in practice is much more a function of literal hours writing code than any other factor.* *with the caveat that competency tends to follow a sub-linear growth curve and people vary…

Post by throw_again99 » Thu, Dec 15, 2016, 6:23 PM UTC

mkolosick wrote: post #39

throwaway009912 wrote: post #30

Earlier quoted context omitted.

I was also surprised. The syntax they use is basically Standard ML. Also I'd really like to see a paper on their static type checking, because they mix objects and algebraic data types, which is not trivial at all.

Hi, I'm actually the person who wrote the static type checker. Essentially we get around the difficulties of mixing objects and ADTs by having very limited support for subtyping. This way we can still carry out unification-based inference. The subtyping bounds are not propagated during unification so we don't need to worry about calculating closures. This does mean that type inference is incomplete with respect to su…

  data Animal:
    | elephant(name, weight)
    | tiger(name, stripes)
    | horse(name, races-won)
    ...
  end

  fun animal-name(a :: Animal):
    a.name
  end

Post by AstralStorm » Thu, Dec 15, 2016, 6:25 PM UTC

sdx23 wrote: post #60

mattangriffel wrote: post #4

As someone who teaches coding to beginners for a living (I founded One Month and I teach Python to business students at Columbia University), this language looks really intimidating to beginners. Maybe Pyret isn't for beginners, and it's intended to teach people who already have some basic knowledge more advanced concepts like functional programming. That's fine. But to a total beginner, the syntax of Pyret is defini…

In what world is: def square(n): return n * n ... easier for a beginner to understand than: square n = n * n