A Case for the Pyret Programming Language
pyret.org
pyret.org
This leads to things like desktop apps in node.js (or server apps in node.js, amirite), or high-performance apps in Python/Ruby, or mobile apps in PHP. Given this trend, a language that is very easy to learn/teach will soon take over everything, and, if Pyret is that language, brace yourselves for the oncoming "put Pyret in all the things" revolution.
Once newspapers became large scale phenomena and states began building large bureaucracies, the reality that most people in most areas will only learn one (natural) language became a very unifying (and dividing) dynamic.
Computer science education idealists imagine a world built by the best students, those who finish the entire course of study they set out. It indeed seems logic that the world is shaped by the great mass of people who at the minimum useful level.
You make it sound like it was an ill-conceived goal to make a simple and understandable language, but the reason most of us aren't writing our CRUD apps in BASIC isn't that we all moved to APL.
Programming languages as Basic or Pyret certainly have their place and can empower people that didn't program before, but they won't take over the world.
If you mean something like programming without using the heap, most high-level languages cannot do that anyway.
In this sense, a totally new framework / ecosystem for a known language is as difficult as learning a new one.
(Here it is: https://news.ycombinator.com/item?id=9262770)
An admiring comment: the fact you encoded into the language unit tests close to functions, which is a style choice for some in Python but not mandatory, was very cool to me.
An admiring comment: you talk about multimedia-centric must be awesome. I am language major and failed programmer many times over. I started with C++ on Solaries boxes compiling with g++ over SSH; I was one of the few who started using Linux, not Unix mind you, in Poli Sci school so it was not so bad for me as everyone who would use VS and msvcc, forget to check g++ builds, and lose points (I still did miserably). When I saw samples where you have stdlib tools for integrating into things like Google Docs and Dropbox, I thought wow; these kids are going to learn to make stuff so early, and that is so liberating.
And finally, an obnoxious comment: as a Lisp wheeny, I wish Racket and its toolkit was fast enough, as one of the few who bought Conrad's book and never got around to really amazing Scheme usage.
Still, this is wonderful work. The idea of people building such full environments in JS, stacked on top of transpilers and compilers, is amazing to me as a novice. Not that it's possible, but that it works at all. Every time Pyret comes up, I smile.
Aaarr, keep hacking matey!
UPDATE: Add my previous Q&A and with shriram. You Brown PLT and Racket people are so approachable and smart, damn you !(He says ironically while shaking his fist.)
Firefox performs better than it did, because the whole language has gradually increased performance, but still the worst of the major browsers. It's worth writing down a bit about that here, just for others to see and comment on.
We have some ideas that we suspect will mitigate the main issue in Firefox, which is that Firefox stack frames seem to be very large for compiled Pyret functions. This matters because Pyret's execution control works by (a) figuring out how many "typical-sized" stack frames fit before a stack overflow; this is a little tricky [1], (b) leaving breadcrumbs of metadata on each stack frame, and collecting them on an exception thrown when the limit is reached, restarting after yielding control to the browser's event loop. The issue is that the "typical" frame size for a Pyret function in Firefox means we only get a few hundred frames, and most idiomatic Pyret is implemented recursively, hence lots of pausing and collecting the stack.
It's clear that good support for safe-for-space tail calls is a simple way to mitigate a lot of the issue. We have a version of safe-for-space tail calls that avoids using unbounded space, but doesn't help (much) with speed.
Upcoming safe-for-space tail calls in JS provides one avenue for this that we'll be trying to take advantage of.
Actually compiling instances of Pyret tail recursion to JS loops is something we want to get working. It's a mildly nontrivial engineering challenge in the presence of dynamic annotation checks for return values (which muddy the definition of "tail call", especially since annotations can contain refinement predicates -- more function calls!), the desire to report faithful error information to students, and wanting to yield to the event loop often enough to not lock the page and get "busy script" errors. It's not extremely difficult, there's just enough tricky bits that it's on a branch right now and we're not totally satisfied with it yet.
Since we've largely focused on design of language features rather than performance for a long time now, there's somewhat of a backlog of these kinds of straightforward performance ideas that aren't in the system yet.
https://github.com/WebAssembly/design/issues/189
As an aside, I am a weak programmer, but I love what you guys have done with Racket, especially with incremental language building with #lang directives. I know you could not do that so seamlessly in Pyret, but I love your progessive lang building, progressive type addition. You get the practicalities of pedagogy in language learning by breaking it down into pieces; I wish more people got that and could have succeeded into steering me into double majoring in Arabic and CS. Ironically I was so weak at it after two semesters of C++ only for major intro courses, the enticement of crazy USG machine translation gigs my profs promised me scared me away with my impostor syndrome.
So why say this? How can people like me help with Pyret? I think its web browser JS transpilation are very interesting, and in this age of data visualization and rich multimedia interactivity, I think these tools are the future of language learning, university or not, whether people think it.
I see you guys went so deep with Racket for building blocks of abstract language building blocks, but the Racket people involved in Pyret are sweetening the deal with the notion of tools for practical incentivization with the wep API and media integration.
So, yeah ... sorry to brain dump there. Really enjoyed this post and the work of your lot over there.
What _could_ we use help with? Obviously, we could use infrastructure help or porting to “platforms” (e.g., a REPL on top of Node), but those are huge commitments and require a lot of special knowledge. But I think a person with only a little time can still help.
Right now, I feel the language is still a bit impoverished. We want to make it really easy to get working with data, and that's still too hard. But pretty soon we're going to be putting out better support for tabular data manipulation. Actually use it to do some fun things with data; share your successes (when things work) and your experiences (when they don't)!
But past that it will balloon and just bloat the program you're trying to understand. Tests are better left in their own file. That's not to mention test infrastructure (mocks etc) should you need it.
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.
However, for educational purposes, I think it's actually a compelling idea. My perspective is that while unit tests are a great idea, each unit test only provides marginal value. Thus, unit tests need to be as easy and natural to write as possible or developers won't do it.
Habits, like writing code that doesn't need much mocking, definitely makes TDD easier, but that often comes after habituating oneself to TDD. For students, I think getting them as early as possible to write unit tests would be a big win. Putting the tests right there in the code with no need to set up test infrastructure or learn a separate test framework will be helpful.
Also, mocks are arguably a test-code-smell side effect of too little isolation: https://www.destroyallsoftware.com/blog/2014/test-isolation-...
In my Elixir one-page code experiments, I put the unit test in the same file after the code under test. It makes sure the test only runs when the file is loaded a certain way: https://github.com/pmarreck/elixir-snippets/
I like the idea of short functions with doctest-like tests, but written with the real language, syntax-highlighted, etc. In addition to education, it's good for quick prototyping. It's also nice to see at a glance which functions don't have tests!
But I can also see it getting a bit unwieldy for complicated stuff, so in that case you can put it in another file, perhaps with a pointer.
I'm guessing you can't stop people from writing tests in separate files, so I suppose Pyret allows that.
I guess you could write a unit test framework in Python that does this with a tiny amount of metaprogramming.
def Foo():
return 5
def testFoo(t):
t.assertEqual(Foo(), 5)
In D there is even a keyword for that. It allows to embed the tests into the documentation as examples. This has the nice side effect that your examples are actually tested. https://dlang.org/spec/unittest.html
What we find valuable is to write a _small_ number of _illustrative_ examples, which we call the “sweep”, that summarize the main behavior of the function. Think of it as essential, runnable documentation. When you come to a new codebase (including your own, six months later!), these help you quickly page back in what the function was supposed to do.
The sweep is also really useful for peer-review, which is another especially valuable technique in both education and industry. We have done some nice studies on its effectiveness: http://cs.brown.edu/~sk/Publications/Papers/Published/pcgfk-...
Has it been used for anything else than its compiler?
--Traditional Computer Science question
The compiler is definitely the main application that's been written. We're not aware of any standalone Pyret applications on the order of more than a few KLOC, but those are quite different in flavor, like course infrastructure.
The next largest chunk of Pyret code out there is assignments for various courses and curricula, which are our major users and macro-scale test cases. In fact, this is a useful perspective on what we get feedback from: a broad and shallow set of use cases in education. This leads us to focus on the first-time use cases, especially on the first time seeing an error message, the first time writing a test, the English vocabulary that lines up with explaining code to a number of different audiences (especially at different age levels), and the snags and inconsistencies in syntax in even extremely short programs.
Of course, it's been _used_ by plenty of students and their teachers, who have written now thousands of their own interpreters and video games and graph algorithms and image-generation programs and type-checkers and data structures in Pyret.
Finally, the design of Pyret is intentionally conservative. Pyret is not a research experiment in some particular new and untested language feature; in fact, such features are almost by definition kept out of the language. Therefore, we believe we're building on a long tradition of crisp, clear language definitions inspired by the lambda-calculus, with little by way of weirdness or frippery.
My boss (I'm a developer on a Data Science team. And my boss doesn't suck as a developer. But I do the heavy lifting for the team) just put his 6 year old girl in a google code camp for young girls. They started out with assembly, for crying out loud.
That young girl is as engaged and excited as you could ever expect.
I think that we might find over time that involvement in the nerdy things of life really comes down to environment more than it does aptitude.
Could be entirely wrong. But, you know, I'd like to see a theory that was testable before we toss that out completely.
It needs to be accessible with the teaching resources (whatever combination of teachers/tutors/mentors, books, or what have you) with which it is exposed to neophytes.
Language features can make a big difference in the ease of achieving this, but the right teachers/materials can achieve it with any language.
I don't expect everyone using Pyret to turn into a professional programmer. In fact, I don't want everyone to do so, because the world also needs electrical engineers and materials scientists and poets and painters and plumbers and everything else. So I'm not out to create a planet full of nothing but nerds (in your sense).
But I do think computing is a fundamentally different way of approaching problems. It is not universal, and even where it applies, it is not the only approach. But it's a powerful and new one. I still think nobody has put it better than Abelson and Sussman, who called this “procedural epistemology”. I would like as many people as possible to have access to this epistemology.
Bringing computing to a wide population requires designing something that works for them. I don't claim we have the perfect answer; maybe assembly would work well too, though I have serious doubts (but hey, there's an easy way to prove me wrong: I'm not standing in anyone's way…).
Over a decade ago, long before “big data” was a thing, I created a course called “Introduction to Computing for Humanities and Social Sciences” that was essentially an intro to big data. It's been a very successful course at Brown, and part of its successes, I believe, was my stubborn adherence to teaching the first month entirely in Excel. That attracted, retained, and empowered a whole group of students who by their own admission did not dream of taking computing.
So, the tool does make a difference. Pyret is a tool to tackle our goals. We as a discipline are in the midst of a huge explosion of computing education interest in many countries. A lot of these are _losing track_ of who they are for and what it takes to get there [http://cacm.acm.org/blogs/blog-cacm/200936-qualify-your-quan...]. That's a problem we're deep in the midst of trying to address, and Pyret is central to how we are going about it. Others who think they can get to “all” [modulo the above article] can and will take other bets. It's all good so long as they are actually clear about their goals and then honestly evaluate them later.