I injured myself ~20 years ago because of Corewars (well mostly stupidity, but Corewars was involved).
I wrote a little evolution routine that would take some corewars code and randomly change instructions around to see if it couldn't evolve a more successful program this way.
I let it run for hours and hours, and it did come up with short programs, and I was eager to see how it would continue. It happened that I needed to install a new light fixture in the same room as the computer... can you see where this is going?
Well, I didn't want to turn off the simulation, so I figured that if I instead just turn off the lights, then even without flipping the breaker for that room, I could be sure there would be no live wires leading to my new light fixture.
I was standing on a long stool and was about to start screwing in the light fixture to the ceiling wires with a lustre terminal and bam, I was hit with 220 volts.
I thought the only outcomes from getting electrocuted would be to either die or survive, but I discovered a third thing that can happen: I lost a bunch of color in my skin, and it never came back.
Lessons? Be careful with electricity, and try not to get too obsessed with Corewars.
1. Save your progress to disk periodically -- for a genetic algorithm, that will be the seeds passed to the next generation. That way, you'll only lose one generation if you need to unplug your box. As a programmer who does any amount of research, this is a superpower. Godliness is achieved when you automatically commit this data, summary metrics, and the code that generates it into a git repo.
2. Invest in a UPS. If you need to do a project that will take longer than your UPS will last, you can just move the box & UPS onto another circuit.
But, yes, be careful with electricity. Lessons from my grandpa, who survived all of his live-circuit edits and died of lung cancer:
3. Wear rubber-soled boots.
4. Keep one hand behind your back.
5. Use rubber-handled tools and do not touch the metal bits.
6. If a ladder is necessary, it should be non-conductive.
7. Equip your child with a 2x4 and give them the instructions to pry you away from the source of electricity with that, and to not touch you under any circumstances.
0. Get a non-contact voltage tester. Always assume mains wiring is dangerous, unless it has been checked. And always assume the voltage tester is lying to you, unless you've verified it at a known live wire at the beginning of your work.
The final event that led to the accident was,
> so I figured that if I instead just turn off the lights, then even without flipping the breaker for that room
If a non-contact voltage tester was used, it could be prevented.
Turning off the light switch without flipping the breaker can be safe if there's no energized wires nearby and no miswiring.
Also of note is that in some regions it is apparently common to run the power to the fixture itself, then extend down to the switch. Which means there will always be hot wires at the fixture unless the circuit is shut off.
My experience with this comes from people who were from the southern US and who found it very weird and even at first insisted it was "wrong" to run the power to the switch then to the fixture. My theory on where this comes from is that this is a result of most homes in that area being built on slabs and so the power feeds are generally run through the ceiling. Whereas locally most buildings have basement/crawl spaces so the power feeds are generally in the floor then run up the wall to the switch and extend from there to the fixtures.
Addendum to your point zero—test against a known live wire before _and_ after if you want to be really cautious. It’s possible the tester failed after your initial test, but before you checked the wire you actually wanted to test.
For example, imagine some batteries on the verge of death. They may keep enough charge initially to test right after being turned on but quickly die before you get to the actual wire under test.
I'm not sure why you would think that my suggestion is "suspiciously good". Your suggestions included rubber boot or keeping one hand behind your back, which are what a grandpa would tell you as precautions when working on a potential live circuit. And my suggestion to double check whether a circuit is really dead before working under such a "deadly" assumption is arguably more important.
> Personally, I take a radically different approach to household wiring: hire folks who know better than gramps.
I never suggested otherwise. In a qualified household wiring, all switches are correctly wired, thus turning off a light switch and touching an exposed wire is as safe as turning off the breaker. And there won't be hidden junctions in the walls waiting to be burned up. And a single earth leakage doesn't kill the power of an entire home... - these properties are what you definitely want.
My point is not to assume anything while working on an existing system. I test live voltage even before I replace a lightbulb - you don't have to mess up the entire wiring of your house, a single miswired light socket can be just as dangerous. Fortunately, so far I've never encountered a single case where the light socket is live after opening the light switch, nor a single case where the metal thread of the light socket is live, which gives me confidence that the wiring at my home was probably in compliance. I simply don't assume.
I remember being in the attic with my Grandfather. He touched a bare wire and said something like 'wooee - That was 220.' I figure I've drawn heavy out of the luck bag already in my life with electricity.
I did a similar thing (the evolution of corewars code bit-- not the light fixture bit) after reading Steven Levy's "Artificial Life"[1] in the early 90s. The chapter on Tom Ray's Tierra[2] really excited me.
Some people say that reading Richard Dawkins caused them to become atheist. For me, it was very clearly "Artificial Life" and the code I wrote playing around w/ "evolving" Corewars code.
I managed to eek out a little "evolution" in my experimentation. I was never particularly religious to begin with. My simulation code caused me to deeply consider the power of evolution. Here was this tiny change, evolved from randomness in a minuscule virtual "petri dish", out of a tiny amount of ingredients that were brittle and unforgiving of the slightest change, on a time scale that was the smallest fraction of a fraction of the age of the universe.
Observing the sheer magnitude of the chemical "parallel computing substrate" at the scale of atoms and molecules, interacting in real time, across a space as large as the Earth, in a timescale measuring billions of years, and over a wide variety of temperature and energy gradients made me aside any concerns that all life couldn't have arisen from randomness.
I didn't need an "intelligent designer" after that. Nature, the vastness of space, the minuteness of atoms, and the overwhelming scale of time were enough.
This must have been in the air 20 years ago. I wrote a tiny (not published, not peer reviewed, not very good) paper about parallelizing core wars for evolutionary search about 19.5 years ago: https://www.angio.net/res/garden.pdf
> Corewars proved itself really, really hard. Learning the assembly commands and how they edited the A and B values of each memory cell, understanding how the processes were executed and how data was stored was incredibly challenging for students to wrap their heads around.
This surprised me. I wrote a Corewars system in compiled Basic for the Sinclair QL when the game became popular. Writing it was not particularly difficult and the toy machine code was very simple. Maybe it was the context: we were used to look at bits and assembly instructions, we're not anymore.
When I read the intro, I was like „They want to teach beginners with Corewars? That‘s brave...“
I really like the idea of Corewars (and programmning games in general), but I never managed to get into it because the whole concept of assembly language was too foreign for me. I would have had to invest too much time up front, just understanding the basics.
I understand the feeling. However you can play some puzzle games that are much more difficult than the assembly of MARS. Furthermore any simple machine language traslates pretty well into a basic version of C: add, sub, pointer operations, bitwise operations, compare a value with zero and possibly move the program counter to a memory location, copy memory from RAM to a register (think of it as a predefined veritable). Everything is an int, maybe a float. All very low level.
Maybe. I don't remember there being 30 instructions either though. We need A RISC Core Wars. (Although he did mention a reduced set of commands still took 1.5 hours of hand-holding....)
> we’re thinking a little bit about a Git Version Control or github-esque software for storing, documenting, sharing and iterating on curriculum
That could be wonderful.
There've been attempts at creating sites for customizing OER texts. But creating communities is hard. Especially as a closed-source VC startup.
It might be nice to support transclusion. Sort of the textual equivalent of importing a code library. So one might say "insert here, that introduction to topic X", and have it track someone else's iterative progress on introducing X.
[op here] - Yep, when we stumbled across this idea we really, really liked it... however, this appeared to be a really neat solution to a problem that didn't actually exist.
Lots of profs are super busy with grading, securing tenure, research, and ultimately don't really care that much about the fine details of their course content.
Motivating profs to document their entire course, class by class, with teacher notes, is really hard.
Here's an example of an olin college course opened up to the public ... it's a pain in the ass to make a course 'teachable by others'.
https://courses.olin.edu/e4h/
Also on top of the above barrier, +1, creating a strong community out of profs who care about teaching would be hard.
Well, creating good education content is certainly an unsolved problem, but nod.
> document their entire course, [...] is really hard
That was the MIT OCW experience as well.
Hmm... thinking aloud...
I wonder how hard it might be to do bulk ingestion of existing OER content to seed such a literate-programming/github/npm but-for-text platform. Slice-and-dice and index, so it's immediately useful for easily pulling together custom content. Though profs creating slides are unconcerned by copyright, so obtaining material by googling seems likely easier than even well indexed ingested OER content.
And the challenges of an accessible UI are not small. One of the unrealized potentials of OneLaptopPerChild was having a community that mixed domain experts with software devs, so one could look ahead to a much lower-barrier MVPs for collaborative content creation. Hmm, so what might motivate people already skilled at git-horrible ui to work on text...?
Perhaps one could find some content niche which somehow inspired people to work together, using a platform with good bones, but without a so-hard-to-make broadly-accessible GUI. For illustration, introductory astronomy courses are common, and best-selling textbooks don't even bother to get the color of the Sun right. So one might imagine the astronomy community, which has coding skills, getting enthused by a "finally, an introductory astronomy textbook which isn't wretched". Or no, maybe not so much. It might be interesting to learn which OER textbooks have achieved wide use, if any. Use them as a market probe for communities which are already receptive to an OER-shaped effort? And hope one of those communities has unmet authoring needs, and the skills to tolerate an MVP ui. Ah well, thanks for the thought exercise.
Adi here -
Thanks all for the advice, comments, support, and tips on ... not getting electrocuted(?)!! It's been a while since I've worked on the Corewars in India project so I'll answer some of your questions the best I can :)
Have been an HN lurker for ~1 year and it's super exciting for my first post to hit the front page! Looking forward to posting more interesting projects in the future!
CoreWars is probably the most interesting programming game ever made.
Yes, I've played Zachtronics games like TIS-100, Shenzen I/O, Exapunks. No doubt those are super fun addictive games. As a programmer who still ocasionally write assembly code for fun, nothing beats CoreWars, though :)
I love your story and am glad to see the next generation of computer scientists thinking about education. It's a huge problem that is nowhere close to solved. I worked as a founder in the ed tech space for around six years and sold two profitable companies, so hopefully I can give you some insight after checking out the actual game.
I really think you need to introduce each concept sequentially with periodic reinforcement, as it is impractical to expect any student at any level of education to read through an entire embedded Google Doc with instructions before playing the game. I sincerely believe you could take this concept to an actual product if you work on the engagement and adaptive learning aspects.
Just to get this out and validate the concept is an achievement in itself. I worked on all kinds of failed prototypes before finding one that worked. I am sure you guys are going to do great things!
Heyo - OP here, thanks for the kind words. Periodic reinforcement and having a video based / more interactive guide than just an embedded gdoc would all be super useful in helping kids learn faster and get to a competitive level quicker ... but with that said, Corewars is not a great game to start teaching kids with limited coding experience by any means. It's too hard to pick up - other games would serve this purpose much better.
However, if we ever hop back into the edtech space, we'd certainly be interested in chatting with you at some point :) Cheers
I think the introduction can benefit from breaking up the instructions into bite-size/progressively-difficult sections with optionally videos demonstrating them.
> we decided to move forwards with a game based software that:
> Would have a low ‘barrier of entry’
> Be easy for students from any background to pick up
> Be visual and simplistic to wrap your head around
> Have some level of a competitive / addictive nature and well defined metrics of success
...
> ... For the frontend, we had to create a clear visualization of what the processes were doing, and also had to build a UI that allowed for intuitively creating programs in Redcode. The latter was especially important for us as the goal for this project was to require as little technical experience as possible, and we also knew that Corewars was a challenging game.
This sounds like a typical case of listing your requirements (low barrier to entry, easy to pick up, simplistic to wrap your head around), but picking something that doesn't satisfy those requirements (a challenging game) while thinking that you can make it work somehow (build a UI to make it more intuitive).
I'm not surprised they ran into a problem with that approach.
> ... Before deployment, we’d assumed that Corewars could be learned and played by students at a semi-competitive level within a sitting. Even with the beginner mode that featured a scoped back set of assembly commands and high visibility into the game’s processes, it took Adi an hour and a half of 1:1 teaching time within the groups to get them comfortable with the game. We can estimate from this testing it would take students ~3 hours to learn the game individually, and another ~3-4 hours of logical challenge questions to get to a competitive level.
(I think those numbers are more likely to be underestimates, except for students with a lot of prior knowledge.)
My high school CS teacher assigned writing a Corewars interpreter as a project, likely because he thought it would be a fun way to expose his students to assembly language. I did enjoy it, but most other students were already pretty lost just trying to understand how programs were executing in the reference implementation, let alone writing their own interpreter.
I think something like AntMe ( http://wiki.antme.net/en/Main_Page ) would've been a better choice of programming game (I only have experience with the two my CS teacher tried on his students, so it's likely I'm missing something better): the game world is an abstraction of physical reality, so it's not hard to visualize, and there's a variety of tasks of different complexity (from just making the ants walk around like LOGO turtles, to foraging for food, to waging war against other ant colonies).
[op here] - thanks for the recommendation, we'll check out AntMe.
In hindsight, Corewars was a stupidly hard game to try to teach the intricacies of in a few hours, and because it's based in Assembly it's also mostly irrelevant to 98% of modern day programming students or new grads will be exposed to.
However, as an experiment in UI design and offering a visual portal into the internal game mechanics, this was a dope project.
First - I strongly agree with everything you said. It's a steep learning curve to climb for something that doesn't really relate to any prior computing experience a typical student could be expected to have today.
The teaching time will go down if they stick with this - they'll learn what the common errors are, what the common conceptual misunderstandings are, and how best to present the material to their students. The 1 on 1 tutoring they did this quarter (hopefully) will have given them a lot of insight into what the student experience is like.
It looks like they mostly learned a lot about teaching, and how their educational system in particular works. If they're hoping to keep working in the educational space these two things alone will make their time worthwhile.
Anyways, it's a really interesting article by people who are both passionate about and new to teaching - it's a fun read.
This entire project really exposed us to some of the challenges of the edtech space - mainly how solving the problems of the current edu system and making an edu product that people want rarely actually overlap.
But regardless, developing a sort of custom curriculum for those couple hours of 1:1 teaching and refining that curriculum on the fly, and seeing what concepts kids picked up quicker was super interesting and honestly one of the most rewarding parts of the project.
> we’re thinking a little bit about a Git Version Control or github-esque software for storing, documenting, sharing and iterating on curriculum
> Most of the professors we talked to [...] appeared mostly ok with the status quo.
Don't underestimate how wretched our own system is. Or how widely that's underappreciated. And thus how awesomely large the potential for improvement. Even if societal payoff is unclear. We're educationally leaving a lot on the table.
Compared with systems with an even greater emphasis on rote learning, yes, we're better at creativity and problem solving. But...
Numeracy? There's almost a century now of professors, across several fields, complaining to their field's journal, about PhD candidates without a feel for reasonable numbers. And there's a funny famous example of an ideal-gas-law chapter question, that persisted for many editions, years, and much use, with numbers describing solid Argon. Ok, so maybe just a typo? And whole lot of student and professorial mindless plug-and-chug? Have you ever seen a question, where it was the students responsibility to judge which simplifying ideals were valid to apply? We just don't do that. We could, but we don't. It's not a thing. So students just can't do that. We're toy problem solving and innumeracy.
Firm grasps? A wizzy teacher of intro genetics at a first-tier university, was asked what they would most like improved about their incoming students, and replied, a firmer grasp on central dogma. Something that can be taught in primary school. But firm grasps aren't something we do well.
Robustly integrated understanding? Versus Trivial-Pursuit collection of factoid fragments? Ask first-tier astronomy graduate students "a 5-year old asks, what color is that hot ball, the Sun?" and then "and sunlight?", and you can expect a wrong answer to the first, and right to the second. Sometimes followed by a pause, and a "that doesn't make sense, does it?". Two incompatible factoids, perhaps first learned in kindergarten, seemingly colliding for the first time, two decades later in grad school. And of the few who do get it right, half-ish (but small N, and at an institution strong in astronomy education research), half-ish report having learned it in a class on common misconceptions in astronomy education, rather than their own, atypically extensive and successful. After all, most all of the most-used introductory astronomy textbooks also have it wrong. And then Kahn Academy makes videos based on textbooks, and surprise... not. We don't do integrated understanding.
How can textbooks be so bad? Science education content is a very distinct thing from science, or even from science education research. It's under very very different selection pressures. And has nothing like science's infrastructure and culture. Physics education research folks tell a recurrent story, of physics colleagues who are solidly empirical in their work, but in teaching? "My trusty gut says it works!" A very large textbook company onboards its science education writers with the reassurance that it's ok you've a BA and no science background at all, because there's a "scientist" on call for consults. Expecting science-like properties of science education content seems to me a scope-of-competence inference error. Like "You're a Scientist? Then you'll know <arbitrary topic>", or "You're a Doctor? Yes, of medieval french literature. Good, I've a question about my surgery", or "My local TV meteorologist explained why climate change isn't real". So why would you expect astronomy textbooks to get the color of the Sun right? Why would they? No one is going to be embarrassed in front of their peers, or fail to get tenure, by getting it wrong. Science education has "science" in the name, and some overlap in individual personnel, but nothing like the social constructs which get us from the work of individual researchers to science and its aggregate properties.
On a more upbeat note, when MIT created a VR cell biology sim, gathering domain expertise by pulling in researchers for interviews, there was a problem... getting the researchers to leave. So despite oft-cited meager funding and lack of incentives, there seems at least a possibility pulling in expertise, if project pragmatics and goals have a right shape.
Fond memories of fiddling with Core War after the article in Scientific American.
I wrote a little evolution routine that would take some corewars code and randomly change instructions around to see if it couldn't evolve a more successful program this way.
I let it run for hours and hours, and it did come up with short programs, and I was eager to see how it would continue. It happened that I needed to install a new light fixture in the same room as the computer... can you see where this is going?
Well, I didn't want to turn off the simulation, so I figured that if I instead just turn off the lights, then even without flipping the breaker for that room, I could be sure there would be no live wires leading to my new light fixture.
I was standing on a long stool and was about to start screwing in the light fixture to the ceiling wires with a lustre terminal and bam, I was hit with 220 volts.
I thought the only outcomes from getting electrocuted would be to either die or survive, but I discovered a third thing that can happen: I lost a bunch of color in my skin, and it never came back.
Lessons? Be careful with electricity, and try not to get too obsessed with Corewars.