TIS-100: the Programming Game You Never Asked For
blog.codinghorror.com
blog.codinghorror.com
I beg to differ. Assembly is awesome. Some of the best times I've had programming were writing networking code (ethernet driver, TCP/IP stack, and HTTP server) in Z80 assembly. I wouldn't recommend assembly if you're writing something like a modern GUI app, but assembly on an embedded micro can be a lot of fun.
I still think my best work is a graphical library I built in 9th grade in assembly to use with my Pascal programs in MSDOS.
mov ax, 13h
int 10h ;SCREEN 13 rules!!![0]http://www.amazon.com/PC-Intern-Programming-Encyclopedia-Dev...
And kids these days, they just don't understand!
also a fun way to seize up your computer when you got it wrong, I mean it compiled it should run, right?
Years ago a "textfile group" I was involved with decided to release a 3 1/2" floppy diskette w/ our files at a hacker con. I thought it would be cool to put a custom bootsector on the disk-- something that displayed an easter egg rather than the boring traditional "Non-System disk or disk error" the bootloader on MS-DOS-formatted disks displayed.
I ended up making a simple static mode 0x13 display w/ a gradient background and a text message. When I tested it I discovered my message was being displayed backwards and in the wrong positions. I'd set the direction flag earlier in the code and neglected to clear it. I was preparing to add the one-byte "CLD" instruction when it hit me that I could just leave the code as-is and reverse the data. I saved a byte and the code did exactly what I wanted. I was quite happy.
You can't experience that kind of joy in a high level language.
I would prefer "what's near universally regarded as un-fun by programmers". Which would simply place you in the small minority, rather than being placed outside the universe of programmers. It could still be wrong, depending on the threshold for "near universal", but it wouldn't be obviously confusing.
I mean, it's efficient...not sure how I feel about a future where a conversation, or even the dreaded whiteboard become relics of more innocent times. That said, great game :)
I'm starting to think that the way out of this is guild-like structures where you qualify by producing a "masterwork" recognised as such by your peers. And then you don't have to prove yourself any more.
If the challenge is just allowed to be itself and not an employment filter, then it can be fun for all involved. I'm keeping an eye on Stockfighter myself, and I know people who do Project Euler for fun.
Isn't this essentially how PhDs are granted?
And of course to another programmer writing a 100 byte assembly program that draws something interesting on the screen is just a fun gimmick and "real programmers" are the ones making the same program 10x slower and consuming 1000x more memory while using some new Java API
(I'm more of the former myself)
In the end it's really dependent on what tools you're used to. And extremely dependent on the goal. For most software, the objective is to accomplish the task, and performance doesn't matter (until it starts to matter of course).
I think judging people on the level of abstraction of their tools could end up being counterproductive and alienating. Maybe you never want to write in Java, but dismissing those people out of hand could mean that you might not have an opportunity to show them why you enjoy writing your assembly programs.
Of course the number of people that could do it in Asm is smaller than those who could do it in Java (I guess in the same way only few people can drive a Formula 1 car)
I used to make small demos. They'd take about a day each to make my Atari 800 do something amazing. I was assigned to create 14 interactive screens for a game at work. I thought to myself "14 screens. I make a screen in 1 day so 14 days I'll be done". Turned out to be closer to 90 days. Of course maybe I just suck as a programmer but my takeaway was real programing is more work than "drawing something interesting on the screen".
http://www.zachtronics.com/the-codex-of-alchemical-engineeri...
The dopamine rush from solving a hard problem is pretty intense, but not worth the hours of frustration after more hours of frustration at my job.
TIS-100 sounds more like one of the old ICFP programming competitions - 2006 and 2007 in particular, both were about reverse engineering esoteric systems.
In comparison, The Human Resource Machine has far better production values, but it's really an assembly class in disguise. The end level is to write a sort, so I see it a lot more as an educational tool for kids than a game that could be fun for programmers.
I found it to be a good "ideal assembly" playground. It definitely could use more depth, but more often than not I didn't meet the cycle count or code size bonus criteria after finishing a level, which turns into its own challenge.
I like these games a lot, but I almost feel like the act of typing out the solutions is the funner part. Getting stuck on an especially hard problem for too long just gets frustrating.
This isn't just a minor economic blip, but I took a non-programming (but still technical) job out of college, because it was what I could get. I now have a few kids and pretty firm roots in a town without a lot of programming jobs. I make a six figure salary, I'm reasonably good at what I do and I like my coworkers, so I feel weird complaining about my job, as I'm better off than most people I know...
However, I really want to write software. I contribute to open source projects, and when there is something I can automate at work, I do it. I'm also somewhat concerned that if programming were to become my day job, I would lose interest in it. Has anyone else made the transition from hobbyist to professional, and have any advice to give?
That being said, I work full time on software that doesn't always align 100% with my passions, but it hasn't dulled my interest or excitement in programming in general or my side projects at all.
While I was working as a PM, I spent a lot of time as a hobbyist programmer, and a lot of time learning about how to engineer good software systems. After leaving that job I spent 6 months or so just building stuff. Games, android apps, whatever I felt like. It was awesome. I turned one of those projects into a consulting gig, then another, then got hired full-time from one of those gigs into a startup where I learned like crazy and sought out as much mentoring as I could get my hands on. I maybe could have done a similar side-step at my previous job, but having talked to some folks about what that would look like, I decided to just jump. It worked out. I hope it does for you too.
...Or, as it sometimes happens, you lose interest in writing software for other people.
[0] http://boundvariable.org/task.shtml [1]
[1] Fair warning, this rabbit hole is deep.
I fired up my Apple ][ recently and was amazed it still worked -- those floppy disks are amazingly durable. 30+ years of sitting in a footlocker and yet they're still readable. Amazing!
There is no substitute for the charm of a flickering greenscreen monitor, the whirr of a 5.25" disc drive, 40 columns of text, a clacky keyboard, and the smell of dust burning off the power supply. Yet I found myself asking "how did I get anything done with such primitive machines?"
For me, if I'm ever working in assembly, which is pretty rare these days, it's usually on an overall "smaller" system. Ie an embedded system where all the SW, HW, and tools can be grokked by a single person with out multiple cascading levels of increasing complexity and abstraction.
Good times for sure, though to be real, the good part usually comes after many moments of banging-head-against-brick-wall.
Interesting trivia: the creator of this game, Zach Barth, created Infiniminer, the precursor to Minecraft.
It reminded me a lot more of the work I did with software-configurable processors in the early 2000s than any of the 8-bit assembly I did back in the 80s.
Stack Exchange, which was co-founded by the author, does exactly this.
And, of course, if you're having fun and noone is forcing you to do it, I'm not sure it can be classified as 'work' anyway (depends on whose viewpoint you're taking, of course).
I suppose a system like stockfighter can try to take into account the fact that not everyone has time to optimize their solution, but also, at the end of the day, how you prioritize your time I suppose is a factor in the whole merit-equation - the more driven you are the more 'passion' you are seen as having.
Stack overflow is different in this respect, though, I will admit that - although some answers are really high quality it is probably the people spending the most time there that end up with most reputation. And I guess that's fine as well, if some recruiters want to use SO points as a basis for recruitment they know (or should know) what kind of people this process singles out.
I hope to see many projects like stockfighter in the future, each focusing on their own aspects of work in software so that employers can look for their candidates in the appropriate 'pool'.
I just really think that measures like this severely distort the employment market and are a terrible measure of actual merit. Which becomes even worse when people talk about those with "merit" being more "deserving" of whatever we consider to be "success".
For example, say a developer worked on an open source project and was paid market rate for their work. At the very least, the code they've contributed is public.
Unless you have a magical telepathic helmet that can access merit
I'm looking for work as a programmer in NYC, my email address is bcoburn3@gmail.com please get in touch if you also think that a game like Stockfighter is a good test of programmer skill.
The impression I get is that people have gotten and will get interviews through this, but that the amount of time each one takes is more than expected and that Thomas/Patrick/Erin are generally overwhelmed.