7 ms·

Pyret looks like a there's a lot going on, based on the examples. It has implicit returns, special purpose syntax for data structures, iterators, assertions, re

• saosebastiao 13y ago
  Edit: deleting snark. Oz is one of the best languages ever for learning CS.
• xfs 13y ago
  Actually Brown teaches Intro to Programming Languages using Pyret. http://cs.brown.edu/courses/cs173/2013/software.html http://cs.brown.edu/courses/cs173/2013/software.html
  • legutierr 13y ago
    By looks of the course number, this is a third or fourth year elective for undergrads. It seems that what is being taught here is the design and engineering of programming languages, not programming itself.
    • dbpatterson 13y ago
      That's correct - 173 is definitely not an intro course. But, we also are teaching an intro course with it: http://cs.brown.edu/courses/csci0190/2013/software.html http://cs.brown.edu/courses/csci0190/2013/software.html
  • fgoodman 13y ago
    They also teach the Accelerated Intro to Computer Science (the first cs course some students take) using Pyret. http://cs.brown.edu/courses/cs019/2013/ http://cs.brown.edu/courses/cs019/2013/
• PhineasRex 13y ago
  By that logic, assembly is the best language to learn programming. Presumably it is easier to learn about concepts with a language that has them.
  • gizmo 13y ago
    Obviously I'm not suggesting that assembler is the best teaching language. I could also take your logic and use it to conclude that C++ is the best programming language to learn first because with C++ you can learn about the implications of heap corruption when improperly handling exceptions in constructors. C++ allows functional, procedural and OO and many more programming styles. It supports manual and automatic memory management. It can be used to teach high level and low level programming constructs. But I think we're all in agreement that C++ is not a good first language to learn despite (or because of) its versatility. I think Python is a very accessible programming language that still has enough depth to go into a lot of interesting CS subjects. That Python doesn't have manual memory management or support for true multiple inheritance means that you can't teach those things effectively with Python, and I'm completely OK with that trade-off.
    • skrishnamurthi 13y ago
      Defining basic data structures is a pain. See the example on the Pyret homepage. I am already seeing a trend in Python tutorials where they just stay away from complex data, and stick to what is easy to encode in the data structures that Python does provide (lists, dictionaries, arrays). We've seen this movie before: it's what happened when languages like Fortran, Pascal, and C dominated programming education, and the fact that they made some data (particularly of the linear kind) really easy and others a nuisance meant that curricula diverted towards the path of least resistance. It's harder now to spot the pattern because it's better hidden. But it's still there.
  • tokenrove 13y ago
    Actually, there's a (devil's advocate) argument for teaching assembly first. After all, TAOCP is all assembly for good reason. Many programmers who never learn any assembly language lack a kind of procedural literacy, as well as a mechanical sympathy, which are a big part of the craft of programming. But, as you state, there are a lot of higher-level programming concepts you can't effectively learn in assembler (one imagines a bizarrely circuitous route around learning to build compilers in assembly (via Forth perhaps) in order to teach lexical scoping or similar).
• tel 13y ago
  My understanding is that it's a relatively simple place to learn about how to manipulate data (as in algebraic data type style, FP data) and has all of the conveniences of syntax that allows someone to think fluently about that concept. So it's syntactic complexity might be high, but it's conceptual complexity is rather low.
• jkscm 13y ago
  Language complexity may not matter much. "He speculated that the size of programming languages might confuse many students trying to learn to program. Java, the teacher’s programming language of choice at the end of the 20th century and at the beginning of the 21st, is defined loosely but at great length in several hundred pages.4 Natural Deduction, on the other hand, can be defined precisely on a single side of a single A4 sheet, in a normal font size. It is small and conceptually simple: surely it can be taught! Well, up to a point it can, but the results were depressingly familiar. Figure 14 shows the results from an in-course exam on formal logical proof. Unlike the examinations of section 3, students were strongly discouraged from guessing, with negative marks for wrong answers in multiple-choice questions and extensive unseen proof problems. As a consequence, two humps are clearly visible, with one at 33-40 (about 50%) and another at 65-72 (about 85%). (This data was collected long before Dehnadi’s test was developed, so we can’t analyse it further)." Saeed Dehnadi - The camel has two humps (working title): http://mrss.dokoda.jp/r/http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf http://mrss.dokoda.jp/r/http://www.eis.mdx.ac.uk/research/Ph...
• jpolitz 13y ago
  Thanks for your comments! I have two responses: 1. You're right that exposing too much, too soon is a recipe for disaster. People can only fit so many new concepts in their head at once, and blasting them with refinement types from day one isn't a great idea. However, there's two things at work here: the role of the curriculum and the role of the language. Pyret is careful to allow a gradual transition to more and more complex features. Annotations are not necessary on day 1, and neither are iterators. We write untyped, recursive-descent functions on lists in the beginning, and build up to types and the pleasant terseness of "for" loops. If Pyret required introducing these concepts to write any programs, that would indeed be a problem, but we've put thought into the dependencies between curricular concepts and the needed language constructs to mitigate exactly this concern. 2. I think that some of the features you listed are actually a huge necessity in early programming, particularly special purpose syntax for data structures. Teaching the definition and implementation of a balanced binary tree to folks without language experience in Python or Java requires a huge amount of boilerplate explanation. You need to describe classes, fields, and constructors just to do the equivalent of Pyret's "data". The alternative (at least in Python) is to encode everything in lists and dictionaries, but hopefully in 2013 we've moved beyond writing all our data structures that way :-)
  • colanderman 13y ago
    Joe, any plans to push this out in Kathi's intro course at WPI?
    • skrishnamurthi 13y ago
      Not our decision! Tell the WPI folks about it and why (if) they should consider using it.
