17 ms·

Pyret – A language exploring scripting and functional programming

306 points by gknoy 10y ago

gr3yh47 10y ago
Honestly imo Python is the best language to start with for learning. It has all the basic constructs of both functional and object oriented programming in plain english without a bunch of syntax to worry about. I personally think it's the most readable language. it's also quite intuitive imo. Lastly, there's a fantastic community and instant help is available for all skill levels but especially beginners on #python on freenode irc Pyret... isnt very readable, doesnt seem very intuitive, has somewhat odd syntax, and generally seems like a terrible choice for learning. Doubt it has the resources quality python has (community, docs, tutorials) i dont get it.
- AstralStorm 10y ago
  Isn't readable? It has mostly Python syntax. Some bits inspired by Standard ML, Ocaml, F# and Haskell. Nothing odd here. End marker prevents accidental scope overrun and is from Pascal I think. Community is hard to get for any new language. If this got popular, there would be no such problems. You're arguing that Python is Good Enough. But then, so was assembly.
- posterboy 10y ago
  >has somewhat odd syntax says the programmer using significant whitespace runs for cover
- jpolitz 10y ago
  The readability, unintuitive, and "odd syntax" comments are somewhat subjective, though I'd curious to hear what parts are odd and unintuitive for you. I linked to a perspective on where Pyret fits in in another similar answer: https://news.ycombinator.com/item?id=13187379 https://news.ycombinator.com/item?id=13187379 We also may have different definitions of what a "beginner" needs for community and help. Pyret is used in middle and high school classes (along with the undergraduate level). Those students, nor their teachers, are likely to know what IRC is or how to seek help on it. We do a lot of curriculum development, and professional development workshops in the summer are a major way we interact with these teachers and set them up with a high-bandwidth way to communicate with us over the year (which is direct email or mailing lists). Prompt and detailed help is certainly available for teachers (who then help their students), and it's coming from the folks who designed the curriculum and the language together. Those mailing lists are public (pyret-discuss [1] and bootstrap-teachers [2]), and anyone is welcome to ask away. [1] https://groups.google.com/forum/#!forum/pyret-discuss https://groups.google.com/forum/#!forum/pyret-discuss [2] https://groups.google.com/forum/#!forum/bootstrap-discuss https://groups.google.com/forum/#!forum/bootstrap-discuss Of course, Pyret doesn't have the huge community, Stack Overflow presence, documentation maturity, etc. of Python (or other major languages) for general programming. That takes time and consistent effort, but the lack of it doesn't negate the reasons Pyret is good for its current use cases.
- zem 10y ago
  i think the pyret syntax is wonderful, personally. it takes a lot of good bits from my two favourite languages, ruby and ocaml, and blends them into a nicely coherent whole. there are a few minor things i'd probably have done differently, but on the whole i find pyret code very pleasant to read.
  - a0 10y ago
    > there are a few minor things i'd probably have done differently, but on the whole i find pyret code very pleasant to read. Curious to know what would you have done differently. I'm working on a programming language based on OCaml with Ruby-like syntax.
    - zem 10y ago
      just bikesheddy stuff like * |> rather than ^ for the pipe operator (more consistent with several other languages) * [list| 1, 2, 3] rather than [list: 1, 2, 3] (just for better visual distinction, though the current syntax does look pretty clean and uncluttered) * having a separate code block for methods of individual variants rather than interspersing them with data definitions (because i think it's important that the basic data definition be as uncluttered as possible) if you'd like some syntax feedback on your language i'd be happy to take a peek :)
      - skrishnamurthi 10y ago
        I'd disagree with the second one. `[list: 1, 2, 3]` reads more like in English: "I'm going to define a list: one, two, three…". Whereas `[list| 1, 2, 3]` has no obvious vocalization. (Vocalization is an important characteristic for us; it's how `ask` came to have its syntax.) In addition, we usually use `|` in programming languages in a separator kind of way (even `||` for "or" separates expressions), which it's certainly not in the list expression.
        zem 10y ago
        "list where the elements are 1, 2, 3", by analogy with set builder notation or list comprehensions :) but i agree the current one reads better as english. it's the separator aspect i was getting at with my proposal though - visually it's [ datatype | elements ] whereas the current one looks more like the colon is part of the first element - [(list : 1), 2, 3]
- skrishnamurthi 10y ago
  No, Python doesn't actually have a lot of things you need in education. See https://news.ycombinator.com/item?id=13189513 https://news.ycombinator.com/item?id=13189513
hajderr 10y ago
"We need better languages for introductory computing." and "One of the enduring lessons from the Racket project is that no full-blown, general-purpose programming language is particularly appropriate for introductory education." Well not really, we need better teachers and methods for teaching programming and computing. A good language on its own is not gonna lift the interest.
- jswrenn 10y ago
  > Well not really, we need better teachers and methods for teaching programming and computing. I think most of the Pyret developers would agree wholeheartedly! To this end, the Pyret development team works closely (and in some cases, overlaps) with Bootstrap [1], a nation-wide program to teach programming to middle school students. The feedback we get from these teachers (and the process of teaching teachers) directly informs language design. Furthermore, at Brown University, where many of Pyret's developers have ties, Pyret is dogfooded on two courses: an "Accelerated Introduction to Computer Science" [2] and "Programming Languages" [3]. (Disclosure: I am a developer of Pyret.) [1] http://www.bootstrapworld.org/ http://www.bootstrapworld.org/ [2] https://cs.brown.edu/courses/cs019/2016/ https://cs.brown.edu/courses/cs019/2016/ [3] https://cs.brown.edu/courses/cs173/2016/ https://cs.brown.edu/courses/cs173/2016/
  - webwanderings 10y ago
    Is there a good quality MOOC on Pyret? I am not in high school but am not a programmer either. I started using DrRacket MOOC fairly recently on Edx and had no idea about Pyret until today. My interest in finding good quality teaching, led me to Racket, all the way from the hype of Python/Ruby, and anyone else in between. I am trying to follow Racket but now I am confused between Racket and Pyret.
    - jpolitz 10y ago
      There is no MOOC I know of that uses Pyret (yet). Racket is great! If you're already deep into Racket, I wouldn't say stop to try Pyret unless you particularly have the goal of learning more languages, or there's something about Pyret that really gets you interested. We taught a programming languages course that uses Racket back in 2012, but all the material is still online: https://cs.brown.edu/courses/cs173/2012/ https://cs.brown.edu/courses/cs173/2012/ So if you're looking for online content that we recommend, that could be an interesting next step that makes use of the momentum you have in following Racket. The Pyret book PAPL is free online, and it's possible to dive in and follow that if you're curious about learning Pyret, though it doesn't have the infrastructure of assignments with autograders, etc, that a MOOC would have: http://papl.cs.brown.edu/2015/ http://papl.cs.brown.edu/2015/
eykanal 10y ago
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.
- dexwiz 10y ago
  Agreed. It probably helps enforce pure functions, which are one of the big pros touted about functional programming. Ideally most functions should be pure and isolatable from the rest of the program.
- jstimpfle 10y ago
  Is there something that prevents you from making functions that only check how other functions interact?
  - eykanal 10y ago
    No, not at all. The point is that there's specific syntax in the language for making this part of the function definition, as it were. New concept for me.
  - Avshalom 10y ago
    Scoping rules probably get in the way in some cases.
  - deleted 10y ago
    [deleted]
- Jtsummers 10y ago
  They have a check clause which is detached from the functions themselves. This is where they would want you to do tests with multiple functions interacting.
- thom 10y ago
  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 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.
sdegutis 10y ago
> "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, etc. But what is BinTree in the following example on the website? Is it a type? Is it a function, or constructor, or what? I'm confused. data BinTree: | leaf | node(value, left, right) end
- dexwiz 10y ago
  Pretty sure its a union type.
  - AstralStorm 10y ago
    Tagged union type, so no casting.
- xearl 10y ago
  > "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 -> Bool`. See http://www.pyret.org/docs/latest/Declarations.html#%28part._s~3adata-decl%29 http://www.pyret.org/docs/latest/Declarations.html#%28part._... for details.
  - AstralStorm 10y ago
    Types are great unless you are forced to be explicit instead of the compiler doing automated type deduction.
- Jtsummers 10y ago
  My intuition from other languages is that it's a type and a set of constructors. leaf constructs an instance of type BinTree, as does node(4, leaf, leaf). This also matches how it's used in the where clause. The documentation seems to verify my intuition: http://www.pyret.org/docs/latest/A_Tour_of_Pyret.html#%28part._.Data%29 http://www.pyret.org/docs/latest/A_Tour_of_Pyret.html#%28par...
