451 karma · joined July 29, 2012
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.
http://www.ccs.neu.edu/home/matthias/manifesto/sec_pl-pl.htm...
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.
Issue for (3) reported here: https://github.com/education/classroom/issues/250
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?
http://docs.racket-lang.org/web-server/stateless.html#%28par...
http://cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-...
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...
http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-mi... http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-me...
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.
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.
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 :-)
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.
“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...
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.
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.
[1] http://www.ustream.tv/recorded/43777177 [2] https://code.pyret.org
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);
https://news.ycombinator.com/item?id=6708420
See if that helps clarify my position for you.
- Reporting failures can more easily report context about the function being tested
- Since "where" blocks are actual blocks, we define helper functions and variables inside them that don't need to clutter up the namespace of the current scope
- It's easy to turn the assertions on and off; for example when importing a Pyret module we skip running the checks of that module by default.
- The localized information also plays into our story for type inference (which is work in progress), but starts from the unit tests in the where: block to figure out what the programmer intended for input/output types.
Re: scope, you're right that using "def" the way I did isn't very idiomatic Ruby, but I always run afoul of it because it looks so similar to what I'd write in another language. I took that example down for the moment; I still have a personal gripe with it, but my "fundamentally broken" language was a bit strong. If I think of a more illustrative example, I'll put something back up.
The currying example I still think is weird in Ruby, and it's because it interacts bizarrely with the syntactic choice about optional argument lists. The thing that is wrong with JavaScript and Ruby is that they both have dot expressions and application expressions; o.m and f(x). It looks like
o.m(x)
should be a composition of dot lookup followed by an application, since both of those raw expressions make sense on their own. But in neither does the decomposition actually work:
m = o.m m(x)
There's no state or funny mutation going on here, but a simple kind of substitutability isn't working. JavaScript does it especially poorly, and Ruby has this awkward inability to decompose because of its choices about application syntax. Now, in Ruby I'm aware that with or without parens are actually both method calls, so it's not like there's a field access and an application in the underlying language model. But Ruby then adds the syntactic convenience of no arguments to make it look like access is possible, but that syntactic convenience is a bit of a leaky abstraction.
I should note that Python actually gets this nicely right IMO, and dot lookup curries self so this works out.
The underlying thing that irks me and I'm calling out here is the non-compositionality of what looks like two expressions that should compose. This is something we felt like figuring out and getting consistent for Pyret.