I am going to cautiously recommend this game for programmers only.
While Hack 'n' Slash may appear to play like the old overhead Zelda games, it is a pure puzzle game. Direct attacks are impossible, there is no penalty for dieing, and you don't need fast reflexes.
I would give it a, perhaps generous, 7/10. I base this on averaging the 5/10 I would give it for non-programmers since they can only play the first half of the game, and 10/10 for programmers who may find it enjoyable.
Quite a bit of programming knowledge is assumed. Almost nothing is explained. At first, all you can do is alter the value of variables. Soon “if” statements and logical operators are introduced. The game spends quite a while at this level of sophistication, and an intelligent person that can read English can get by for the first half of the game.
Intelligence is not sufficient. Do you know what “function” (in the programming sense), “iteration”, “modulo”, and “closure” means? Do you know programmer catchphrases like “hack the planet” well enough to recognize them even when letters are missing and the words are rearranged? If not, you can't complete the last half of this game without a walkthrough. Playing with a walkthrough will be no fun, since there is nothing to the game other than solving the puzzles.
When the game does attempt to explain something, the explanations are often unhelpful, vague, and/or inaccurate. For example, the game hints that a closure is “when a function has a pet function”. That is unhelpful because it doesn't tell you what you can do with it, or 'what it's for'. Those features would help you use it to solve puzzles. It is vague because it neglects to mention that a closure is an anonymous function (a function without a name), and that it can contain references to the values of variables in the enclosing scopes of where it was created. Those features are why programmers care about closures. It's inaccurate because a closure can be returned by a function. It does not have to remain with the function that created it (that would be a nested function definition). If none of that made sense to you, that's fine. Just know that this game will not teach you to be a programmer.
It is perhaps for the best that the game does not teach programming, because the code you interact with appears to be produced by a Lua disassembler. There is no indention, and very little code structure. “goto” is heavily used. This does make the game challenging for programmers near the end, but it would teach bad practices.
For programmers the first half of the game will be far too easy. If you're creative you may be able to amuse yourself by solving the puzzles in roundabout or spectacular ways, but it is not required or rewarded.
Most programmers should find the last half of the game difficult, but mostly fair. Most of the difficulty comes from needing to debug (or carefully 'bug') code that is unfamiliar and poorly structured. This is a valuable skill.
The story is serviceable. Neither the plot nor the characters are very deep, but the ending is clever. I won't spoil it.
Some parts of the interface are very bad.
A minor, but constant, problem is overlapping text. This isn't just an eyesore. It's hard to find a particular book in a burning library when all the titles have other words printed over them. This could have been solved several ways. Text could be nudged the minimal distance from its centered position to avoid overlapping (the best solution I've come up with). Text could only appear when you mouseover something (likely a worse solution). Different colors could be used (probably the worst solution).
Source code (what a programmer writes to make a computer do things) is displayed two ways.
One view of the code is as mostly-text that should be familiar to most programmers. I say “mostly” text because there are colored diamonds scattered throughout. This form is used when you look at a 'signpost' for an algorithm before editing it. I had no problem with it.
The other view of the code is as a collection of machines connected with wires, with beams firing at them from colored diamonds. This form is used to make your changes to the code. It is, to put it bluntly, terrible. Each machine has some text on it. This text is so small as to be illegible. The machines are always arranged as a vertical line, causing the white lines indicating the control flow of the program to overlap, making it very difficult to understand. Even small amounts of code presented this way results in large rooms that make it almost impossible to get a sense of the overall structure of the code, and require a lot of time spent walking.
It's unfortunate that the text view wasn't used for everything.
The interface seems to have been designed with gamepads in mind. This makes editing the code slow and clumsy, and you occasionally have to type variable names and strings anyway. It would have been better if normal text editing had been used for everything.
The engine itself is fascinating. It appears to work by disassembling its own code, and letting you edit it while it runs. It's very resilient. If you make a mistake that would normally crash a program the game doesn't crash. You get a message about the world collapsing, and restart from the point where you entered the room as if you had died. This is even used in some traps late in the game.
While this isn't the first programming game (RobotWars was released in the 1970's, and there may be older examples), it might be the first that shows how to get a non-programmer interested in programming. Editing the value of variables in the source code of BASIC games, and then proceeding to make more and more complex changes, are how I learned to program in the 1980's, and the way this game starts out. It's a pity that Hack 'n' Slash does such a poor job explaining things, and that the learning curve hits a brick wall so suddenly halfway through the game. Hopefully future games will use this as a model to improve upon, rather than as a sign that such games cannot work.