mattangriffel 10y ago
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 definitely a step back in terms of readability. In what world is: fun square(n :: Number) -> Number: n * n end ...easier for a beginner to understand than: def square(n): return n * n I get that the intention of this language seems to be to help beginners avoid some of the more common pitfalls that they may run into (ex. unexpected parameters and return values), but it seems like they do it at the expense of the total beginner's ability to understand and keep track of lots of new concepts when they're just starting out.
- makmanalp 10y ago
  Annotations are optional. This is equally valid: fun square(n): n * n end Not that different after all! And I say this as a lover of python and significant whitespace, but not having it at first would be easier.
  - lmm 10y ago
    "def" is an abbreviation non-programmers are more likely to understand than "fun".
    - AstralStorm 10y ago
      But that's no fun. ;-) Seriously, fun is obvious for function to anyone. (also, defun in some other languages fits the bill) In contrast, def doesn't explain what is defined. (See Groovy where it is a real problem or JavaScript where you can use var for everything.)
      - lmm 10y ago
        > In contrast, def doesn't explain what is defined. (See Groovy where it is a real problem or JavaScript where you can use var for everything.) Does that matter? I'm used to Scala where `def x = 4` is just as good as `val x = 4` as far as a beginner's concerned.
makmanalp 10y ago
Yarr! Pyret always seemed like a great idea to me. It's still quite-scheme-y, and so can introduce functional programming ideas easily, without the hangups people normally have about syntax. It also has minimal weird-language-cruft that is hard to explain to beginners, that you'd normally have to be like "ok ignore the int argc, char argv for now". And it runs in the browser. Awesome. Can't wait to get a chance to dig in further. Also, try code samples in here: https://code.pyret.org/editor https://code.pyret.org/editor Also, scroll down to see the comparison vs other languages: http://www.pyret.org/#examples http://www.pyret.org/#examples
Insanity 10y ago
The annoying banner was distracting from the actual content unfortunatenly. From what I did see I don't see a reason to start using it in education to be honest. I don't see the problem with just teaching Java or Python. Sure it might be a bit harder, but it's what you'll end up using in the real world
- skrishnamurthi 10y ago
  https://news.ycombinator.com/edit?id=13189513 https://news.ycombinator.com/edit?id=13189513
danso 10y ago
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 result in subtracting b from a. But in Pyret, it seems that `a-b` would be interpreted as a reference? That seems needlessly confusing for no benefit in readability over using snakecase. Beginners frequently have issues with grammar, that is, they are pretty much unaware of it when trying to figure out the many other things they have to learn about programming. Even in SQL, I forget that it must be quite confusing for beginners to parse out the meaning of the `` in something as simple as: SELECT mytable.*, (a * b) AS myproduct, COUNT(*) AS the count FROM mytable ... Doesn't seem worth it to make the hyphen, which is so frequently associated with subtraction and negative numbers, have just a decorative meaning when used between word tokens (as opposed to subtraction of values represented by variables).
- juliendorra 10y ago
  On the other end, I love that Calca (mac and iPhone app and language) allows to use spaces in function or variable names. It's so natural.
- jswrenn 10y ago
  Pyret inherits hyphens-in-identifiers from Scheme/Racket. One of Pyret's largest users, Bootstrap [1], has long-used a dialect of Scheme, and has recently introduced a curriculum that uses Pyret. For these users, "virtually every other language" allows for hyphens in identifiers. Scheme mitigates the spacing issue with s-expressions. Pyret attempts to mitigate it by enforcing that operators should be separated from their operand with at least one space. (Disclosure: I am an occasional developer of Pyret.) [1] http://www.bootstrapworld.org/ http://www.bootstrapworld.org/
  - eridius 10y ago
    Scheme and Racket are both LISPs, with very different syntax. Hyphens in identifiers aren't a hazard, because binary operators don't go between two other identifiers, and operators must be separated with spaces, e.g. subtraction looks like `(- 2 1)` instead of `2 - 1`. This means that using hyphens in identifiers is quite safe. But Pyret is using more traditional syntax, where binary operators go between their operands, e.g. `2 - 1`, which means using hyphens in identifiers is a hazard as the parent comment describes.
reacweb 10y ago
When I was student, my favorite language syntax was Caml, the ancestor of OCaml. I am surprise there was comparison with many languages but not OCaml.
- throwaway009912 10y ago
  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.
  - mkolosick 10y ago
    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 subtyping, but I haven't found a satisfactory system that would let us do otherwise. I would also like to note that we do also have a new feature where types can be inferred if you provide tests in a "where:" block attached to a function. This infers a function's type solely from the examples of usage provided. If you have any other questions feel free to ask!
    - throw_again99 10y ago
      Hi, thanks. Primarily I wondered about actual mixing of ADTs and objects, which is limited even in OCaml, see e.g.: http://caml.inria.fr/pub/ml-archives/caml-list/2003/06/bed2822602ed37484c166cef1d57f7be.en.html http://caml.inria.fr/pub/ml-archives/caml-list/2003/06/bed28... But does Pyret always translate an ADT to a class hierarchy behind the scenes? This example sure looks like it does: data Animal: | elephant(name, weight) | tiger(name, stripes) | horse(name, races-won) ... end fun animal-name(a :: Animal): a.name end
      - 10y ago
romanovcode 10y ago
> Pyret is a programming language designed to serve as an outstanding choice for programming education For me these examples look super complicated.
- jpolitz 10y ago
  Thanks for the feedback – we've gotten this a few times, and I think the homepage is targeted too much towards getting across Pyret's design to an already multi-lingual audience, and not enough towards actual beginner uses of the language (of which we have many). This is something we're working on changing to make it easier to see what true beginner examples look like.
rogerbinns 10y ago
I'm somewhat confused by the indentation rules. Is this code valid? fun abc(d): d+1 end
- jswrenn 10y ago
  Yes, Pyret is totally indentation-insensitive.
  - skrishnamurthi 10y ago
    FOR NOW. We have a plan for making the indentation checked but it's not been our top priority, but it is on our stack. Languages take a while to cook. Welcome to the kitchen. (-:
    - rogerbinns 10y ago
      I must admit to being a fan of the python approach. My example code above is obviously "wrong", and is immediately so in Python. In other languages it is valid, and then brings a burden for a reader of trying to determine why the indentation doesn't match the intent. Since code is read a lot more than it is written, that seems like pointless complications for no real benefit.
      - skrishnamurthi 10y ago
        You're conflating two things. Indentation can be enforced without being semantic. In Python, indentation is semantic: if you move certain statements two lines out, you've changed the meaning of the program. In Pyret, our goal is to enforce indentation but never make it semantic: i.e., there's an unambiguous place for every bit of code. You can select-all and hit Tab in the Pyret editor and it'll reindent your whole program according to the rules. We just haven't yet implemented the checker for these rules (in part because we still don't all agree on exactly what they will be). Once we agree, the program you wrote would be a syntax error, but a user could have the system automatically indent it for them to make it right. (Even now, they can have the line be automatically indented for them.)
AstralStorm 10y ago
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?
- davexunit 10y ago
  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.
  - AstralStorm 10y ago
    But why? Best languages are truly general. This should aim to replace Racket, not be bait for a switch.
    - baldfat 10y ago
      Racket is both a programming language and a framework for building programming languages. http://queue.acm.org/detail.cfm?id=2068896 http://queue.acm.org/detail.cfm?id=2068896 Racket is the most fun I have had in Programming and the more I "get it" the more I enjoy it. I can't say that for any other language.
    - davexunit 10y ago
      Racket is a platform for running many languages. It's different than the usual "one language for everything!" mantra. You can Pyret for one part of a program, Racket for another, Typed Racket for another, etc.
  - baldfat 10y ago
    http://www.pyret.org/pyret-code/ http://www.pyret.org/pyret-code/ > One of the enduring lessons from the Racket project is that no full-blown, general-purpose programming language is particularly appropriate for introductory education. By the time a language grows to be useful for building large-scale systems, it tends to have accumulated too many warts, odd corners, and complex features, all of which trip up students. The journal paper for DrScheme (the old name for DrRacket) explains this in some detail. In that respect, the closest fellow travelers of us Pyreteers are the Racketeers (see how that works?). In fact, the first version of Pyret was merely a #lang in Racket. Nevertheless, Pyret represents a departure from Racket (for now and for the near future, at least) for several reasons:
kofejnik 10y ago
tbh, it looks like ruby with minor changes
- AstralStorm 10y ago
  It is quite different syntax from Ruby.
phkahler 10y ago
What's the point? One would hope they start with a description of why this is better for education than something like Python. I just gave it a quick glance, and it looks like many other programming languages - a bunch of odd text gibberish. I don't think the problem dividing people into "gets it" and "doesn't get it" has anything to do with nuances in syntax or semantics.
- steego 10y ago
  Despite what the down voters think, I actually found this comment useful because I had the exact opposite reaction. I took a quick look at the examples, saw familiar syntax and features and quickly concluded it looks like a nice toy, but I'd probably never use it because there are way too many unknowns (Performance, runtime, buggy, etc. etc.). I was actually a little flabbergasted when you said it looked like "odd text gibberish", but then I took another look at the the first example and saw it. data BinTree: | leaf | node(value, left, right) end Unless I'm familiar with union types, what part of that code tells me this is a parameterized enum? Why should I assume we're even talking about data types? I'm relatively flexible when it comes to syntax, but clearly syntax is a huge hurdle that almost always gets in the way of adoption. I understand Pyret isn't looking to be the next Python, but for an educational language I would argue it's not living up to Python's Principle of Least Surprise. It's great if you know Haskell, OCaml, Python and other languages, but it's not so great if you're an unsuspecting student who's sharpened your teeth on Java/Python. I suspect most people could pick up the syntax pretty quickly, but I suspect most people still need some hand-holding on the first page. Most programmers still don't know what this short paragraph means: Pyret allows for concise, expressive, recursive data declarations. Type annotations are optional and can be added incrementally, to serve a variety of pedagogic styles and curricular needs.
  - skrishnamurthi 10y ago
    It isn't designed to be for student who have “sharpened” their teeth on Java or Python. Nor does it claim to be. And that paragraph you quote is written for educators, not for students.
  - 10y ago
