"... I then proceeded to rip out dependencies until I no longer needed to. I put up another one called Tetris-Lite. After a quick search I found that already existed."
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.
"so I looked for python versions, but there were only versions of python 2.7 and my PC has installed python 3.0; after downgrading I realized this version uses the win32api, which doesn't exist in my Mac. After much frustration I went on the internet to ramble about how bad is nodeJS and JavaScript fatigue"
"... so, keeping mind that this is 1996, I started to connect my Gateway 2000 Pentium Pro to the dial-up internet. After the fax screech, and only within a few hours, I found several great shareware implementations on usenet." ;)
I think any re-implementation of something you are fond of is a great exercise. It reminds me of a small project in undergrad for a networking course. Our professor's assignment for the quarter was to implement a basic TCP stack using the UDP protocol. It wasn't perfect and had quirks but it worked for a basic client/server model and gave me a huge appreciate for what happens when we use the internet.
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?
> I think any re-implementation of something you are fond of is a great exercise
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).
I second project Euler, but for a different use case. It is a great tool to learn the lower level workings of a computer language. Work through the first 100 or so exercises in a new programming language, and you have got a good understanding of how to write efficient code. Most of the problems are solvable in less than 1s in most languages with the non-naive brute Force approach. I remember doing it in a functional style using scheme. At about problem 50 I had a good understanding for how to write in a way that avoided excess allocations/collections.
Ah the frustration when someone was generating primes with a worse approach than I had, and my code was 2 or more times slower.
> I think any re-implementation of something you are fond of is a great exercise.
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.
Great story. I recently made my own tetris game, though since I wanted to put it on the app stores and not get sued, I had to come up with a "tetris without being tetris", which was a great creative exercise. In the end I made a more unique game with some gameplay that is rather fun (IMHO) that would never have come to be if I just made a straight clone.
Thanks for posting this. I'm always on the lookout for interesting Tetris variants. I purchased (on iOS) for Quad Blocks, after playing it on your website.
Yes because with improved tools we are expected to do more things to achieve the same goals.
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:
The demoscene is amazing fountain of technological progress. I feel sometimes like it's the abstract math of the software world, off doing lots of very impressive useless stuff, until some little piece of tech filters its way down and revolutionizes part of an industry. For example, lots of sceners now are bringing things like procedural generation of art assets to the masses, but it's been a common technique in the scene for decades.
>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.
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.
By "more things" the author doesn't mean "inefficient work that produces no value." She actually gives the example that her old code produced solid squares with a border & the new ones are generated with some visual effects.
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), ...
Yeah, it's much more defensible a statement if you read it as "our expectations from code have grown exponentially" than if you read it as "it's exponentially more complex to achieve the same goal".
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 like to have a simple personal 'benchmark' when learning new languages. One of the first programs I try to implement whenever a new language comes along is a filesystem walker.
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.
I'm glad to hear I'm not the only person to have re-written Tetris a number of times over the years. Usually it's what I use to try out a new game framework.
I've implemented Tetris 5 or 6 times over the period of 20+ years. This is my standard exercise to learn/try a new platform. I wrote one in C for custom smart phone/PDA prototype we were developing in 1994, then I wrote one in assembly for Zaurus PDA, another one little later for Palm Pilot, few more I do not even remember, and the last one 2 years ago to learn some OCaml (text-based and SDL versions) https://github.com/vzaliva/otetris .
I use Tetris to learn too, here my last implementation in javascript, I've started to learn Nodejs and how to reuse code with browserify, the version worked in the terminal and the browser.
I would like to take time to rewrite it again in ES6/7, and then start learning other things like AI.
edit:
https://github.com/alfonsodev/tetrinode/tree/dev-0.2
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.
I can't see how writing a Text Based Adventure as being enjoyable for the programmer unless you try to have people play it and watch them scratch their heads figuring out what to put in the door slot after "Put key in slot" and "Key feel through slot and is now behind a locked door."
I like how she starts with Windows and QBasic - probably available out of the box on 90% of the PCs at that time and then achieves 2016 code with better 'maintainability' running on an exotic stack barely known.
At which point did we remove learning curve from maintainability?
42 comments
[ 3.3 ms ] story [ 94.9 ms ] threadPlease provide an example of a Node.js project which downloads 500MB of deps.
- http://rungoterminal.com/
- https://github.com/shockone/black-screen
- https://github.com/nylas/N1
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.
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.
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.
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.
https://www.youtube.com/watch?v=zBkNBP00wJE
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.
At which point did we remove learning curve from maintainability?
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. :)