jpolitz

Thanks for the feedback!

To add to what you said, this is exactly the kind of situation where we design features that _may_ not scale well, but are remarkably useful in teaching contexts.

Having test cases inline with code is massively useful:

1. For students not used to thinking about their program being split over several files. If tests must be in their own file, then understanding multi-file programs (modules, essentially), becomes a curricular dependency of writing tests. That is a _lot_ of friction early on – think about an intro student who has a fuzzy notion of a "working directory" or IDE "workspace" in general. Even if the eventual goal is to address these concepts, they shouldn't have to come first just to write a unit test.

2. When live coding in front of a class. Having tests in a separate file is a huge pain because you pay either (a) the cognitive overhead of switching buffers, or (b) precious projector real-estate on having both open. Since live-coding programs that are less than 100 lines long is a major use case for Pyret, this is a big win.

As programs scale up, for example in Pyret's compiler or in larger assignments, we end up with a blend of test cases in inline where: blocks, with the majority in separate files in standalone check: blocks. So at scale, things turn into more traditional-looking separate suites.

Another important metric: a handful of C programmers can write arbitrarily more buffer overflows than thousands of Java or Ruby programmers.

It is a real issue. The programming languages and software engineering communities have been working on evaluating software artifacts for a few years now:

http://www.artifact-eval.org/

This doesn't address open access, but it does make sure the software is usable by a non-author to reproduce the results of the paper.

There's progress on this front in computer science conferences in software-focused disciplines:

http://www.artifact-eval.org/ https://plus.google.com/+JanVitek/posts/19BH96G8rrw

The artifact evaluation workflow is a reasonable starting point for what you suggest.

Racket and #lang are a pretty good start.

http://www.ccs.neu.edu/home/matthias/manifesto/sec_pl-pl.htm...

In some software-focused conferences, artifact evaluation has become a new, separate phase:

http://www.artifact-eval.org/

There is a separate committee charged with evaluating software (and other artifacts, like data sets), that come along with a paper.

This is a nice start to a process that could be adopted in non-CS fields for the evaluation of statistical results or software that analyzes data.

Thanks for the response! Related to (1), the issue was more that when a _student_ visits an assignment page, they get the same big permission list as an instructor; it makes sense that instructors might need a plethora of permissions. Is that necessary for students?

Issue for (3) reported here: https://github.com/education/classroom/issues/250

I use Github in my courses, and I was excited when I saw this. Three responses:

1. The permissions screen immediately irked some of my collaborators – why does this need access to _everything_, including deleting repositories that already exist? They pointed out that if one privacy/security-conscious student makes a stir about this in an undergrad course, it's all of a sudden a potentially huge issue. And I teach my students to be suspicious of screens that ask for too many permissions, with good reason!

2. Can I connect this to my institution's internal Github enterprise? I currently manage assignment distribution and collection with hand-rolled Github scripts that run against our institution's deployment. Do the teachers_pet scripts work in that environment as well, or is there Classroom-specific setup required to make that work?

3. On the screen where I choose organizations, there was a text box for a new organization, and a dropdown. I thought I was making the choice to create a new organization, but it seems to be creating all the repos in an existing organization selected in the dropdown. This has caused a lot of folks to all of a sudden get signed up for automatic notifications who are members of the selected org. That's annoying, now I have to clean up after Classroom and figure out what went wrong. I doubt that adding random student repos to an existing organization is ever what a new user wants, and I tried to follow the flow that (I thought) would not accidentally do that. It seems like a Classroom organization is a different thing from a Github organization?

Off the top of my head, I'm not sure (other than follow-up work to this paper, like http://jeapostrophe.github.io/home/static/icfp065-mccarthy.p... [ICFP '09]). But, the ideas in that paper aren‘t any less true just because they are from 2005, and they are still what the Racket web server runs on as far as I know :-)

I'm always really impressed when things just work in Wine. I started using YNAB this year and sure enough, it worked in Wine _with Dropbox integration_. Pretty cool.

For an approach that does this, check out how Racket's web server manages statelessness across requests:

http://docs.racket-lang.org/web-server/stateless.html#%28par...

http://cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-...

I contacted the site's author, the link should work now.