ebbv 10y ago
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.
- AstralStorm 10y ago
  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.
- Ericson2314 10y ago
  These comments surprise my so much. Pyret is designed to have as much of a familiar scripty-looking syntax as is possible while not being a shit language. Just like Rust has lousy C-like syntax to not alienate that crowd.
vog 10y ago
> 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.)
- skrishnamurthi 10y ago
  Tests are, by definition, checked dynamically. And setting aside terminology, there's a small issue called the Halting Problem that makes most tests unable to be checked statically.
gre 10y ago
The docs at http://www.pyret.org/docs/latest/ http://www.pyret.org/docs/latest/ link to the outdated book. Update the link?
- skrishnamurthi 10y ago
  Yes, thanks. We weren't expecting to end up on HN today. (-:
- jpolitz 10y ago
  Fixed, thanks.
AbrahamParangi 10y ago
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 significantly with respect to their growth rate so this statement is more accurate when comparing individuals who are early in their growth curve aka beginners.
- jpolitz 10y ago
  I responded to a similar comment in another thread from a pedagogic perspective, I hope this answer gives some perspective on how we approach this point: https://news.ycombinator.com/item?id=13186216 https://news.ycombinator.com/item?id=13186216 Also, Pyret can be used to make things – Pyret's compiler is written in Pyret! As the language matures, the experience of writing small Pyret programs that grow into real applications will only get more authentic.
- nine_k 10y ago
  People who learn to program have to get used to the idea that programming languages are many, and they have to attain certain competence in several of them. A typical frontend dev uses Javascript, CSS, HTML, likely some occasional bash. A backend developer probably faces the preferred backend language (Java / Python / Ruby / PHP / whatever), SQL, and has to have at least a nebulous understanding of HTML, CSS, and JS. A devops person has to face a shell language, the Unix tools mini-languages, have enough Python or Ruby chops to handle things like Ansible / Salt / Chef, and likely some SQL to keep an eye on the databases. This does not include smaller languages like regexps, or narrow-use languages like XSLT, JSON Schema, etc. There's no way you learn the One Practical Language That Matters and can be limited to it. You could in past, with a Spectrum or a TRS-80 and Basic, but the times have changed.
  - AbrahamParangi 10y ago
    I agree that everyone likely has to learn more than one language in the course of their life, but the difficulty of learning language N is typically more than learning language N+1. Therefore I believe that it is productive to start beginners off with a language which is: 1) as approachable as possible 2) as useful as possible Such that the value of that first, most difficult learning experience is maximized and the challenge is minimized.
gfodor 10y ago
I've never understood the idea of a 'teaching' programming language. (Modulo examples like Logo and Scratch, which offer much more than a language as part of a wider teaching/computing system.) You spend all this time ramping up on a language, toolchain, library, etc, that you will eventually be unable to leverage beyond a certain point since it is not one used by everyday programmers. The delta in "quality learning" between a teaching language and a non-teaching language would have to be astronomically high, imho, to offset the difference in capability and the opportunity cost of learning an applicable skill to a wider problem set. Something that is just a slightly better Python or a slightly better Clojure for the purpose of illustrating computer science concepts seems like something that you'd be doing a disservice to students to teach, vs the "real thing" which they could carry for the rest of their lives into future projects ad infinitum.
- AstralStorm 10y ago
  Yes, this should not be one of those training wheels, but a fully fledged solution. Even Pascal grew up into Object Pascal. Yes, it is still used in production.
- eastWestMath 10y ago
  I've had some experiences where it really helped. My supervisor uses a teaching stack based VM for his compilers class - it is slow as all hell but very simple, easy to get running, and it gives very good debugging info. Similarly, I can see the value in a simplified graphics API that let's you focus on the basic theory, or a simplified language with Hoare logic for writing loop invariants in an algorithms class.
- qwertyuiop924 10y ago
  The idea is that the concepts of CS are universal, regardless of programming language. So instead of using a programming language that has been designed for real world use (carved with the footprints of a thousand language hackers, full of awkward inconsistencies, warts, and good-enough-for-nows), teach in a teaching language - a programming language that is very regular, with very simple semantics, not necessarily designed for speed. However, this doesn't exclude it from being a Real Language. Scheme is both a very popular teaching language (perhaps the prototypical teaching language, being used in SICP), and has seen actual use, with a dedicated community around the various implementations of the language. For a teaching language, there are a lot of things built atop it. Like, say, this site (PG's Arc runs atop an old version of Racket, from back before Racket diverged quite so much from Scheme, and was still called Scheme).
good_gnu 10y ago
For me, this looks MUCH more like Haskell than Python and I think that this is symptomatic of an erroneous claim that some functional programming proponents seem to constantly make: That declarative, "mathy","deconstructive" programming is somehow easier to learn than imperative, "algorithmic", step-by-step constructive programming. In reality, most people in the world struggle with abstract mathematics and find it much more intuitive to think about a program as a series of steps and in terms of control flow. Programming beginners want to draw nice pictures on their computer, not struggle with understanding and implementing some recursive function. This is of course not to say that recursion is not an important concept or that functional languages have no merits. They are however complicated abstractions over simple concretions that are much easier to understand for a beginner.
- natec425 10y ago
  Do you have any measurable (preferably peer-reviewed) evidence that suggests imperative programming is inherently easier? That sounds like a challenging claim to make.
  - nnq 10y ago
    > a challenging claim to make ...or more like the obvious intuition and wisdom of 99% of working software developers. The intuition is not backed up by any peer-reviewed evidence but by the real world fact that most production code ends up written in C++, Java, C#, JavaScript, PHP, Python,Ruby etc. and not Haskell, OCaml, F#, Clojure etc. Since they made the first stone tools and cave drawings, humans have always defaulted to "how to" reasoning and not "what is" reasoning. You may have the opposite intuition for the simple reason that 99% of what you read, write or see on TV is produced by the the 0.01% percent of people with decent communication skills and a larger percent of them have better developed "what is" type thinking. Also, "what is" type knowledge is easier to communicate in compact form. Also, most people who tend to learn programming are "makers" types, like me, which have a huge bias towards "process based intuition": for examples, for us, intuitively, an "ellipse" is firstly "the abstract equivalent of what you get by drawing a curve constrained by a string constrained by 2 pins" (http://www.sems.und.edu/FrameA/SolarEclipses/ellipse.jpg http://www.sems.und.edu/FrameA/SolarEclipses/ellipse.jpg), not "the points whose sum of the distances from 2 fixed points is constant", and a "bubble sort" is "what you get by walking over an array and for each..." etc. And the obvious companion to "how to" or "procedure based" reasoning is extensive mutability because... this is how the physical world seems to work at our level: even writing an equation on paper is actually just "mutating the position of particles of ink from a pen to precise distinct locations on the piece of paper", and results in "changing the information stored at particular 'addresses' of the paper. Even pointers ended up being used not because they are a very smart or appropriate concept or anything, but because they map obviously to the intuition of "pointing at things scribbled on a piece of paper or a blackboard"... But yeah, "how to" reasoning scales horribly, creates huge misunderstanding and communication problems, and is extremely hard to debug, and we should start moving software engineering past the "cave drawing" stage... but this doesn't mean we should ignore where we're starting from :)
sergiotapia 10y ago
I really like the idea of tests right beside the code. I don't like how it's code though. Muddles what the actual implementation is a bit. Maybe with more usage the where statements start to blur and you don't notice them as much. I like Elixir's approach better where your test cases live as documentation examples in comment form, right above the function declaration. It's fantastic and free. Your mix test command runs tests, in addition to any examples you have as tests. http://elixir-lang.org/getting-started/mix-otp/docs-tests-and-with.html http://elixir-lang.org/getting-started/mix-otp/docs-tests-an... You put your tests as comments below an ## Example header. Oh and these examples go into your auto generated documentation as well. Ridiculously effective and free. You feel bad not using them.
- AstralStorm 10y ago
  Again, use IDE with code folding if that is ever a problem. At least it is in the same file. Cannot do that with elixir style tests easily.
- jpolitz 10y ago
  Pedagogically, the nice thing about the examples/tests just being code for beginners is that they are... just code! Once we've taught students about function calls and values, it's a small jump to write an example with "is" in the middle. The syntax errors, static errors about unbound identifiers, and dynamic behavior all act the same as everywhere else in the program, so it's less friction to write the first test. For getting off the ground writing that first test, I've been really happy with what Pyret lets us do. There is more involved in getting better testing/reporting options as systems scale up (we have lots of test-only files for the compiler), but pedagogically, the testing block infrastructure has worked well.
