Do not buy this game. This is not the programming game you want to buy. It is not worth the money, and it is not currently, by my standards, a finished puzzle game, much less one that teaches any reasonable amount of programming.
It is a beautiful idea for a game, and a very clever title for the idea. But it is not the game the idea would suggest exists. If you must buy it, wait for the game that purports to teach programming to at least be itself adequately programmed. That is not the game that is available right now.
Hack 'n' Slash is a game in which you swing your USB sword to, instead of slaying things, set their hit points to 0. I can offer no higher praise for the integration of the "hacking" in the game for the first few minutes of gameplay. Instead of attacking the turtle, you hack its allegiance so it becomes your ally. Instead of finding the right order of blocks to push for a block pushing puzzle, you simply hack the number of remaining pushes allowed for one block. Reprogramming the movement of the guards was hilarious.
Then, just as quickly as the fun begins, the clever puzzle design disintegrates.
The coding is still painfully inaccessible and unserviceable—if you're a programmer, it's boring and tedious for no apparent reason, and if you're not a programmer, there's no chance you'll really even understand the puzzle as it's presented. As an experienced programmer, putting together the clues using detailed understanding of how programming generally works got me through the "programming puzzles", but left me painfully frustrated by how obtuse they were guaranteed to be for someone who didn't automatically know that "HackBlock 1" is probably the same in-game object as "blocks". I see no reason to relate a red letter 'a' directly to a red diamond symbol other than educated guesswork. A game which requires trial and error is fine, but a game that requires too much backtracking between trials and crashes when you don't know what you're doing is not a game that encourages learning.
The most frustrating thing for me was when I immediately saw the solution the programmers intended, but also that there were far more obvious and trivial solutions. Let's take a hypothetical locked gate as an example: if instead of entering the prescribed password, you simply toggled some output value from "false" to "true," you might bypass the intended lesson entirely. Not only are the puzzles poorly thought out, they don't even enforce the intended lesson. I can't imagine anything other than inexperienced players blundering their way through the "puzzles."
The game crashes when the built-in LUA interpreter falls apart, because instead of being a sandboxed interpreter, the game runs code you throw at it natively, and I wouldn't be surprised if the game wasn't a legitimate security vulnerability for getting admin access to the local machine. What's worse, the programming conventions used are distracting, if not outright confusing. The variables that are useful to hack aren't even always next to the lines of code they relate to, requiring mundane back calculation or walking around to find the right variable.
Imagine if a game that wasn't about programming presented these qualities: for instance, you found yourself in a hallway with five switches, and the purpose of the doors is only marginally explained to you. There is absolutely no feedback to tell you what each switch does, unless you've solved the puzzle, or unknowingly triggered a fail state. What's worse, these fail states cause you to lose any forward progress made not only on the current 5-switch puzzle, but also the 3-switch puzzles that you've managed to solve in the same hallway. This is not what I consider a good puzzle game, but it is exactly the sort of scenario Hack 'n' Slash unforgivingly drops players into. Where traditional games undergo thorough testing to prevent the player from causing crashes, Hack 'n' Slash markets the total (and completely unnecessary) instability of the game as a feature. Can you imagine an point and click adventure game that crashed when you used the wrong item on the wrong target? How is this fun for the player? Why aren't they simply preventing unnecessary modifications, and adding iteration limits and variable scopes to prevent accidents? The puzzles are poorly designed, and just aren't fun.
And now for the rest of the game. As adventure games go, this game feels incomplete: shoddy collision detection make movement a confusing dance, total lack of information on what can and can't be done makes even thinking about solutions total guesswork.Traditional adventure games leave a trail of breadcrumbs to lead you along, and a useful assistant who makes sure the player is at least going in the right direction. Not so in this half-done game. Between acts the player is expected to know where they should romp for five minutes to get to the next destination, and while this could be "part of the puzzle" in some twisted logic the latter half of the game is a series of tedious activities: wander until you reach the next scripted destination, randomly permute code until success. Nothing is named in a useful fashion, nothing is provided, and the game gives you more ways to cause a crash than it does any meaningful direction towards a smart solution. There's invariably way too much information available as "clues," and the player has no idea what's useful and what's just there because the programmers thought it would be cool. I spend so much time wading through unnecessary details for reasons I don't understand to solve puzzles that aren't even intellectually challenging so much as they are a series of inside jokes. The final puzzles aren't so much arcane wizardry as they are exercises in variable tweaking, and there's not even any guide to explain which variables should really be tweaked to start with. Behaviors not explained before or after a particular puzzle are used and so players shouldn't even know to try the things the developers expect us to know.
As someone who actually studied computer science, incidentally, I'm disappointed by what the game refers to as algorithms. None of the implementations are meaningfully quantifiable algorithms. This is what most saddens me, to be honest: there are so many beautiful, challenging, and meaningful problems in computer science that programming games could explore and teach. Even the final chapter of the game, purported to be a legitimate programming challenge with actual security applications, boils down to a series of password reading tricks used earlier, or the mundane "wander, hack, permute" process. I was hoping to maybe see some binary search, or some loop iteration, or even just simple mathematics to inject actual challenge into the game, but instead found myself going through the exact motions I go through when debugging ugly, poorly written code. "If x ==y continue" tells me nothing about how many lines are actually part of the if statement, by the way. LUA probably wouldn't have been my first choice as a language for making the code readable to nonprogrammers. Might have been smarter to create a simpler, if still Turing complete domain specific version of LUA that doesn't throw unfamiliar terms like jump statements and closure operations. I'm saddened by the possibility that LUA was chosen not because it's a beautiful, educational language but because it made executing user code easy (and highly destructive and universe-collapsing). I spent more time shaking my head at the programming choices than solving the puzzles, and even more time wondering why Double Fine failed to even make the non-programming parts of the game enjoyable. It plays like a very promising alpha, which would be encouraging, if the game wasn't being marketed as a full release.
This is not a programming game. This is not a well-programmed game. And what's worse, this is not even a good game. I'd save your money if I were you.