Closed markcornwell closed 4 years ago
Feeling good about progress. Got drawing tests working and building up a test suite as I go. Have some clear ideas on how the toplevel will work. Recommend googling Dr. Frizbee's Mostly Adequate Guide to Functional Programming in JS.
Resulting code has a Haskell like feel, minus the type checking. Though that could probably be handled with a transpiler later on. I have many thoughts on transpilers that could be food for a future blog post.
There is a good deal of technical guidance on the the why and the how regarding refactoring imperative, object oriented style JS programs into a corresponding functional form. If you google "functional programming javascript" you get lots of information. If functional programming in javascript is new to you, here are some
Links I can recommend:
Skeptics Guide to Functional STYLE JavaScript
https://www.youtube.com/watch?v=oF9XTJoScOE
"Functional style is about using less brain power and making things simpler."
Another really good talk, ...
Stop Writing Classes https://www.youtube.com/watch?v=o9pEzgHorH0 Take Away: stop needless wrapping stuff in objects...
Got the functional version working with about the same functionality as the OO version. Next step is to merge this branch into the master making it the trunk of development. There are a few nits in how a few of the test scripts don't play well with node. Will look at them before doing the merge. I want the trunk to build cleanly and pass its test cases.
Cleaned up the tests. Added a check to sense if the code was running in a browser or not. See top of draw.js. If running in browser we use the window dimensions to determine the dimensions of space. On the server side, there is no window, so just assume 1000 x 1000. This works ok for testing and for our browser only versions. When we spit to a client server version we will need to add some negotiation to determine the space dimensions to use. If a server and only one display, we can have the client with the display tell the server what dimensions to use. If there are two players with different screens, we will provide some way to negotiate what works best for mapping between the two displays.
Functional branch merged into master. There is certainly more we can to to make it more functional, we have made a good start. Moving forward, I would like to do more with currying, composition, pointless, functors, etc. For now, I took it about as far as I can without incorporating a functional programming library like Ramda, Underscore, or LoDash.
Closing out this issue.
This is a follow up to my attempt at 2 player. Transforming the single player to separate functions and data and maximize a functional style in order to simplify transition to a 2-player client server version. Reference issue #4