xbeta 10y ago
Yet another language - excuse for my lack of context/background, but why? If you go into a job now, how many will expect you to code in Pyret? Don't get me wrong, I love learning new languages and every language does give me a slightly different perspective when it comes to programming. It sometimes change how I think in my mind to code. But do we need a new language just for the sake of someone wants to write a new language?
- AstralStorm 10y ago
  We do. I'd love a more readable variant of Rust for example, with built in testing and contract support.
nnq 10y ago
Seems like a great functional scripting language with above-retard type system. This is really cool, no sarcasm. Just please don't label it as "educational" or "academic" or industry devs will avoid it out of pure macho-ism :) And find a way to marry it to a popular ecosystem, maybe a transpiler to js (for nodejs ecosystem) or python or go. 'Cause it really looks like a language I'd enjoy writing production code in if I could just `require` some of my favorite libs and hit the ground running!
- jpolitz 10y ago
  Pyret's runtime is entirely built on JavaScript (seriously: you can load https://code.pyret.org/editor https://code.pyret.org/editor, then turn off the network, and your IDE still works), and Pyret programs compile to JavaScript. At the command-line, it builds standalone JavaScript files that run under node. It's entirely possible to write pure JavaScript libraries that interface with the language (the compiler expects AMD style and requires that you write some small wrapping code). That's how the image library (https://www.pyret.org/docs/latest/image.html https://www.pyret.org/docs/latest/image.html) works, for instance, and how we connect to Google Sheets (https://github.com/brownplt/pyret-lang/wiki/TM028-Pyret-and-Google-Sheets-(Part-1) https://github.com/brownplt/pyret-lang/wiki/TM028-Pyret-and-...). Industry devs should be suspicious of Pyret's performance right now, though that will improve as time goes on. We've been spending most of our effort supporting our student and teacher users, so things that really build the traditional out-of-the-box language experience aren't where a typical application developer would hope. I think that's fine since we've made our intentions and goals clear (the educational audience and a coherent curricular design), and would be less fine if we were offering Pyret as a general-purpose language today. Offering it as general-purpose will become more and more reasonable as time goes on.
leeoniya 10y ago
http://www.nicolasbize.com/blog/30-years-later-qbasic-is-still-the-best/ http://www.nicolasbize.com/blog/30-years-later-qbasic-is-sti...
yagga 10y ago
"We need better languages for introductory computing. A good introductory language makes good compromises between expressiveness and performance, and between simplicity and feature-richness. Pyret is our evolving experiment in this space." Object Pascal is the best language I know for education. Programming education first must be about understansing algorithms I think. However, learning something old or not useful in real world can be harmful. The best I think is to learn modern tech. The development world evolves too and other skills become more relevant.
branchly2 10y ago
Every time I see a project pop up touted as being simple and a good "teaching language", it has some weirdness or pet features thrown in that turns enough people off to keep adoption low. If you want a good teaching language which will receive substantial adoption, do this: * syntax-wise, use curlies and semicolons like C, Java, Perl, JS, etc. * use many of the good function names that Perl uses. * have all variables be refs to objects, like Python does. * use nice normal lexical scoping like Scheme et al * this shouldn't have to be mentioned, but provide data literals for lists, maps, and sets * keep it small, and written in C, like Lua. * resist the temptation to complicate things by adding this really amazing advanced feature that it's just got to have to distinguish itself. * plan for it to become used for general purpose programming, as it very likely will. And some "don'ts": * don't worry about performance, that can come later * don't worry about lack of libs --- your implementation is in C, and you should get good ffi down the road. And with the substantial adoption you'll see, libs will come later anyway. * don't have it be on the JVM, LLVM, or any other existing VM. Keep it simple. Even an interpreter is fine for now. That's it. That's all you need to do for amazing success in a teaching language that will also see serious adoption. That said, no one does this. Presumably because if you're skilled enough to implement it, you have some neat but obscure features you'd like to add, or a unique syntax you'd prefer, which ... turns users off and keeps adoption low.
- jpolitz 10y ago
  Thanks for the advice! What are some examples where a teaching language has followed these points and succeeded? What is the weirdness and/or pet features you see in Pyret?
  - branchly2 10y ago
    I'm an old curmudgeonly programmer (more hobby than pro), have kids in middle and high school, and have some meager amount of teaching experience. Here's my take: your students (especially in middle and high school) are generally a captive audience. Maybe later, if they have more interest in comp sci, they may be interested in using a more alternative language, but right now they want you to give them something that looks mostly like the current lingua franca and then get out of their way. For the language I described above: * it's like JS but with warts removed * it's like C or C++, but higher level * it's like Java but doesn't require types or the JVM * it's like Perl but without the context rules and other zaniness * it's like Python but with better names, more familiar syntax, and better scoping (It's even a little like Scheme but with more conventional syntax, and regular lists, maps, and sets.) Students can use it in your class, then if they want to pursue programming in earnest, can very easily segue to any of those common languages above. Not only that: * They can easily re-type their classwork programs in any of the above langs, and not feel like their teacher had them using something that was only applicable to their particular class. * They can show their classwork programs to any JS/C/C++/Java/Perl/Python programmer and it will be easy for that person to make sense of what they're looking at (with no previous experience with the lang described above). I have no experience with Pyret, and don't want to cast any judgement on it or the people working on it. Maybe it's great and will benefit students even when they move on from their class which uses it.
labrador 10y ago
I really like this sensible policy: Some thoughts on syntax We believe indentation is critical for readable code, but we don't want the whitespace of the program to determine its meaning. Rather, the meaning of the program should determine its indentation structure. Indentation becomes just another context-sensitive rule. Unambiguous syntax (the reason for explicit end delimiters) means you can copy-and-paste code from email or the Web, and its meaning won't change. Your IDE can help you reindent code without worrying that doing so will change the meaning of the program.
fridsun 10y ago
I've long thought that Haskell is much more intuitive than any engineering languages out there for people with no programming experience, since it builds on mathematics that everyone has already learned. It's great to see functional programming placed at the center of intro-level programming teaching.
thecity2 10y ago
Why not just use the "easy" parts of Haskell as a teaching language for functional programming? No monads, applicatives, etc. No category theory. Just immutability, laziness, pattern matching, and type classes. I feel like that makes as much sense as developing an entirely new language that most likely will only be used by a complete novice. Conversely, one can grow with a language like Haskell for an entire lifetime. Just my two cents.
- skrishnamurthi 10y ago
  Because we also use Pyret to teach program complexity, and big-O is a whole 'nother can of worms in Haskell (the cost model is totally non-traditional). Because we use Pyret to introduce students to state, and even basic equality is a whole 'nother can of worms in Haskell. Because we teach basic algorithms in Pyret, and even something like DFS in Haskell is complicated (because of the preceding issues).
  - codygman 10y ago
    > even basic equality is a whole 'nother can of worms in Haskell How so?
    - skrishnamurthi 10y ago
      I'm afraid I don't have time here to explain Haskell. Think about how graph reduction and reference equality would interact.
      - tome 10y ago
        codygman and I both understand Haskell well, but neither of us (apparently) can work out what you mean. There's no "can of worms" around equality in Haskell as far as I can see.
        skrishnamurthi 10y ago
        See https://news.ycombinator.com/item?id=13198342 https://news.ycombinator.com/item?id=13198342
swat17 10y ago
For what it's worth, I'm a student at the University at which J Politz teaches. I haven't taken the programming languages course which is taught in Pyret, but it's worth noting that it's an upper level course here and everyone I know who's taken it is a fairly experienced programmer (relative to university CS standards, of course). So, if the fear is that Pyret is an unrealistic/overly complex/non transferable language to learn, it's definitely not marketted towards beginners here. By the time you're taking this class, you should already be well versed in Python and C++.
- jpolitz 10y ago
  Hey fellow Swattie! [Actually, I'm at UC San Diego as of this fall, so I'm a former fellow Swattie, I suppose :-) ] The programming languages course in question (https://www.cs.swarthmore.edu/~jpolitz/cs91/s15/ https://www.cs.swarthmore.edu/~jpolitz/cs91/s15/) indeed used Pyret, and that course is a heavy functional programming implementation course (writing interpreters, type inference, GC, etc). That's using Pyret for more complex programming, and is the upper end of where we use it pedagogically right now. Ditto for CS019 (the advanced introduction to data structures), and CS173 (PL) at Brown. In all of those cases, students _are_ expected to have some prior programming experience, so they get a faster introduction to Pyret. In the other direction, Pyret is in active use at the middle and high school level in math, cs, and physics classes, and this is where much of our active design work is tailored (tables, reactors, etc have some explicit curricular goals they target). They have scaffolding and workbooks written for their grade level, use features suitable for the context they are in, and so on. The use in CS91 in particular is (1) appropriate in the first place, since many functional languages could work in that setting, (2) eating my own dogfood, and (3) an excellent opportunity to discuss design decisions of a language that students are learning in a PL course, while it is still having design decisions made about it!
PudgePacket 10y ago
Looks fun actually ! Lots of critique in here, but you know what they say, there are only two types of languages ;)

