Twenty years later I wrote a Tetris again
blog.levit.be
blog.levit.be
Doesn't this mean we are becoming more inefficient? I wouldn't agree with calling those tools "improved", in that case.
About the size of the code: the code I wrote this time is roughly one third of the size of my original code which probably means it has less bugs and is more maintainable
That neglects to consider the fact that you are now depending on orders of magnitude more code than before, which from an overall perspective certainly doesn't mean "less bugs", and in fact could even make things more difficult to debug.
...and for something related but on the opposite direction, a competition on making the smallest (binary) Tetris clone that follows a spec:
https://files.scene.org/view/mags/hugi/compos/hc22fin.zip
The winners are 363 bytes.
This particular compo has a long history and lots of different challenges: http://www.hugi.scene.org/compo/compoold.htm
- A brainfuck interpreter in 98 bytes
- Nibbles in 48 bytes (some of the disqualified entry reasons are also equally interesting)
- Maze builders in 122 bytes
If you choose wisely your dependencies those are going to be a lot more reliable (incl. less bugs) than the code you can write in a few hours; because its code with tests, a large user base, etc.
Realistically, she could have produced some blur effect twenty years ago, but there were no good toolsets for doing it. Because of the "improved tools", developers can now create that effect with one or two lines of code.
Summary: "improved tools": These tools enable easy access to advanced functionality. "expected": Users expect beautiful tetris, not just solid color with a border "achieve the same goals": Really, the goal is to create a playable terris. The definition of playable has apparently evolved in these twenty years.
As an aside, generally I agree with your comments about the bugs. Libraries are implemented in python (bugs here), python is implemented in C (bugs here), C has a compiler (bugs here), ...
A hacked-out Tetris clone in QBasic is easily doable even today, just head on over to qbasic.net and download the old interpreter and away you go.
I would like to see, for comparison, "how many things" you need to do to build (from scratch, in QBasic) an entire new version along with bitmapped artwork and it's own custom control hardware.
I think the higher up the stack you go the easier it is to lose appreciate for all the lower layers that facilitate your stack. And over time I fear new generations of programmers are losing touch with what the basic foundation of a computer is. Sure they will study theory but do they really know how many man hours are supporting their stack?
This is basically my procedure for learning a new programming language. I have a list of things that I like to have on hand that cover a fair amount of possible paradigms, and re-implement them. Things like FFT, linear algebra methods, numerical root finding/optimization algorithms, etc. Project Euler (and now also exercism.io) are great for finding small but digestible things to do too.
At the moment I'm working on finding some better mathematical examples for class abstractions & better use cases for object-oriented concepts in general. Because it looks like I'll be teaching a course either in Java or C# next fall. Coming from a scientific computing background the usual use cases for java and .net aren't my typical problem areas of expertise (though there are some things I definitely do appreciate about them).
Ah the frustration when someone was generating primes with a worse approach than I had, and my code was 2 or more times slower.
That's basically how I learn new technology is to either partially or fully port my Proximity game (http://briancable.com/proximity) to it. I've used that to learn C#/XNA, Objective-C/iOS, Java/Kindle (sadly never finished, but it looked beautiful on a Kindle), and most recently Pico-8/Lua (still in the process). I'm planning to start working on a 3D version soon, as well, with the goal of getting stronger in my 3D programming and getting it onto a bunch of platforms with a single codebase (using Unity).
Considering the game has been used in at least one book (Actionscript 3 Design Patterns) as a 'learning to code' game and I periodically get emails from students whose teachers have made an A.I. programming exercise for Proximity, it probably makes sense that it's my go-to learn new tech game, considering I've made other games too but don't port any of those.
Please provide an example of a Node.js project which downloads 500MB of deps.
- https://github.com/shockone/black-screen
And there are hundreds of them, specially if they require Babel which by itself requires a significant amount of disk space, but since you were lazy to find these projects by yourself, I will be lazy too and just list three of them, I will leave the rest to your imagination.
At which point did we remove learning curve from maintainability?
This is a great exercise.
I can read all the tutorials in the world, but I don't feel comfortable with a new language/platform/toolkit/etc until I've ported Tetris to it.
I go as far as making every implementation replay-compatible for ease of testing (and also because it's just really satisfying watching half a dozen entirely different implementations of the same game running in frame-perfect harmony).
Right now I'm working on a Haskell port, and as a beginner to FP, it's quite a mind-bending experience trying to implement something so familiar in such an alien language.
323 lines of MACLISP including comments, no dependencies.
It combines enough concepts that allow me to quickly evaluate the syntax and some core principles of a language. I rarely end up writing the same thing, which is rather impressive and sometimes even enlightening.
This hits home, I just recently found my old Tetris game written in Purebasic 10 years ago and uploaded it to GH. https://github.com/kennycason/blocks
My other larger games in basic were even worse. :)