Live data from Hacker News

Pyret – A language exploring scripting and functional programming

pyret.org

41–50 of 272 posts

Re: Pyret – A language exploring scripting and functional programming

#41
post #2

So, as someone without too much experience in language development, the concept of having unit tests being an extension of the functions themselves seems very interesting. Clearly this doesn't work for all scenarios—multiple functions interacting, any sort of GUI interaction—but that's a very intriguing concept.

I've written a lot of tests using Clojure's with-test, which is slightly less elegant, but the same style:

https://clojuredocs.org/clojure.test/with-test

I've found it wonderful and productive for low-level bits of functionality, especially working on small data structures and primitives. With Emacs set up to reload the namespace and run all the tests on every save, it's a great feedback look with very little cognitive overhead.

It breaks down a bit for more involved tests, as you say, and it can be taxing knowing when to refactor, how much test setup code to include along with the unit under test, and also once you start splitting things into other namespaces, where to look to get a full view of a module's functionality.

Re: Pyret – A language exploring scripting and functional programming

#42

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 method of writing loops with map/filter/foldr.

I have a bias here, as I help teach an introductory course using DrRacket, and many of my colleagues are very aware of Pyret, some even helping to develop it. In one semester, however, we have students with a full understanding of recursion, linked lists, many other common data structures, anonymous functions, functions as data, and understanding of map/filter/fold and how to use them. The class is specifically aimed at people who do not have prior programming skills, and works very well in my experience. Yes, it is a lot, but it builds an incredible base, and if taught to build on itself slowly, is actually very minimal conceptually. The optional features in Pyret are probably allowed with that in mind.

One of its weaknesses, arguably, is that it doesn't look like much else out there in common use, since it's a Scheme. This syntax is an attempt to try and make the same ideas translate to other languages easier, such as Python/Java.

Re: Pyret – A language exploring scripting and functional programming

#43
post #14

Example from the OP: fun to-celsius(f): (f - 32) * (5 / 9) end What's the justification for allowing the use of hyphens/dashes in reference names, when underscores would seemingly provide the same purpose? One of the most common problems I notice in newbie code is inconsistency in using whitespace, e.g. `a-b` vs `a - b`, though in that situation, for Python and virtually every other language I've used, those both res…

Part of the reason whitespace is inconsistent around operators is because nothing about most languages forces you to care. It's a lot like case sensitivity in that regard.

Re: Pyret – A language exploring scripting and functional programming

#45
post #12
post #3

> "while exploring the confluence of scripting and functional programming" Scripting and functional go amazing together, as long as it's (mostly) dynamic typing. In general, types really just get in the way when scripting or prototyping or trying to do anything fast, especially when you don't know the types of data you're going to be working with ahead of time, e.g. when it comes from a file or from an external API,…

> "In general, types really just get in the way when scripting or prototyping or trying to do anything fast" I've found the opposite of that claim to be true. Types are absurdly helpful in prototyping or trying to do anything fast, especially when exploring data coming from a file or an external API. Anecdotes aside, BinTree in the example is both a data type and a type testing function ("detector") of signature `Any…

Types are great unless you are forced to be explicit instead of the compiler doing automated type deduction.

Re: Pyret – A language exploring scripting and functional programming

#46
> Functions can end in a where: clause that holds unit tests for the function. These assertions are checked dynamically.

Wouldn't it be even better to check these statically, such that a program with failing unit tests doesn't even compile?

There may be tests that can't be checked statically, but I think these wouldn't quality as unit tests anyway. (These would be more at the level of integration tests.)

Re: Pyret – A language exploring scripting and functional programming

#47
post #35

No offense but I really don't think it's a good idea to teach beginners a language with such a goofy syntax. It's fine if you want to make a language with a unique and "innovative" syntax. But beginners are best served by learning something mainstream, and ideally simple. They can expand into crazy stuff as they are ready for new languages.

The syntax is the converse of innovative. Standard ML is very old. End keyword telegraphs Pascal and Algol.

About the only new thing here is the testing, documentation and contract support and it is great to have.

Re: Pyret – A language exploring scripting and functional programming

#48
post #2

So, as someone without too much experience in language development, the concept of having unit tests being an extension of the functions themselves seems very interesting. Clearly this doesn't work for all scenarios—multiple functions interacting, any sort of GUI interaction—but that's a very intriguing concept.

I agree

Re: Pyret – A language exploring scripting and functional programming

#50

Unexplained important things: * concurrency, is there any nice built in syntax like Python async? Any kind of threading? Multiprocessing support? * error handling, how is it done? Where are exceptions? * standard and file io, string operations, serialisation? * no builtin higher math types (matrix etc.), is math done on decimal floating point numbers? * foreign functions, interfacing with other languages, embedding?

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 reply on HN