306 points by gknoy 10y ago

Honestly imo Python is the best language to start with for learning. It has all the basic constructs of both functional and object oriented programming in plain english without a bunch of syntax to worry about. I personally think it's the most readable language. it's also quite intuitive imo. Lastly, there's a fantastic community and instant help is available for all skill levels but especially beginners on #python on freenode irc Pyret... isnt very readable, doesnt seem very intuitive, has somewhat odd syntax, and generally seems like a terrible choice for learning. Doubt it has the resources quality python has (community, docs, tutorials) i dont get it.

AstralStorm 10y ago
Isn't readable? It has mostly Python syntax. Some bits inspired by Standard ML, Ocaml, F# and Haskell. Nothing odd here. End marker prevents accidental scope overrun and is from Pascal I think. Community is hard to get for any new language. If this got popular, there would be no such problems. You're arguing that Python is Good Enough. But then, so was assembly.
posterboy 10y ago
>has somewhat odd syntax says the programmer using significant whitespace runs for cover
jpolitz 10y ago
The readability, unintuitive, and "odd syntax" comments are somewhat subjective, though I'd curious to hear what parts are odd and unintuitive for you. I linked to a perspective on where Pyret fits in in another similar answer: https://news.ycombinator.com/item?id=13187379 https://news.ycombinator.com/item?id=13187379 We also may have different definitions of what a "beginner" needs for community and help. Pyret is used in middle and high school classes (along with the undergraduate level). Those students, nor their teachers, are likely to know what IRC is or how to seek help on it. We do a lot of curriculum development, and professional development workshops in the summer are a major way we interact with these teachers and set them up with a high-bandwidth way to communicate with us over the year (which is direct email or mailing lists). Prompt and detailed help is certainly available for teachers (who then help their students), and it's coming from the folks who designed the curriculum and the language together. Those mailing lists are public (pyret-discuss [1] and bootstrap-teachers [2]), and anyone is welcome to ask away. [1] https://groups.google.com/forum/#!forum/pyret-discuss https://groups.google.com/forum/#!forum/pyret-discuss [2] https://groups.google.com/forum/#!forum/bootstrap-discuss https://groups.google.com/forum/#!forum/bootstrap-discuss Of course, Pyret doesn't have the huge community, Stack Overflow presence, documentation maturity, etc. of Python (or other major languages) for general programming. That takes time and consistent effort, but the lack of it doesn't negate the reasons Pyret is good for its current use cases.
zem 10y ago
i think the pyret syntax is wonderful, personally. it takes a lot of good bits from my two favourite languages, ruby and ocaml, and blends them into a nicely coherent whole. there are a few minor things i'd probably have done differently, but on the whole i find pyret code very pleasant to read.
- a0 10y ago
  > there are a few minor things i'd probably have done differently, but on the whole i find pyret code very pleasant to read. Curious to know what would you have done differently. I'm working on a programming language based on OCaml with Ruby-like syntax.
  - zem 10y ago
    just bikesheddy stuff like * |> rather than ^ for the pipe operator (more consistent with several other languages) * [list| 1, 2, 3] rather than [list: 1, 2, 3] (just for better visual distinction, though the current syntax does look pretty clean and uncluttered) * having a separate code block for methods of individual variants rather than interspersing them with data definitions (because i think it's important that the basic data definition be as uncluttered as possible) if you'd like some syntax feedback on your language i'd be happy to take a peek :)
    - skrishnamurthi 10y ago
      I'd disagree with the second one. `[list: 1, 2, 3]` reads more like in English: "I'm going to define a list: one, two, three…". Whereas `[list| 1, 2, 3]` has no obvious vocalization. (Vocalization is an important characteristic for us; it's how `ask` came to have its syntax.) In addition, we usually use `|` in programming languages in a separator kind of way (even `||` for "or" separates expressions), which it's certainly not in the list expression.
      - zem 10y ago
        "list where the elements are 1, 2, 3", by analogy with set builder notation or list comprehensions :) but i agree the current one reads better as english. it's the separator aspect i was getting at with my proposal though - visually it's [ datatype | elements ] whereas the current one looks more like the colon is part of the first element - [(list : 1), 2, 3]
skrishnamurthi 10y ago
No, Python doesn't actually have a lot of things you need in education. See https://news.ycombinator.com/item?id=13189513 https://news.ycombinator.com/item?id=13189513

hajderr 10y ago

"We need better languages for introductory computing." and "One of the enduring lessons from the Racket project is that no full-blown, general-purpose programming language is particularly appropriate for introductory education." Well not really, we need better teachers and methods for teaching programming and computing. A good language on its own is not gonna lift the interest.

jswrenn 10y ago
> Well not really, we need better teachers and methods for teaching programming and computing. I think most of the Pyret developers would agree wholeheartedly! To this end, the Pyret development team works closely (and in some cases, overlaps) with Bootstrap [1], a nation-wide program to teach programming to middle school students. The feedback we get from these teachers (and the process of teaching teachers) directly informs language design. Furthermore, at Brown University, where many of Pyret's developers have ties, Pyret is dogfooded on two courses: an "Accelerated Introduction to Computer Science" [2] and "Programming Languages" [3]. (Disclosure: I am a developer of Pyret.) [1] http://www.bootstrapworld.org/ http://www.bootstrapworld.org/ [2] https://cs.brown.edu/courses/cs019/2016/ https://cs.brown.edu/courses/cs019/2016/ [3] https://cs.brown.edu/courses/cs173/2016/ https://cs.brown.edu/courses/cs173/2016/
- webwanderings 10y ago
  Is there a good quality MOOC on Pyret? I am not in high school but am not a programmer either. I started using DrRacket MOOC fairly recently on Edx and had no idea about Pyret until today. My interest in finding good quality teaching, led me to Racket, all the way from the hype of Python/Ruby, and anyone else in between. I am trying to follow Racket but now I am confused between Racket and Pyret.
  - jpolitz 10y ago
    There is no MOOC I know of that uses Pyret (yet). Racket is great! If you're already deep into Racket, I wouldn't say stop to try Pyret unless you particularly have the goal of learning more languages, or there's something about Pyret that really gets you interested. We taught a programming languages course that uses Racket back in 2012, but all the material is still online: https://cs.brown.edu/courses/cs173/2012/ https://cs.brown.edu/courses/cs173/2012/ So if you're looking for online content that we recommend, that could be an interesting next step that makes use of the momentum you have in following Racket. The Pyret book PAPL is free online, and it's possible to dive in and follow that if you're curious about learning Pyret, though it doesn't have the infrastructure of assignments with autograders, etc, that a MOOC would have: http://papl.cs.brown.edu/2015/ http://papl.cs.brown.edu/2015/

eykanal 10y ago

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.

dexwiz 10y ago
Agreed. It probably helps enforce pure functions, which are one of the big pros touted about functional programming. Ideally most functions should be pure and isolatable from the rest of the program.
jstimpfle 10y ago
Is there something that prevents you from making functions that only check how other functions interact?
- eykanal 10y ago
  No, not at all. The point is that there's specific syntax in the language for making this part of the function definition, as it were. New concept for me.
- Avshalom 10y ago
  Scoping rules probably get in the way in some cases.
- deleted 10y ago
  [deleted]
Jtsummers 10y ago
They have a check clause which is detached from the functions themselves. This is where they would want you to do tests with multiple functions interacting.
thom 10y ago
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 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.

sdegutis 10y ago

> "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, etc. But what is BinTree in the following example on the website? Is it a type? Is it a function, or constructor, or what? I'm confused. data BinTree: | leaf | node(value, left, right) end

dexwiz 10y ago
Pretty sure its a union type.
- AstralStorm 10y ago
  Tagged union type, so no casting.
xearl 10y ago
> "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 -> Bool`. See http://www.pyret.org/docs/latest/Declarations.html#%28part._s~3adata-decl%29 http://www.pyret.org/docs/latest/Declarations.html#%28part._... for details.
- AstralStorm 10y ago
  Types are great unless you are forced to be explicit instead of the compiler doing automated type deduction.
Jtsummers 10y ago
My intuition from other languages is that it's a type and a set of constructors. leaf constructs an instance of type BinTree, as does node(4, leaf, leaf). This also matches how it's used in the where clause. The documentation seems to verify my intuition: http://www.pyret.org/docs/latest/A_Tour_of_Pyret.html#%28part._.Data%29 http://www.pyret.org/docs/latest/A_Tour_of_Pyret.html#%28par...

mattangriffel 10y ago

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 definitely a step back in terms of readability. In what world is: fun square(n :: Number) -> Number: n * n end ...easier for a beginner to understand than: def square(n): return n * n I get that the intention of this language seems to be to help beginners avoid some of the more common pitfalls that they may run into (ex. unexpected parameters and return values), but it seems like they do it at the expense of the total beginner's ability to understand and keep track of lots of new concepts when they're just starting out.

