Maybe AI was involved, maybe it wasn't. I don't know. But the author seems to know what he's doing, rather than someone just giving Claude a task and posting the result to GitHub. He talks through some of the challenges in building this, some of the different implementations he tried, the kinds of bugs and crashes he hit, and ultimately what worked and what didn't.
This is exactly the kind of stuff I love. Another comment said Claude has killed interest in crazy projects, but for me, as someone who likes to hand-craft some "why would you even think of that?" projects from time to time, discovering his repositories and YouTube has made my day.
This was posted on hackaday[0] last week with a link to a youtube video. In the video, the author of the project goes into depth about some of the challenges they encountered and changes they made in good technical detail.
I think the complaints in this thread are not in the spirit of HN. Let's do better.
It's quite interesting, and describes how the developer used COBOL to implement a raycasting algorithm and generate a stream of PPM images to to pipe into FFplay. There's zero evidence of this being written in Claude; there are multiple clips of the developer working in VSCode, where the Claude plugin doesn't even appear to be installed.
It would be nice to have screenshots. Also it’s just a single commit, did you use AI? Quoting the readme: “FPS.cob is what you get when you decide that game development is too easy nowadays”.
It’s also OK to be turned off by AI use in hobby projects and it is also OK to prefer disclosure of the use of AI in projects so I can make that choice.
As a few people have asked for screenshots, I spun it up. Here's a video of the basic gameplay: https://peterc.org/misc/fpscob.mp4 .. it's clunky, but it does play.
We need to start putting guardrails on hn to not allow those esoteric projects to be published.
Before ai, it was impressive that a person has that much passion and dedication to go down the rabbit hole, and it usually comes back with some cool anacdotes that are nice to read.
Today, it's shallow, emptied out of the content.
It's not impressive that Claude wrote it, it was impressive if you have written it, OP.
> It's not impressive that Claude wrote it, it was impressive if you have written it, OP.
Do you have evidence that it's Claude written? Looking through the source it isn't clear to me, at all. Plus, even if it _was_ Claude/LLM assisted, why does that take away from the project?
It's like being offered a big mac at a fine dining restaurant. Yes, big mac is gonna taste fine, maybe you can dress it up nicely even. But the restaurant didn't make it, and you feel cheated for buying it (and in this case, wasting your time thinking someone coded it).
Something just existing isn't the same as something being made by someone with passion and effort beyond a one-shot prompt to Fable 5.
Because it is process that matters, in such projects, not the outcome. E.g. it is fascinating how one manages to port and run Doom on some microwave led screen... But nobody is going to play it eventually, it is not relevant as the "end product".
You have to remember that this forum is for people who have a passion and an intellectual interest in coding and development, and discussing such with like-minded people. Stimulating intellectual curiosity. An interest in what humans think and do is an implicit part of the experience.
An engineer vibe-coding a project generates an end product, yes, but what is there to be interested in or to discuss? Chances are said engineer isn't even capable of discussing the project in any depth. Are we going to be left discussing nothing but prompts and Claude workflows, and how we got the black box to do a thing? OK. Who cares? I guess we can all politely clap and move on.
I don't know if the posted project was written by an LLM or a human, but I have to agree with localhoster than AI has sucked a lot of the joy out of a lot of HN.
How this isn't causing an existential crisis in fellow developers, I don't understand. We're seeing our craft dissolve day by day, to the point where even our forums are filled with AI generated crap that we just don't find interesting or engaging.
It is. People have posted threads about how they hate that AI has sucked all of the joy and fun out of their work, and they can feel it rotting their brains, but they just can't not use it. Either because their employers require it or because the compulsion to minmax and optimize their "productivity" overrides all. The dialogue they have with themselves and with HN is a lot like the dialogue someone has questioning the tenets of their own religion.
Aside from that, I don't want to take responsibility for that which I don't understand. And even if I can read the code generated by a LLM, that's not the same as thinking through a solution or planning a design.
You can't call yourself an "engineer" if you just open Claude or Codex and hit "Y" on the keyboard to every prompt like that dipping flamingo when Homer Simpson took the wfh job (Simpsons predicted it).
I am facing that very dilemma. I lean more to the anti-AI side, I don't want to get my skills atrophied by relying on it, but I recognize its potential productivity boosts as tempting to use.
> An engineer vibe-coding a project generates an end product, yes, but what is there to be interested in or to discuss? Chances are said engineer isn't even capable of discussing the project in any depth.
And this is reductive to the point of absurdity.
Everybody screaming about AI forgets the fact... you STILL need the domain knowledge. That's where the value in engineering is now.
Imagine a wanna-be game designer thinking they can fire up codex or claude and even with a few weeks and a few hundred dollars in credit, coming out the other side with a game anybody would want to play.
That's not how it works.
I tried with godot. I can tell you everything you want to know about programming/networking/DevOps, and daily use that knowledge. But was very very quickly overwhelmed with the things I DON'T know about game design and development when I tried to develop retro-DQ clone in space.
I don't think Claude wrote this, even so, it's still cool.
I'm not proficient in COBOL, although the README.md is very human generated, its not verbose at all.
I saw the recent "would a slop button be useful in addition to flags?" and my immediate response was "only if I can also flag people whining about slop.
Frankly at this point, it's just as insulting to claim it's shallow and worthless just because Claude did it.
If there is a cool project that comes out the other side, who cares? I am forced to use Claude for day job, and while it's annoying, I am running at a pace that can keep up with my brain, not just what I can shit out and get tested and inevitably miss things. Because you know what's great?
When you have actual controls in place like Jira ticket integration, CI/CD steps that can be considered, but the overall change is small, how many more of those small changes do you think I can get done in a day versus before it? But hey, localhoster says it's shallow and empty of content, so it must be true.
A passion project of mine has been to develop a full decompilation and a randomizer for Neutopia. I've been working on this multiple years. I had it at a point where I had chests randomized, item grants, etc, but that kind of turned into a lame game because of how the existing Neupotia game works.
It's been stuck at 40% for just as long. I pointed codex at it, and now I'm at the at least 85-90% and will have it done within a few weeks.
Given Neutopia is a much smaller target audience, but when this project is released, it will at least as capable as http://alttpr.com/en, and more capable in some ways as random dungeon and overworld layouts are already possible, not just reusing layouts and changing chests.
Codex generated a big chunk of it, so it's clearly a horrible idea and piece of crap not worthy of localhoster here.
Exactly. But the damage is done. I find nothing anyone does in tech impresses or interests me anymore. The only things that interest me are things I’d like to also do myself. I imagine it’s probably the same for a lot of other people.
Like OK someone vibecoded an FPS in COBOL or Pokémon emerald in a web browser with web assembly? Ok good for them, piss off karma farmer.
> Like OK someone vibecoded an FPS in COBOL or Pokémon emerald in a web browser with web assembly? Ok good for them, piss off karma farmer.
Sorry, but most of these discussions reek of extreme gatekeeping. First off, neither of these things are impossibly difficult and are easily doable with some dedication by hand. LLMs simply accelerate the process, the human still has to come up with the architecture, _idea_ and plan to do something like this.
I think what we’re seeing play out in this thread is the devaluation of software engineers. If a growing number of people have the sentiment that an engineer vibecoding an idea has less value than a human doing it then that is all that will matter in the end.
That’s the inevitable result of machines being invented that can largely do our jobs. Just like how artisanal products are often prized over factory productions. The effort put in to and the organic quality of products have pretty much always been of value to consumers and appraisers. “I clicked a few buttons and look what the machine produced” will never be as impressive.
> If a growing number of people have the sentiment that an engineer vibecoding an idea has less value than a human doing it then that is all that will matter in the end.
Because if you put them on balance that will be the truth.
If an “artist” comes up with ideas for some artwork then just prompts it out with an LLM I am similarly not impressed, and never will be, even if the image looks cool. It’s a cool image, not an impressive effort. That’s all these code projects are. Shiny objects.
I remember being taught in my COBOL class (early 2000s, needed an elective, thought it would be fun) that that was the point.
The stupid engineers could write the code like the grunts they are, and then the manager could read it and verify that it was correct without having to know how a program.
That wasn’t exactly how it was put. And there are obviously some assumptions in they are on how good a job a manager who doesn’t know how to code could ever do.
I had to get into an old tcl program for work recently and had the same thought. I wouldn't necessarily pick it today but it was kind of nice in a way that's unfamiliar to me from modern development.
Tcl 8 introduced dual-ported objects. Everything can exist as a typed object that is convertible back to a string in certain cases (some form of string operation typically). That plus the bytecode engine makes it work completely different than prior releases.
No. Tcl is all strings from a language point of view. To your Tcl code, everything is a string.
Internally in the main Tcl implementation, it isn't just strings. It's a bit cleverer so it can be faster. But that is completely invisible to the Tcl programmer.
JavaScript is not just strings. It has real types (even if it is happy to coerce them to strings at the drop of a hat).
To put it another way, JavaScript has `typeof` which returns the type of an object. Tcl doesn't have that because the answer would always be "string".
> ::tcl::unsupported is a namespace that contains bits and pieces of Tcl that are experimental, not intended for production code, perhaps useful for debugging and introspecting Tcl, and liable to change or removal without warning.
One of the things I like about it is he had to create a little front end to display the game, mirroring actual COBOL practice. Until the 80s or so, COBOL didn't support meaningful terminal I/O in its own right; it was all batch. If you were a mainframe dev and wanted to do terminal interaction, you either had to write your own routines for that in mainframe assembly or use something like CICS, IBM's application server which provided its own terminal handling and transactional database routines accessible through a language extension which got swizzled into regular COBOL by a preprocessor. Creating a layer outside of COBOL to do the things COBOL was deficient in, and using COBOL's regular I/O to communicate with it, is peak mainframe-era engineering.
Other solutions to the same problem existed; there was one called InterComm, which lacked the preprocessor and required you to reserve a shared area of memory and write messages to InterComm directly into it. These days there's KICKS, an open source library API-compatible with CICS, aimed at the sort of person who faffs about with old software on Hercules.
That just gave me flashbacks. I wrote code on some ancient stuff that operated like you describe InterComm. Haven't done that in years, and I don't think much of anyone uses those systems anymore (Harris H100).
The author has a number of repositories going back 3 years that seem purely experimental and, to me at least, really fun to look through.
https://github.com/icitry?tab=repositories
And he has a YouTube channel linked to his GitHub. Here's his video on the development of this project:
https://www.youtube.com/watch?v=qzpZQe7JT-o
Maybe AI was involved, maybe it wasn't. I don't know. But the author seems to know what he's doing, rather than someone just giving Claude a task and posting the result to GitHub. He talks through some of the challenges in building this, some of the different implementations he tried, the kinds of bugs and crashes he hit, and ultimately what worked and what didn't.
This is exactly the kind of stuff I love. Another comment said Claude has killed interest in crazy projects, but for me, as someone who likes to hand-craft some "why would you even think of that?" projects from time to time, discovering his repositories and YouTube has made my day.
Thanks for posting this, MBCook :)
This was posted on hackaday[0] last week with a link to a youtube video. In the video, the author of the project goes into depth about some of the challenges they encountered and changes they made in good technical detail.
I think the complaints in this thread are not in the spirit of HN. Let's do better.
0) https://hackaday.com/2026/06/06/a-raycast-fps-in-cobol/
Direct link to the video: https://www.youtube.com/watch?v=qzpZQe7JT-o
It's quite interesting, and describes how the developer used COBOL to implement a raycasting algorithm and generate a stream of PPM images to to pipe into FFplay. There's zero evidence of this being written in Claude; there are multiple clips of the developer working in VSCode, where the Claude plugin doesn't even appear to be installed.
It would be nice to have screenshots. Also it’s just a single commit, did you use AI? Quoting the readme: “FPS.cob is what you get when you decide that game development is too easy nowadays”.
Submitted a PR: https://github.com/icitry/FPS.cob/pull/6/changes. You can see a screenshot at the link.
It’s odd it’s not linked in the repo but the author made a your video:
https://www.youtube.com/watch?v=qzpZQe7JT-o
I have many projects with 0 commits, meaning were I to use git, it would be a single commit. It does not mean anything.
I hope for their sake that it's an agentic AI experiment.
Why the negativity?
If someone wants to have fun in COBOL, let them have fun in COBOL.
If it’s agentic fun, that’s cool. If it’s an interest in the language, that’s cool. It’s not like you have to have an ROI for a fun side project.
It’s also OK to be turned off by AI use in hobby projects and it is also OK to prefer disclosure of the use of AI in projects so I can make that choice.
As a few people have asked for screenshots, I spun it up. Here's a video of the basic gameplay: https://peterc.org/misc/fpscob.mp4 .. it's clunky, but it does play.
We need to start putting guardrails on hn to not allow those esoteric projects to be published. Before ai, it was impressive that a person has that much passion and dedication to go down the rabbit hole, and it usually comes back with some cool anacdotes that are nice to read.
Today, it's shallow, emptied out of the content.
It's not impressive that Claude wrote it, it was impressive if you have written it, OP.
The actual author of the project, has been putting out COBOL passion projects since before LLMs gained popularity. Because they write COBOL.
They've also written a couple dozen games in SQL over the years.
Accusing them of inexpertise with the tools is a gut reaction - but an unfair one in this case.
> It's not impressive that Claude wrote it, it was impressive if you have written it, OP.
Do you have evidence that it's Claude written? Looking through the source it isn't clear to me, at all. Plus, even if it _was_ Claude/LLM assisted, why does that take away from the project?
> why does that take away from the project?
It's like being offered a big mac at a fine dining restaurant. Yes, big mac is gonna taste fine, maybe you can dress it up nicely even. But the restaurant didn't make it, and you feel cheated for buying it (and in this case, wasting your time thinking someone coded it).
Something just existing isn't the same as something being made by someone with passion and effort beyond a one-shot prompt to Fable 5.
Wait until you find out about Sysco
Please remember to thank Chef Mike
Where you order ingredients doesn't take away from the preparation and cooking.
Pushing a button and having a machine turn those ingredients into a final product does eliminate its specialness.
So a mixer and an oven? Or does that not count because it’s 2 buttons to bake something?
I disagree.
> why does that take away from the project?
Because it is process that matters, in such projects, not the outcome. E.g. it is fascinating how one manages to port and run Doom on some microwave led screen... But nobody is going to play it eventually, it is not relevant as the "end product".
You have to remember that this forum is for people who have a passion and an intellectual interest in coding and development, and discussing such with like-minded people. Stimulating intellectual curiosity. An interest in what humans think and do is an implicit part of the experience.
An engineer vibe-coding a project generates an end product, yes, but what is there to be interested in or to discuss? Chances are said engineer isn't even capable of discussing the project in any depth. Are we going to be left discussing nothing but prompts and Claude workflows, and how we got the black box to do a thing? OK. Who cares? I guess we can all politely clap and move on.
I don't know if the posted project was written by an LLM or a human, but I have to agree with localhoster than AI has sucked a lot of the joy out of a lot of HN.
How this isn't causing an existential crisis in fellow developers, I don't understand. We're seeing our craft dissolve day by day, to the point where even our forums are filled with AI generated crap that we just don't find interesting or engaging.
It is. People have posted threads about how they hate that AI has sucked all of the joy and fun out of their work, and they can feel it rotting their brains, but they just can't not use it. Either because their employers require it or because the compulsion to minmax and optimize their "productivity" overrides all. The dialogue they have with themselves and with HN is a lot like the dialogue someone has questioning the tenets of their own religion.
Aside from that, I don't want to take responsibility for that which I don't understand. And even if I can read the code generated by a LLM, that's not the same as thinking through a solution or planning a design.
You can't call yourself an "engineer" if you just open Claude or Codex and hit "Y" on the keyboard to every prompt like that dipping flamingo when Homer Simpson took the wfh job (Simpsons predicted it).
I am facing that very dilemma. I lean more to the anti-AI side, I don't want to get my skills atrophied by relying on it, but I recognize its potential productivity boosts as tempting to use.
> An engineer vibe-coding a project generates an end product, yes, but what is there to be interested in or to discuss? Chances are said engineer isn't even capable of discussing the project in any depth.
And this is reductive to the point of absurdity.
Everybody screaming about AI forgets the fact... you STILL need the domain knowledge. That's where the value in engineering is now.
Imagine a wanna-be game designer thinking they can fire up codex or claude and even with a few weeks and a few hundred dollars in credit, coming out the other side with a game anybody would want to play.
That's not how it works.
I tried with godot. I can tell you everything you want to know about programming/networking/DevOps, and daily use that knowledge. But was very very quickly overwhelmed with the things I DON'T know about game design and development when I tried to develop retro-DQ clone in space.
And yeah, it didn't work.
https://i.imgur.com/hyXQEyA.png
I don't think Claude wrote this, even so, it's still cool. I'm not proficient in COBOL, although the README.md is very human generated, its not verbose at all.
The creator has a YouTube Channel you can check out: https://www.youtube.com/@icitry/videos
We need to start putting guardrails on hn to not allow those pointless comments complaining about usage of AI.
If you have nothing else to comment on then can you stop crying please?
I saw the recent "would a slop button be useful in addition to flags?" and my immediate response was "only if I can also flag people whining about slop.
Adds absolutely nothing to the discussion.
I've whined about it. I try not to. Maybe I'm being a nosy bystander, but here's what I see:
- User X posts some very AI-ish comment: "It's not X --- it's Y, and the reason is important...blah blah"
- User Y responds, taking the original at face value, and disagreeing or otherwise putting time into parsing the ideas in User X's post.
- Me, thinking: User Y is being duped, wasting their time, arguing with a ghost, and otherwise being taken for a ride
That's not my problem, it's User Y's, and they may have knowingly decided to respond even though User X is posting AI slop.
But a forum where that happens a lot doesn't seem like a good place.
If slop adds nothing then discussing what is and isn’t slop and how to get rid of it does add something.
We need to start putting guardrails on hn to not allow those pointless comments complaining about usage of peepee poop
Could you stop evacuating your bladder and bowels? Puuuuhfleas
As OP: I _didn’t_ write it. I’m not the author. I just thought it was neat.
But thanks for the accusation.
Frankly at this point, it's just as insulting to claim it's shallow and worthless just because Claude did it.
If there is a cool project that comes out the other side, who cares? I am forced to use Claude for day job, and while it's annoying, I am running at a pace that can keep up with my brain, not just what I can shit out and get tested and inevitably miss things. Because you know what's great?
When you have actual controls in place like Jira ticket integration, CI/CD steps that can be considered, but the overall change is small, how many more of those small changes do you think I can get done in a day versus before it? But hey, localhoster says it's shallow and empty of content, so it must be true.
A passion project of mine has been to develop a full decompilation and a randomizer for Neutopia. I've been working on this multiple years. I had it at a point where I had chests randomized, item grants, etc, but that kind of turned into a lame game because of how the existing Neupotia game works.
It's been stuck at 40% for just as long. I pointed codex at it, and now I'm at the at least 85-90% and will have it done within a few weeks.
Given Neutopia is a much smaller target audience, but when this project is released, it will at least as capable as http://alttpr.com/en, and more capable in some ways as random dungeon and overworld layouts are already possible, not just reusing layouts and changing chests.
Codex generated a big chunk of it, so it's clearly a horrible idea and piece of crap not worthy of localhoster here.
Exactly. But the damage is done. I find nothing anyone does in tech impresses or interests me anymore. The only things that interest me are things I’d like to also do myself. I imagine it’s probably the same for a lot of other people.
Like OK someone vibecoded an FPS in COBOL or Pokémon emerald in a web browser with web assembly? Ok good for them, piss off karma farmer.
> Like OK someone vibecoded an FPS in COBOL or Pokémon emerald in a web browser with web assembly? Ok good for them, piss off karma farmer.
Sorry, but most of these discussions reek of extreme gatekeeping. First off, neither of these things are impossibly difficult and are easily doable with some dedication by hand. LLMs simply accelerate the process, the human still has to come up with the architecture, _idea_ and plan to do something like this.
It's only cool if it's in written in brainfuck via pencil and paper.
Bonus points if it's ink on paper.
Bonus points if ink and paper are hand crafted by the creator rather than the filthy casuals that rely on paper mills to make their paper for them.
Made me laugh. Thanks :)
I think what we’re seeing play out in this thread is the devaluation of software engineers. If a growing number of people have the sentiment that an engineer vibecoding an idea has less value than a human doing it then that is all that will matter in the end.
That’s the inevitable result of machines being invented that can largely do our jobs. Just like how artisanal products are often prized over factory productions. The effort put in to and the organic quality of products have pretty much always been of value to consumers and appraisers. “I clicked a few buttons and look what the machine produced” will never be as impressive.
> If a growing number of people have the sentiment that an engineer vibecoding an idea has less value than a human doing it then that is all that will matter in the end.
Because if you put them on balance that will be the truth.
If an “artist” comes up with ideas for some artwork then just prompts it out with an LLM I am similarly not impressed, and never will be, even if the image looks cool. It’s a cool image, not an impressive effort. That’s all these code projects are. Shiny objects.
You know what, that is some pretty readable code.. COBOL might have been on to something there. I've gotten so used to syntax soup this is refreshing.
https://github.com/icitry/FPS.cob/blob/main/fps.cob
That readability is the upside of COBOL’s oft-assailed verbosity.
I remember being taught in my COBOL class (early 2000s, needed an elective, thought it would be fun) that that was the point.
The stupid engineers could write the code like the grunts they are, and then the manager could read it and verify that it was correct without having to know how a program.
That wasn’t exactly how it was put. And there are obviously some assumptions in they are on how good a job a manager who doesn’t know how to code could ever do.
Certainly an interesting idea though.
I had to get into an old tcl program for work recently and had the same thought. I wouldn't necessarily pick it today but it was kind of nice in a way that's unfamiliar to me from modern development.
The tcl syntax is fine. And modern tcl is fine.
But tcl 7.x and before was a pure string-based language. Everything was essentially a eval(). People would hit syntax errors on production code.
Fun, painful times.
The flip side: the interpreter is super simple and fun to write.
Tcl is still entirely stringly typed. That's never changed.
There are under-the-hood optimisations to make it less insanely slow but that only affects performance.
Tcl is a cool hack (the interpret is simple to write) but it's insane to actually use it. I wish the EDA industry would realise that.
Tcl 8 introduced dual-ported objects. Everything can exist as a typed object that is convertible back to a string in certain cases (some form of string operation typically). That plus the bytecode engine makes it work completely different than prior releases.
That's just a performance optimisation. It doesn't change the semantics at all. From the changelog:
> Tcl automatically manages these values so their type is transparent to the Tcl script writer.
https://www.tcl-lang.org/software/tcltk/whatsnew.tml
Saying it's "just strings" is disingenuous. You could make a js interpreter that uses strings internally too.
No. Tcl is all strings from a language point of view. To your Tcl code, everything is a string.
Internally in the main Tcl implementation, it isn't just strings. It's a bit cleverer so it can be faster. But that is completely invisible to the Tcl programmer.
JavaScript is not just strings. It has real types (even if it is happy to coerce them to strings at the drop of a hat).
To put it another way, JavaScript has `typeof` which returns the type of an object. Tcl doesn't have that because the answer would always be "string".
tcl::unsupported::representation will expose the actual internal type.
> ::tcl::unsupported is a namespace that contains bits and pieces of Tcl that are experimental, not intended for production code, perhaps useful for debugging and introspecting Tcl, and liable to change or removal without warning.
Looks like it outputs PPM and use ffplay as a display driver:
https://github.com/icitry/FPS.cob/blob/497867bb6827bcfc32d50...
The level of nested ifs is just pure insanity. Is this COBOL forcing this kind of style?
They should compile it to WASM and host it.
I did not know COBOL compiles to WASM until I read your comment and looked it up, thanks!
I saw his YouTube video here: https://m.youtube.com/watch?v=qzpZQe7JT-o
One of the things I like about it is he had to create a little front end to display the game, mirroring actual COBOL practice. Until the 80s or so, COBOL didn't support meaningful terminal I/O in its own right; it was all batch. If you were a mainframe dev and wanted to do terminal interaction, you either had to write your own routines for that in mainframe assembly or use something like CICS, IBM's application server which provided its own terminal handling and transactional database routines accessible through a language extension which got swizzled into regular COBOL by a preprocessor. Creating a layer outside of COBOL to do the things COBOL was deficient in, and using COBOL's regular I/O to communicate with it, is peak mainframe-era engineering.
Other solutions to the same problem existed; there was one called InterComm, which lacked the preprocessor and required you to reserve a shared area of memory and write messages to InterComm directly into it. These days there's KICKS, an open source library API-compatible with CICS, aimed at the sort of person who faffs about with old software on Hercules.
That just gave me flashbacks. I wrote code on some ancient stuff that operated like you describe InterComm. Haven't done that in years, and I don't think much of anyone uses those systems anymore (Harris H100).
I think Intercomm is bundled in the TK5 distribution of MVS 3.8 now. They got clearance from the owners a while back as I recall.
I'm assuming it's the same Intercomm you're talking about.
It is, and that's how I learned about it!
Doesn't run for me. Just I/O errors and quits.
Criminal not to put a screenshot in the readme.
Come on, we need screenshots!