I say this in spite of an excruciating experience I had a few weeks ago where I led a Python for absolute beginners day-long workshop. I had tried Repl.it before writing the course materials and was mind-blown at how everything just worked, including the filesystem, which I needed for downloading NLTK modules. I decided to design the materials around Repl.it, letting me spare the class the possibly excruciating and definitely not fun experience of downloading and configuring Python and an IDE. Unfortunately, on the day of the workshop, Repl.it just didn't work for half the class, and for most of the rest, it was really, really slow. Hopefully this was just a hiccup.
We've been battling crypto miners, evil hackers trying to launch attacks, and other nasty stuff. Of course, this is nothing new and we know how to deal with it but I think we just reached a scale where no other truly open computing platform has ever reached and we had to clamp down harder on abuse. Unfortunately, the systems are not very well-tuned yet.
Can you please email me some more info (firstname.lastname@example.org) so we can debug?
Do you know Try it online?
Try it online: https://tio.run/
It’s consistent and Github login saves your code in one page.
Aren't you afraid that class participants will have a hard time configuring later Python and IDE by themselves? Wouldn't be beneficial for them to spend some time setting up their own environment during the class?
BTW I am curious in what way installing Anaconda and starting Jupyther notebook is "excruciating". Last time I did that it went kind of smooth, but maybe there are some gotchas I've missed (it was MS Windows machine, I had a admin privileges, etc.)?
I think techies like us severely underestimate how much of a turnoff it can be to begin someone's computer programming experience by making them schlep through an arduous installation and configuration process. You can promise them "really, we'll just get this right once, and it'll all be over", but that doesn't change the fact that this is their first encounter with programming, and that it will therefore have an incredibly disproportionate impact on how they conceive of the task and experience of programming.
On a first date, would you interrogate your date about their likes and dislikes, childhood trauma, and insecurities? It's probably not entirely wrong to claim that this would pay off in the long term, but there is a good chance that this would strike the wrong tone and prevent a second date.
A coarse metaphor perhaps, but there are some parallels. Imagine hearing someone tell you "You, too, can be a digital magician, and bend computers to your will", and then spending 1 hour bashing your head your keyboard trying to figure out how this Anaconda thing works (I thought I was using Python? What's Anaconda? Is it like Python but different?). If I were in that position again, I think I'd begin to wonder whether this is what programming is always like, and probably wonder if I want to do this after all.
Certainly, as we all know, programming does always involve a great deal of resilience in the face of unsexy unfamiliarity, but there are transcendental moments when you look at what you just brought into the terminal and marvel at how this ever came to be possible, and I think trying to give a taste of that to people in a first encounter with programming with a minimum of pain leading up to it is the best way to make them so excited about programming they'll be willing to continue learning, and yes, set up an IDE and Python installation.
As folks who are fairly proficient in programming, our scales for what constitutes as a "difficult task" can be wildly different from beginners to the field. They haven't built the knowledge, experience and mental representations to accurately determine whether something is hard or easy (case in point: my 9th graders will often propose final projects that would take a group of seasoned engineers months to complete).
After CS classes in college and working in the field, I kinda forgot about the initial setup barriers that I first encountered (and was much more patient to battle through); but after just teaching a single class of middle school students (a) not knowing how to properly install software and (b) as a result, getting into the state of "This is boring ... so I'm going to entertain myself by socializing, distracting my friends, or goofing around" I quickly realized how important it was for these kids' first experience with programming to be painless ... otherwise they would also make my life as a teacher a difficult one.
In my mind, something like repl.it would be ideal for getting through enough material such that the course participants were motivated and knowledgable enough to setup their own environments at a later stage in the course.
1. Hit install on Python and accept the defaults.
2. Install a simple text editor with syntax highlighting.
3. Open a file right on your desktop and type two commands in it and press F5 or something to run it.
Anaconda and Jupyter are great tools, but even they add complexity you don't need when teaching absolute beginners how accessible this can be.
Here's Python. It's installed. Tell the computer what you want to do inside a file. You understand text files and how to store them where you want, use your own conventions for that. Shove it in documents or whatever. We'll learn about project management and version control later, when you're writing programs more than 20 lines long.
There's so much stuff included in the basic installation from python.org. And it all just works.
The only thing missing from the basic installation is psycopg2 for talking with PostgreSQL.
And IDLE has always left me unimpressed relative to the terminal... but using Unicode on Windows, suddenly code pages get involved, which no one should ever have to know. There is a long series of subtle, unpleasant tradeoffs.
Writing short Python scripts when I traveled with a Chromebook was messy, I leaned on repl.it as one option... It was super easy to dive in.
Disclosure: I’m the CEO of GitLab and we’re looking at live coding ourselves as well.
But, if they don’t, here’s my take.
To me it seems like this is something that would be built in-house with the ability to leverage repl.it’s existing application infrastructure. I’d imagine this would simplify the development compared to the vscode plugin. (stand-alone desktop app)
Also, long-time gitlab-CE user here. I’d love to see multiplayer as a feature.
I've been evaluating ShareDB for a Google Docs-like and it seems promising.
The OT space is really interesting. For those wanting to read more about it, check out the paper: "Operational transformation in real-time group editors: issues, algorithms, and achievements"
Bit of an aside: I used to take notes and share code using SubEthaEdit which pioneered this sort of collaborative editing over a decade ago. While it’s now pretty normal to see students taking collaborative notes in classes using Google Docs (and etherpad before it was acquired by Google to improve the experience in Docs), it was astonishing a decade ago. I recall spontaneously loading it up at an early Rails conference and taking notes with a bunch of strangers (it advertises open docs over the LAN). It was a noteworthy enough experience that one of the collaborators blogged about it. 
It was heartening to learn that SubEthaEdit was made free and open-sourced a week ago. 
 Alas, the coloured formatting didn’t survive the blogrot http://www.zenspider.com/ruby/2006/04/canadaonrails-day-1-sh...
Hard to believe 7 months have already gone by since I was working with you on this prototype! I took a peek at some of the websocket messages, and I'm glad to see its come a long way since I last saw it :-D
This launch seems to perfectly cover the vision of collaborative coding that the repl.it community has been clamoring for!
I hope you like it and I hope it's helpful to you and to the people you teach. Let us know if you have feedback or ideas, I would love to hear them.
What does this do that VS Live Share  in VS Code doesn’t? Seems like port sharing + tty sharing has this covered.
If you go the vs coderoute everyone needs to set up there system to match. Using node? Which version of node? Or which version of python.
And everyone sees the output of the program when anyone clicks play.
The host shares their TTY and ports, all the clients see everything that happens in the host’s TTY (read-only) and ports (r/w on localhost.) Code editing syncs in real-time to the host machine P2P.
I really like Colab by Google for a web based one, and if you have VSCode installed, their Live Share extension is pretty solid 
Since people are recommending other multiplayer-stuff I'll recommend Live Share for VS Code . It is so useful that I've shifted to VS Code (with my teammates) for some projects just for the live sharing. I've tried Floobits (to be able too keep my regular editor), but that seems much more elaborate with persistent "projects" which is not really a fit for my more casual use case.
It's pretty cool and it addresses a need that we've found missing as well -- live code editing is half the feature, what's also important, is that the REPL state be synced. It's a coincidence that we both picked the same name!
In addition to sharing code and a REPL, it also allows you to collaboratively edit HTML, CSS, web pages, etc. Really cool talk!
Obviously not quite as good for many reasons, but possible.
Apparently it is do-able with a little effort, but man I'd love for this to be a standard feature. "Hey Jim, I just pushed to the funky-broken branch, can you take a look and help me solve it?"
So when I've run out of free pads I've switched to repl.it + screen sharing, but it's not the same as simultaneous editing.
Really happy with it.
It's worth noting that excellent folks at Coderpad have a lot of features that complements the editor too -- I've used it while at Facebook -- so we're not trying to compete with that.
The amazing utility of being able to see the location of everyone's active cell, and seeing each person as a different colour, was just wonderful. Combined with a voice channel and it was more useful than a face to face meeting in a conference room.
This inspires me to try to get the editor sharing running for my tiny DevOps team.
This was on the first try. :-(
It's funny, it's both a regression and an improvement. We started using XTerm.js with a PTY and we stopped throttling output which reintroduces the "browser locking up from too much output" bug. We'll need to introduce backpressure.
We'll be open-sourcing some more. As for how Multiplayer is implemented, we'll be doing a blogpost on it soon.
Sorry to be the license police, but I think that the attribution for embedding another project like that is a little unfair to the original authors, especially since this project is the more restrictive GPL 2.0.
"The fourth paragraph says that the copyright notice in the second paragraph must be reproduced. Users of the license [sic] substitute the [fullname] with their actual name. That is what constitutes "proper attribution" in the mind of the MIT: every user of the software can find out who wrote it if they want to."
All the examples are synched
Needing SSH access, valid user accounts, and various permissions meant it was always viewed as a hassle rather than benefit.