makmanalp 10y ago
Annotations are optional. This is equally valid: fun square(n): n * n end Not that different after all! And I say this as a lover of python and significant whitespace, but not having it at first would be easier.
- lmm 10y ago
  "def" is an abbreviation non-programmers are more likely to understand than "fun".
  - AstralStorm 10y ago
    But that's no fun. ;-) Seriously, fun is obvious for function to anyone. (also, defun in some other languages fits the bill) In contrast, def doesn't explain what is defined. (See Groovy where it is a real problem or JavaScript where you can use var for everything.)
    - lmm 10y ago
      > In contrast, def doesn't explain what is defined. (See Groovy where it is a real problem or JavaScript where you can use var for everything.) Does that matter? I'm used to Scala where `def x = 4` is just as good as `val x = 4` as far as a beginner's concerned.

makmanalp 10y ago

Yarr! Pyret always seemed like a great idea to me. It's still quite-scheme-y, and so can introduce functional programming ideas easily, without the hangups people normally have about syntax. It also has minimal weird-language-cruft that is hard to explain to beginners, that you'd normally have to be like "ok ignore the int argc, char argv for now". And it runs in the browser. Awesome. Can't wait to get a chance to dig in further. Also, try code samples in here: https://code.pyret.org/editor https://code.pyret.org/editor Also, scroll down to see the comparison vs other languages: http://www.pyret.org/#examples http://www.pyret.org/#examples

Insanity 10y ago

The annoying banner was distracting from the actual content unfortunatenly. From what I did see I don't see a reason to start using it in education to be honest. I don't see the problem with just teaching Java or Python. Sure it might be a bit harder, but it's what you'll end up using in the real world

skrishnamurthi 10y ago
https://news.ycombinator.com/edit?id=13189513 https://news.ycombinator.com/edit?id=13189513

danso 10y ago

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 result in subtracting b from a. But in Pyret, it seems that `a-b` would be interpreted as a reference? That seems needlessly confusing for no benefit in readability over using snakecase. Beginners frequently have issues with grammar, that is, they are pretty much unaware of it when trying to figure out the many other things they have to learn about programming. Even in SQL, I forget that it must be quite confusing for beginners to parse out the meaning of the `` in something as simple as: SELECT mytable.*, (a * b) AS myproduct, COUNT(*) AS the count FROM mytable ... Doesn't seem worth it to make the hyphen, which is so frequently associated with subtraction and negative numbers, have just a decorative meaning when used between word tokens (as opposed to subtraction of values represented by variables).

juliendorra 10y ago
On the other end, I love that Calca (mac and iPhone app and language) allows to use spaces in function or variable names. It's so natural.
jswrenn 10y ago
Pyret inherits hyphens-in-identifiers from Scheme/Racket. One of Pyret's largest users, Bootstrap [1], has long-used a dialect of Scheme, and has recently introduced a curriculum that uses Pyret. For these users, "virtually every other language" allows for hyphens in identifiers. Scheme mitigates the spacing issue with s-expressions. Pyret attempts to mitigate it by enforcing that operators should be separated from their operand with at least one space. (Disclosure: I am an occasional developer of Pyret.) [1] http://www.bootstrapworld.org/ http://www.bootstrapworld.org/
- eridius 10y ago
  Scheme and Racket are both LISPs, with very different syntax. Hyphens in identifiers aren't a hazard, because binary operators don't go between two other identifiers, and operators must be separated with spaces, e.g. subtraction looks like `(- 2 1)` instead of `2 - 1`. This means that using hyphens in identifiers is quite safe. But Pyret is using more traditional syntax, where binary operators go between their operands, e.g. `2 - 1`, which means using hyphens in identifiers is a hazard as the parent comment describes.

reacweb 10y ago

When I was student, my favorite language syntax was Caml, the ancestor of OCaml. I am surprise there was comparison with many languages but not OCaml.

throwaway009912 10y ago
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.
- mkolosick 10y ago
  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 subtyping, but I haven't found a satisfactory system that would let us do otherwise. I would also like to note that we do also have a new feature where types can be inferred if you provide tests in a "where:" block attached to a function. This infers a function's type solely from the examples of usage provided. If you have any other questions feel free to ask!
  - throw_again99 10y ago
    Hi, thanks. Primarily I wondered about actual mixing of ADTs and objects, which is limited even in OCaml, see e.g.: http://caml.inria.fr/pub/ml-archives/caml-list/2003/06/bed2822602ed37484c166cef1d57f7be.en.html http://caml.inria.fr/pub/ml-archives/caml-list/2003/06/bed28... But does Pyret always translate an ADT to a class hierarchy behind the scenes? This example sure looks like it does: data Animal: | elephant(name, weight) | tiger(name, stripes) | horse(name, races-won) ... end fun animal-name(a :: Animal): a.name end
    - 10y ago

romanovcode 10y ago

> Pyret is a programming language designed to serve as an outstanding choice for programming education For me these examples look super complicated.

jpolitz 10y ago
Thanks for the feedback – we've gotten this a few times, and I think the homepage is targeted too much towards getting across Pyret's design to an already multi-lingual audience, and not enough towards actual beginner uses of the language (of which we have many). This is something we're working on changing to make it easier to see what true beginner examples look like.

rogerbinns 10y ago

I'm somewhat confused by the indentation rules. Is this code valid? fun abc(d): d+1 end

jswrenn 10y ago
Yes, Pyret is totally indentation-insensitive.
- skrishnamurthi 10y ago
  FOR NOW. We have a plan for making the indentation checked but it's not been our top priority, but it is on our stack. Languages take a while to cook. Welcome to the kitchen. (-:
  - rogerbinns 10y ago
    I must admit to being a fan of the python approach. My example code above is obviously "wrong", and is immediately so in Python. In other languages it is valid, and then brings a burden for a reader of trying to determine why the indentation doesn't match the intent. Since code is read a lot more than it is written, that seems like pointless complications for no real benefit.
    - skrishnamurthi 10y ago
      You're conflating two things. Indentation can be enforced without being semantic. In Python, indentation is semantic: if you move certain statements two lines out, you've changed the meaning of the program. In Pyret, our goal is to enforce indentation but never make it semantic: i.e., there's an unambiguous place for every bit of code. You can select-all and hit Tab in the Pyret editor and it'll reindent your whole program according to the rules. We just haven't yet implemented the checker for these rules (in part because we still don't all agree on exactly what they will be). Once we agree, the program you wrote would be a syntax error, but a user could have the system automatically indent it for them to make it right. (Even now, they can have the line be automatically indented for them.)

AstralStorm 10y ago

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?

davexunit 10y ago
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.
- AstralStorm 10y ago
  But why? Best languages are truly general. This should aim to replace Racket, not be bait for a switch.
  - baldfat 10y ago
    Racket is both a programming language and a framework for building programming languages. http://queue.acm.org/detail.cfm?id=2068896 http://queue.acm.org/detail.cfm?id=2068896 Racket is the most fun I have had in Programming and the more I "get it" the more I enjoy it. I can't say that for any other language.
  - davexunit 10y ago
    Racket is a platform for running many languages. It's different than the usual "one language for everything!" mantra. You can Pyret for one part of a program, Racket for another, Typed Racket for another, etc.
- baldfat 10y ago
  http://www.pyret.org/pyret-code/ http://www.pyret.org/pyret-code/ > One of the enduring lessons from the Racket project is that no full-blown, general-purpose programming language is particularly appropriate for introductory education. By the time a language grows to be useful for building large-scale systems, it tends to have accumulated too many warts, odd corners, and complex features, all of which trip up students. The journal paper for DrScheme (the old name for DrRacket) explains this in some detail. In that respect, the closest fellow travelers of us Pyreteers are the Racketeers (see how that works?). In fact, the first version of Pyret was merely a #lang in Racket. Nevertheless, Pyret represents a departure from Racket (for now and for the near future, at least) for several reasons:

kofejnik 10y ago

tbh, it looks like ruby with minor changes

AstralStorm 10y ago
It is quite different syntax from Ruby.

phkahler 10y ago

What's the point? One would hope they start with a description of why this is better for education than something like Python. I just gave it a quick glance, and it looks like many other programming languages - a bunch of odd text gibberish. I don't think the problem dividing people into "gets it" and "doesn't get it" has anything to do with nuances in syntax or semantics.

steego 10y ago
Despite what the down voters think, I actually found this comment useful because I had the exact opposite reaction. I took a quick look at the examples, saw familiar syntax and features and quickly concluded it looks like a nice toy, but I'd probably never use it because there are way too many unknowns (Performance, runtime, buggy, etc. etc.). I was actually a little flabbergasted when you said it looked like "odd text gibberish", but then I took another look at the the first example and saw it. data BinTree: | leaf | node(value, left, right) end Unless I'm familiar with union types, what part of that code tells me this is a parameterized enum? Why should I assume we're even talking about data types? I'm relatively flexible when it comes to syntax, but clearly syntax is a huge hurdle that almost always gets in the way of adoption. I understand Pyret isn't looking to be the next Python, but for an educational language I would argue it's not living up to Python's Principle of Least Surprise. It's great if you know Haskell, OCaml, Python and other languages, but it's not so great if you're an unsuspecting student who's sharpened your teeth on Java/Python. I suspect most people could pick up the syntax pretty quickly, but I suspect most people still need some hand-holding on the first page. Most programmers still don't know what this short paragraph means: Pyret allows for concise, expressive, recursive data declarations. Type annotations are optional and can be added incrementally, to serve a variety of pedagogic styles and curricular needs.
- skrishnamurthi 10y ago
  It isn't designed to be for student who have “sharpened” their teeth on Java or Python. Nor does it claim to be. And that paragraph you quote is written for educators, not for students.