One suggestion is Triplicate (http://practicaltypography.com/triplicate.html), which looks _awesome_ at high resolutions.

Looks like a version of the paper without the ACM paywall is at https://web.cs.umass.edu/publication/docs/2013/UM-CS-2013-02....

This looks like a really great idea. Does Convox provide a convenient way to set up SSL for custom domains? The custom domains page (https://docs.convox.com/docs/custom-domains) didn't say much about it, but I may just be looking in the wrong place.

For an interesting dive into one formal definition of the expressiveness of different features, see [1]. It defines expressiveness of features by asking questions like (I'm really simplifying here) "If I add this feature to my language and start plugging it into programs that didn't use that feature before, can I write any programs that I couldn't before?"

This is a useful definition because a feature like an enhanced for-loop doesn't have global effects on the program if it's plunked into some local context -- the same program could have been written without it. But adding something like, say, exceptions does have interesting nonlocal effects, and allows for differently-shaped computations than before.

The useful point here is that the feature is added as an incremental change on an already-existing language, so its effects can be measured relative to the original language. The original and extended language can both be Turing-complete, and this is still a useful definition.

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.4...

For studies of Racket student level error messages, see:

http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-mi... http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-me...

Thanks for the feedback. (EDIT: I should note that my only substantial contribution to Racket proper is bug reports and one blog post. I'm mostly just a fanboy.)

The load problem definitely doesn't jive with my experience, so I'd like to hear about it if it happens again.

I do a lot of Pyret work on a many years-old Acer Aspire Timeline X, and the slowest loads (in powersaver mode) take 25ish seconds. The lab machines my students work on take about 5-10 seconds, their laptops differ widely in (guessing a bit here) the 5-30s range, and many do work on their laptops. Students are somewhat annoyed by the load time, but this is actually not out of the ballpark for how long it takes, say, DrRacket to start (just now it took 5s on my lab machine, ~11s on my piddly laptop). So in our experience it hasn't been prohibitive, but that doesn't mean there aren't classes of machine/browser combinations that screw it up that I don't know about.

I recommend Chrom[e|ium] to my class at Swarthmore (Chromium is installed by default on department machines here), though Safari and modern IE (IE10+) have worked totally fine in practice, too. Firefox has some unfortunate interactions with the way Pyret does stack management that can make it really slow. I do have a few students who stick by Firefox and do all their work in it, despite the slowdown, so it's not unusable for them, but it is annoying.

For some assignments I do imports from Google Drive for black-box support code, and that requires connectivity, so I've gotten some minor complaints from students doing a lot of air travel (for e.g. job and grad school interviews) about that. But my students are used to having some assignments that require access to machines in the department, so it isn't a huge deal. With a Chrome App, or even just upcoming standards like ServiceWorkers, we should start to be able to cache enough/do more in the browser to make this a non-issue, even across tabs closing and browser restarts. There's more we could be doing right now with localStorage to get around this, even, but just haven't done the engineering required. So no fundamental obstacles to a better offline experience for the browser-based editor, "just" substantial engineering work.

The CLI and packaging up Pyret as an installable "binary" (really a JS blob + Node) are works in progress, but having a good CLI repl is an explicit goal.

(I'm a Pyret core designer/developer.)

Pyret started its life as a #lang, which was delightful as a prototyping tool.

The demands of running with reasonable performance in a browser led us to switch to a direct-to-JS approach, and we haven't looked back since. The original Pyret-to-JS compiler has been up and running for around a year now; we're still learning how to improve and tune its performance, but it's proven quite robust.

No macros are planned, though it's not set in stone that they'll never happen. Just not a priority, and not something that Pyret's use in classrooms has caused huge demand for.

Pyret does indeed have a number of Racket's good ideas in it (especially from the teaching languages, and especially with respect to testing), along with a few new ones. However, I'd like to temper the comment "most of the good and advanced parts of Racket..." A number of Racket's advanced features, for example #lang and powerful macros, the super-expressive class/mixin/trait system, and OS-level resource management, aren't things that Pyret handles right now, and won't come right away.

Pyret's development will continue to be driven by classroom usage and curricular demands first, so it eschews, for example, the "everything should be in the language" part of Racket's manifesto. That's just a case of differing goals, which means that if you're, say, prototyping a new language from scratch, it will likely always be a safe bet to do it in Racket rather than in Pyret. (But if you're prototyping an algorithm over algebraic datatypes and want a web-based editor to try it out, just hop on over to https://code.pyret.org/editor and dive in.)

As a note on where we're maturing to, Pyret will accommodate gradual typing to mix static and dynamic checking of annotations, which is an area of active development, and something that Typed Racket is pioneering. Another thing we're thinking hard about is native JavaScript interop, to bring the lovely libraries of the Web to Pyret programmers, without forcing beginners to grok the intricacies of JS and the browser's evaluation model.

Re the typing point:

Statements like "Python is more strongly-typed than Java" can mean too many different things without a precise definition of what "strongly-typed" means. The Wikipedia page linked from the article even supports the position that there isn't an accepted definition for the strong vs. weak! (https://en.wikipedia.org/wiki/Type_system#.22Strong.22_and_....)

These terms are not very illuminating, and I don't understand the post's argument about types as a result, especially w.r.t None vs. null.

One argument that the post might be making, and I'd like to see fleshed out, is "Python's expressions and built-in operators check their inputs at runtime in a way that gives useful and effective error messages in practice." That seems like a lesson from experience that could be backed up with anecdotes and provide some useful feedback on the language. That avoids the terminology debate about types, which is more about picking definitions than about the quality of the language for certain purposes.

It does require defining "useful and effective" for error messages, but I'm more interested in that debate :-)

Two things spring to mind, there are lots more I'm sure.

Racket's macros are unlike any other. They are better thought of as a lightweight compiler API. Check out http://www.greghendershott.com/fear-of-macros/.

Also, the whole #lang framework is a pretty unique tool for experimenting with and extending the language, see http://docs.racket-lang.org/guide/hash-languages.html. For example, used to build http://www.greghendershott.com/rackjure/.

Greg Hendershott does some great writeups, there's more to find on his site.

Indeed it has. For a few more examples, see also http://www.ustream.tv/recorded/43777177, and http://www.ccs.neu.edu/racket/pubs/stackhack4.html. Pyret (http://pyret.org) uses similar stack techniques to these to simulate an arbitrarily deep stack while compiling to JS.

A few more are listed here:

https://news.ycombinator.com/item?id=4986125

This topic has come up before on HN, and I ended up writing up a pretty comprehensive list of ways this can be bound, with references to the spec:

https://news.ycombinator.com/item?id=4986125

Reminds me of an Asimov story:

“But if they have thermonuclear power, where do they conduct the tests and detonations?”

“On their own planet, sir.”

http://supernovacondensate.net/2012/06/23/isaac-asimov-silly...

The best thing about this is that there is emulated thread management via setTimeout going on underneath to allow for Ctrl-C and other interactivity while things are running. No background workers, no running things on the server, this is some single-page engineering goodness.

It implements proper tail calls, too, so it looks like you can run `(define (f) (f)) (f)` forever.

Cool stuff, this is one of the most robust single-page REPL experiences I've seen.

Gradual and optional typing have become a pretty big idea over the last 6-7 years, as language designers have tried to retrofit type systems onto languages that weren't designed with them.

This idea has been showing up in industry (whether the designers call it "gradual typing" or not) with at least Hack, Flow, TypeScript, and Dart (which has optional type annotations).

You can find lots of references for useful underlying theory and research applications (the first paper that mentions "gradual typing" was Siek and Taha in 2006) at https://github.com/samth/gradual-typing-bib.

Typed Racket (http://docs.racket-lang.org/ts-guide/) is probably the best-engineered exemplar of many of these ideas, especially 1. installing run-time checks at boundaries between typed and untyped code, and 2. tackling problems of typing previously untyped code that uses rich class and interface patterns.

Pyret is implemented in JavaScript so we can have a completely in-browser runtime. And since the Pyret compiler is implemented in Pyret, that comes along for free and can be run in the browser as well. JS is far from an ideal compilation target (especially for a functional language, it requires jumping through some extra hoops [1]), but compiling to it lets us deliver the language to students with no installation necessary [2].

[1] http://www.ustream.tv/recorded/43777177 [2] https://code.pyret.org

This worked for the whole first chapter for me (and has some obvious further applications):

    startLevel["constructor"]("m",
    "console.log(m);" +
    "var old = m.placeObject;\n" +
    "m.placeObject = function(x,y,t) { \n" +
    "console.log(t);\n" +
    "if (t === 'exit' || t === 'computer') {\n" +
    "console.log('adding' + t);\n" +
    "return old['ca' + 'll'](m, x,y,t) }};")(map);

EDIT: I wonder if you could wrap the user's code in, e.g. https://code.google.com/p/es-lab/wiki/SecureEcmaScript, and use this to gamify finding bugs in that sandbox :-)

Thanks for the feedback! There are tradeoffs here, and I appreciate that it's a little glib to say things are necessarily right or wrong. I took down the scope example for now, but in relation to the method example, I posted some thoughts about why I disagree on this post:

https://news.ycombinator.com/item?id=6708420

See if that helps clarify my position for you.