• dragonwriter 13y ago
  I don't see why a complex language can't be good for teaching if its designed in such a way that the complexity is optional, and you can use a focussed subset for pedagogical purposes (especially when the language supports using different focussed subsets depending on the specific focus of pedagogy.) I mean, even if you look at how language like Scheme/Racket, or Python, or pretty much any other language is used in teaching, you don't usually use the whole thing in any one teaching context.
  • skrishnamurthi 13y ago
    This is true of all educational settings -- except that the language subset then becomes an unenforced (and hence very leaky) abstraction. Students inadvertently step outside the subset and get either bizarre errors or, worse, their program runs and produces strange errors. DrRacket pioneered the notion of "language levels" that grow with the student's needs. Pyret will end up taking some variant of this route. It's just too early to design those levels yet.
• skrishnamurthi 13y ago
  The language is in use in introductory courses, with a gradual introduction of these topics. It's no different from using any other modern programming language in education. Our goal is to eventually create language levels, pioneered by DrRacket, based on what we learn from observation. This is a research project in addition to a development one, where the research is into human factors.
  • colanderman 13y ago
    Why replace Racket with Pyret? Is this purely to stop students from being able to complain about syntax or is there a deeper strategic reason behind this? Refinement types are nice. I really wish those were more common.
    • skrishnamurthi 13y ago
      Your second paragraph answered your first paragraph (-:. 1. We have a different view of static typing than Racket. 2. We have a different view of the type language than Racket. 3. Long term, we are working on smoothly integrating testing, types, and specification [as a spectrum -- perhaps even as a cycle -- rather than as three different things]. Refinements are an instance of this. Another is our plan for how to do type inference. 4. I am also convinced that parenthetical syntax has real problems that I can't completely ignore. Of course, it doesn't hurt if it can get people to stop complaining. (It's not only students: the bigger opposition often comes from teachers. Unfortunately the teachers control the path to the students, so their views _really_ matter!)
      • colanderman 13y ago
        I am also convinced that parenthetical syntax has real problems that I can't completely ignore. What brought you to this conclusion? Experience from Bootstrap (in which I found arithmetic and parenthesis counting to be the biggest stumbling blocks) or just personal reflection?
        • skrishnamurthi 13y ago
• skrishnamurthi 13y ago
  DrRacket pioneered the notion of "language levels" that grow with the student's needs. Pyret will end up taking some variant of this route. It's just too early to design those levels yet. Once we have more experimental data about what kinds of inadvertent mistakes students make, we'll be in a position to say, "Oh, yeah, that was a bad thing to release on day 1", etc.
• carterschonwald 13y ago
  The grammar can be described with a single page in actual BNF. Thats AMAZING. The only languages have shorter grammars are core lisp/scheme. Ruby is fundamentally impossible to describe with a BNF.
  • vidarh 13y ago
    > Thats AMAZING. The only languages have shorter grammars are core lisp/scheme. It's nice, but I'm not sure I'd go with amazing. Most or all of Niklaus Wirth's languages have shorter grammars, for example. I'd imagine quite a few others do as well. E.g. Oberon-2 has 33 EBNF productions: http://en.wikipedia.org/wiki/Oberon-2_(programming_language) http://en.wikipedia.org/wiki/Oberon-2_(programming_language) - that fits fully on screen for me with my default font size... Regarding Ruby, I agree. I'm working on a Ruby compiler, and "decoding" the MRI parser into something closer to optimal will still leave an awful mess no matter what you do. I love programming Ruby, but implementing it is hell (and one of the reasons I'm trying it...)
    • skrishnamurthi 13y ago
      If you think parsing is the hard part, wait for the semantics. See, for instance, the Ruby examples on the Pyret home page.
      • carterschonwald 13y ago
        agreed, having decent semantics is key. :)
      • vidarh 13y ago
        I don't see any difficult semantics in those examples. The hard part of parsing Ruby is mostly trying to conform to MRI rather than to a formal grammar. In comparison the semantics are reasonably simple. It's hard to compile Ruby efficiently, though, but for reasons unrelated to those examples. (Incidentally I don't know if that scoping example is intentionally ignoring the fact that Ruby does support lexical scoping (EDIT: for blocks), or if it's lack of understanding of what what "def" is. The Ruby way of achieving what that example is trying to do is: def f(x) g = proc do |y| x + y end g[2] end f(2) (g[2] is shorthand for g.call(2)) "def" explicitly introduced a method-level scope of the innermost wrapping class scope. Nesting 'def's is not in any way idiomatic Ruby. It's not necessarily very useful to nest them given those semantics. But "def" is really just syntactic sugar for #define_method, and so it is logical for it to work where #define_method does. I might be inclined to agree that the different Ruby ways of defining blocks, methods and closures could do with some simplification. Allowing "def" to bind surrounding variables would remove a lot of the need for class instance variable or class variables, for example. ) EDIT: Also, the currying example would look like this in Ruby: o = Object.new def o.my_method(x) self.y + x end def o.y 10 end method_as_fun = o.method(:my_method) method_as_fun[5] You can argue for implicit currying if you want, but to me that's far more confusing. That said, it is extremely rare to find currying used in Ruby code.