- 10y ago

ebbv 10y ago

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.

AstralStorm 10y ago
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.
Ericson2314 10y ago
These comments surprise my so much. Pyret is designed to have as much of a familiar scripty-looking syntax as is possible while not being a shit language. Just like Rust has lousy C-like syntax to not alienate that crowd.

vog 10y ago

> 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.)

skrishnamurthi 10y ago
Tests are, by definition, checked dynamically. And setting aside terminology, there's a small issue called the Halting Problem that makes most tests unable to be checked statically.

gre 10y ago

The docs at http://www.pyret.org/docs/latest/ http://www.pyret.org/docs/latest/ link to the outdated book. Update the link?

skrishnamurthi 10y ago
Yes, thanks. We weren't expecting to end up on HN today. (-:
jpolitz 10y ago
Fixed, thanks.

AbrahamParangi 10y ago

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 significantly with respect to their growth rate so this statement is more accurate when comparing individuals who are early in their growth curve aka beginners.

jpolitz 10y ago
I responded to a similar comment in another thread from a pedagogic perspective, I hope this answer gives some perspective on how we approach this point: https://news.ycombinator.com/item?id=13186216 https://news.ycombinator.com/item?id=13186216 Also, Pyret can be used to make things – Pyret's compiler is written in Pyret! As the language matures, the experience of writing small Pyret programs that grow into real applications will only get more authentic.
nine_k 10y ago
People who learn to program have to get used to the idea that programming languages are many, and they have to attain certain competence in several of them. A typical frontend dev uses Javascript, CSS, HTML, likely some occasional bash. A backend developer probably faces the preferred backend language (Java / Python / Ruby / PHP / whatever), SQL, and has to have at least a nebulous understanding of HTML, CSS, and JS. A devops person has to face a shell language, the Unix tools mini-languages, have enough Python or Ruby chops to handle things like Ansible / Salt / Chef, and likely some SQL to keep an eye on the databases. This does not include smaller languages like regexps, or narrow-use languages like XSLT, JSON Schema, etc. There's no way you learn the One Practical Language That Matters and can be limited to it. You could in past, with a Spectrum or a TRS-80 and Basic, but the times have changed.
- AbrahamParangi 10y ago
  I agree that everyone likely has to learn more than one language in the course of their life, but the difficulty of learning language N is typically more than learning language N+1. Therefore I believe that it is productive to start beginners off with a language which is: 1) as approachable as possible 2) as useful as possible Such that the value of that first, most difficult learning experience is maximized and the challenge is minimized.

gfodor 10y ago

I've never understood the idea of a 'teaching' programming language. (Modulo examples like Logo and Scratch, which offer much more than a language as part of a wider teaching/computing system.) You spend all this time ramping up on a language, toolchain, library, etc, that you will eventually be unable to leverage beyond a certain point since it is not one used by everyday programmers. The delta in "quality learning" between a teaching language and a non-teaching language would have to be astronomically high, imho, to offset the difference in capability and the opportunity cost of learning an applicable skill to a wider problem set. Something that is just a slightly better Python or a slightly better Clojure for the purpose of illustrating computer science concepts seems like something that you'd be doing a disservice to students to teach, vs the "real thing" which they could carry for the rest of their lives into future projects ad infinitum.

AstralStorm 10y ago
Yes, this should not be one of those training wheels, but a fully fledged solution. Even Pascal grew up into Object Pascal. Yes, it is still used in production.
eastWestMath 10y ago
I've had some experiences where it really helped. My supervisor uses a teaching stack based VM for his compilers class - it is slow as all hell but very simple, easy to get running, and it gives very good debugging info. Similarly, I can see the value in a simplified graphics API that let's you focus on the basic theory, or a simplified language with Hoare logic for writing loop invariants in an algorithms class.
qwertyuiop924 10y ago
The idea is that the concepts of CS are universal, regardless of programming language. So instead of using a programming language that has been designed for real world use (carved with the footprints of a thousand language hackers, full of awkward inconsistencies, warts, and good-enough-for-nows), teach in a teaching language - a programming language that is very regular, with very simple semantics, not necessarily designed for speed. However, this doesn't exclude it from being a Real Language. Scheme is both a very popular teaching language (perhaps the prototypical teaching language, being used in SICP), and has seen actual use, with a dedicated community around the various implementations of the language. For a teaching language, there are a lot of things built atop it. Like, say, this site (PG's Arc runs atop an old version of Racket, from back before Racket diverged quite so much from Scheme, and was still called Scheme).

good_gnu 10y ago

For me, this looks MUCH more like Haskell than Python and I think that this is symptomatic of an erroneous claim that some functional programming proponents seem to constantly make: That declarative, "mathy","deconstructive" programming is somehow easier to learn than imperative, "algorithmic", step-by-step constructive programming. In reality, most people in the world struggle with abstract mathematics and find it much more intuitive to think about a program as a series of steps and in terms of control flow. Programming beginners want to draw nice pictures on their computer, not struggle with understanding and implementing some recursive function. This is of course not to say that recursion is not an important concept or that functional languages have no merits. They are however complicated abstractions over simple concretions that are much easier to understand for a beginner.

natec425 10y ago
Do you have any measurable (preferably peer-reviewed) evidence that suggests imperative programming is inherently easier? That sounds like a challenging claim to make.
- nnq 10y ago
  > a challenging claim to make ...or more like the obvious intuition and wisdom of 99% of working software developers. The intuition is not backed up by any peer-reviewed evidence but by the real world fact that most production code ends up written in C++, Java, C#, JavaScript, PHP, Python,Ruby etc. and not Haskell, OCaml, F#, Clojure etc. Since they made the first stone tools and cave drawings, humans have always defaulted to "how to" reasoning and not "what is" reasoning. You may have the opposite intuition for the simple reason that 99% of what you read, write or see on TV is produced by the the 0.01% percent of people with decent communication skills and a larger percent of them have better developed "what is" type thinking. Also, "what is" type knowledge is easier to communicate in compact form. Also, most people who tend to learn programming are "makers" types, like me, which have a huge bias towards "process based intuition": for examples, for us, intuitively, an "ellipse" is firstly "the abstract equivalent of what you get by drawing a curve constrained by a string constrained by 2 pins" (http://www.sems.und.edu/FrameA/SolarEclipses/ellipse.jpg http://www.sems.und.edu/FrameA/SolarEclipses/ellipse.jpg), not "the points whose sum of the distances from 2 fixed points is constant", and a "bubble sort" is "what you get by walking over an array and for each..." etc. And the obvious companion to "how to" or "procedure based" reasoning is extensive mutability because... this is how the physical world seems to work at our level: even writing an equation on paper is actually just "mutating the position of particles of ink from a pen to precise distinct locations on the piece of paper", and results in "changing the information stored at particular 'addresses' of the paper. Even pointers ended up being used not because they are a very smart or appropriate concept or anything, but because they map obviously to the intuition of "pointing at things scribbled on a piece of paper or a blackboard"... But yeah, "how to" reasoning scales horribly, creates huge misunderstanding and communication problems, and is extremely hard to debug, and we should start moving software engineering past the "cave drawing" stage... but this doesn't mean we should ignore where we're starting from :)

sergiotapia 10y ago

I really like the idea of tests right beside the code. I don't like how it's code though. Muddles what the actual implementation is a bit. Maybe with more usage the where statements start to blur and you don't notice them as much. I like Elixir's approach better where your test cases live as documentation examples in comment form, right above the function declaration. It's fantastic and free. Your mix test command runs tests, in addition to any examples you have as tests. http://elixir-lang.org/getting-started/mix-otp/docs-tests-and-with.html http://elixir-lang.org/getting-started/mix-otp/docs-tests-an... You put your tests as comments below an ## Example header. Oh and these examples go into your auto generated documentation as well. Ridiculously effective and free. You feel bad not using them.

AstralStorm 10y ago
Again, use IDE with code folding if that is ever a problem. At least it is in the same file. Cannot do that with elixir style tests easily.
jpolitz 10y ago
Pedagogically, the nice thing about the examples/tests just being code for beginners is that they are... just code! Once we've taught students about function calls and values, it's a small jump to write an example with "is" in the middle. The syntax errors, static errors about unbound identifiers, and dynamic behavior all act the same as everywhere else in the program, so it's less friction to write the first test. For getting off the ground writing that first test, I've been really happy with what Pyret lets us do. There is more involved in getting better testing/reporting options as systems scale up (we have lots of test-only files for the compiler), but pedagogically, the testing block infrastructure has worked well.

xbeta 10y ago

Yet another language - excuse for my lack of context/background, but why? If you go into a job now, how many will expect you to code in Pyret? Don't get me wrong, I love learning new languages and every language does give me a slightly different perspective when it comes to programming. It sometimes change how I think in my mind to code. But do we need a new language just for the sake of someone wants to write a new language?

AstralStorm 10y ago
We do. I'd love a more readable variant of Rust for example, with built in testing and contract support.

nnq 10y ago

Seems like a great functional scripting language with above-retard type system. This is really cool, no sarcasm. Just please don't label it as "educational" or "academic" or industry devs will avoid it out of pure macho-ism :) And find a way to marry it to a popular ecosystem, maybe a transpiler to js (for nodejs ecosystem) or python or go. 'Cause it really looks like a language I'd enjoy writing production code in if I could just `require` some of my favorite libs and hit the ground running!

jpolitz 10y ago
Pyret's runtime is entirely built on JavaScript (seriously: you can load https://code.pyret.org/editor https://code.pyret.org/editor, then turn off the network, and your IDE still works), and Pyret programs compile to JavaScript. At the command-line, it builds standalone JavaScript files that run under node. It's entirely possible to write pure JavaScript libraries that interface with the language (the compiler expects AMD style and requires that you write some small wrapping code). That's how the image library (https://www.pyret.org/docs/latest/image.html https://www.pyret.org/docs/latest/image.html) works, for instance, and how we connect to Google Sheets (https://github.com/brownplt/pyret-lang/wiki/TM028-Pyret-and-Google-Sheets-(Part-1) https://github.com/brownplt/pyret-lang/wiki/TM028-Pyret-and-...). Industry devs should be suspicious of Pyret's performance right now, though that will improve as time goes on. We've been spending most of our effort supporting our student and teacher users, so things that really build the traditional out-of-the-box language experience aren't where a typical application developer would hope. I think that's fine since we've made our intentions and goals clear (the educational audience and a coherent curricular design), and would be less fine if we were offering Pyret as a general-purpose language today. Offering it as general-purpose will become more and more reasonable as time goes on.

leeoniya 10y ago

http://www.nicolasbize.com/blog/30-years-later-qbasic-is-still-the-best/ http://www.nicolasbize.com/blog/30-years-later-qbasic-is-sti...

yagga 10y ago

"We need better languages for introductory computing. A good introductory language makes good compromises between expressiveness and performance, and between simplicity and feature-richness. Pyret is our evolving experiment in this space." Object Pascal is the best language I know for education. Programming education first must be about understansing algorithms I think. However, learning something old or not useful in real world can be harmful. The best I think is to learn modern tech. The development world evolves too and other skills become more relevant.

branchly2 10y ago

Every time I see a project pop up touted as being simple and a good "teaching language", it has some weirdness or pet features thrown in that turns enough people off to keep adoption low. If you want a good teaching language which will receive substantial adoption, do this: * syntax-wise, use curlies and semicolons like C, Java, Perl, JS, etc. * use many of the good function names that Perl uses. * have all variables be refs to objects, like Python does. * use nice normal lexical scoping like Scheme et al * this shouldn't have to be mentioned, but provide data literals for lists, maps, and sets * keep it small, and written in C, like Lua. * resist the temptation to complicate things by adding this really amazing advanced feature that it's just got to have to distinguish itself. * plan for it to become used for general purpose programming, as it very likely will. And some "don'ts": * don't worry about performance, that can come later * don't worry about lack of libs --- your implementation is in C, and you should get good ffi down the road. And with the substantial adoption you'll see, libs will come later anyway. * don't have it be on the JVM, LLVM, or any other existing VM. Keep it simple. Even an interpreter is fine for now. That's it. That's all you need to do for amazing success in a teaching language that will also see serious adoption. That said, no one does this. Presumably because if you're skilled enough to implement it, you have some neat but obscure features you'd like to add, or a unique syntax you'd prefer, which ... turns users off and keeps adoption low.

jpolitz 10y ago
Thanks for the advice! What are some examples where a teaching language has followed these points and succeeded? What is the weirdness and/or pet features you see in Pyret?
- branchly2 10y ago
  I'm an old curmudgeonly programmer (more hobby than pro), have kids in middle and high school, and have some meager amount of teaching experience. Here's my take: your students (especially in middle and high school) are generally a captive audience. Maybe later, if they have more interest in comp sci, they may be interested in using a more alternative language, but right now they want you to give them something that looks mostly like the current lingua franca and then get out of their way. For the language I described above: * it's like JS but with warts removed * it's like C or C++, but higher level * it's like Java but doesn't require types or the JVM * it's like Perl but without the context rules and other zaniness * it's like Python but with better names, more familiar syntax, and better scoping (It's even a little like Scheme but with more conventional syntax, and regular lists, maps, and sets.) Students can use it in your class, then if they want to pursue programming in earnest, can very easily segue to any of those common languages above. Not only that: * They can easily re-type their classwork programs in any of the above langs, and not feel like their teacher had them using something that was only applicable to their particular class. * They can show their classwork programs to any JS/C/C++/Java/Perl/Python programmer and it will be easy for that person to make sense of what they're looking at (with no previous experience with the lang described above). I have no experience with Pyret, and don't want to cast any judgement on it or the people working on it. Maybe it's great and will benefit students even when they move on from their class which uses it.

labrador 10y ago

I really like this sensible policy: Some thoughts on syntax We believe indentation is critical for readable code, but we don't want the whitespace of the program to determine its meaning. Rather, the meaning of the program should determine its indentation structure. Indentation becomes just another context-sensitive rule. Unambiguous syntax (the reason for explicit end delimiters) means you can copy-and-paste code from email or the Web, and its meaning won't change. Your IDE can help you reindent code without worrying that doing so will change the meaning of the program.

fridsun 10y ago

I've long thought that Haskell is much more intuitive than any engineering languages out there for people with no programming experience, since it builds on mathematics that everyone has already learned. It's great to see functional programming placed at the center of intro-level programming teaching.

thecity2 10y ago

Why not just use the "easy" parts of Haskell as a teaching language for functional programming? No monads, applicatives, etc. No category theory. Just immutability, laziness, pattern matching, and type classes. I feel like that makes as much sense as developing an entirely new language that most likely will only be used by a complete novice. Conversely, one can grow with a language like Haskell for an entire lifetime. Just my two cents.

skrishnamurthi 10y ago
Because we also use Pyret to teach program complexity, and big-O is a whole 'nother can of worms in Haskell (the cost model is totally non-traditional). Because we use Pyret to introduce students to state, and even basic equality is a whole 'nother can of worms in Haskell. Because we teach basic algorithms in Pyret, and even something like DFS in Haskell is complicated (because of the preceding issues).
- codygman 10y ago
  > even basic equality is a whole 'nother can of worms in Haskell How so?
  - skrishnamurthi 10y ago
    I'm afraid I don't have time here to explain Haskell. Think about how graph reduction and reference equality would interact.
    - tome 10y ago
      codygman and I both understand Haskell well, but neither of us (apparently) can work out what you mean. There's no "can of worms" around equality in Haskell as far as I can see.
      - skrishnamurthi 10y ago
        See https://news.ycombinator.com/item?id=13198342 https://news.ycombinator.com/item?id=13198342

swat17 10y ago

For what it's worth, I'm a student at the University at which J Politz teaches. I haven't taken the programming languages course which is taught in Pyret, but it's worth noting that it's an upper level course here and everyone I know who's taken it is a fairly experienced programmer (relative to university CS standards, of course). So, if the fear is that Pyret is an unrealistic/overly complex/non transferable language to learn, it's definitely not marketted towards beginners here. By the time you're taking this class, you should already be well versed in Python and C++.

jpolitz 10y ago
Hey fellow Swattie! [Actually, I'm at UC San Diego as of this fall, so I'm a former fellow Swattie, I suppose :-) ] The programming languages course in question (https://www.cs.swarthmore.edu/~jpolitz/cs91/s15/ https://www.cs.swarthmore.edu/~jpolitz/cs91/s15/) indeed used Pyret, and that course is a heavy functional programming implementation course (writing interpreters, type inference, GC, etc). That's using Pyret for more complex programming, and is the upper end of where we use it pedagogically right now. Ditto for CS019 (the advanced introduction to data structures), and CS173 (PL) at Brown. In all of those cases, students _are_ expected to have some prior programming experience, so they get a faster introduction to Pyret. In the other direction, Pyret is in active use at the middle and high school level in math, cs, and physics classes, and this is where much of our active design work is tailored (tables, reactors, etc have some explicit curricular goals they target). They have scaffolding and workbooks written for their grade level, use features suitable for the context they are in, and so on. The use in CS91 in particular is (1) appropriate in the first place, since many functional languages could work in that setting, (2) eating my own dogfood, and (3) an excellent opportunity to discuss design decisions of a language that students are learning in a PL course, while it is still having design decisions made about it!

PudgePacket 10y ago

Looks fun actually ! Lots of critique in here, but you know what they say, there are only two types of languages ;)