Follow-up: Why JavaScript and PHP rule the web

The Reddit discussion of my earlier post “Why JavaScript and PHP rule the web” had good comments and made me wonder a bit more about the subject.

There are two comments of mine that I think are worth enough to put up on the blog, even if it is for being bashed by the internet, as it adds more substance to my opinion.

“pinnr” reminded me that both languages has lot of flaws, and I agree. But why no substitute won so far? That’s my comment for it:

That’s a good point. PHP and JS are full of “gotchas”. It makes me wonder, why no other languages have replaced them already?

Maybe if a new language can be as permissive and flexible as JS and PHP are, use an easy to understand flow (both are basically an infinite interactive loop) and adds more “sanity” to it, then it could win. The problem could be that new languages tries to be saner and stricter at the same time, and the web doesn’t like the stricter part. Does it make sense?

From “aslate” comments, I believe some people thinks that WordPress plugin system is just an example of a well defined API, and has no relation to PHP itself, as it could be made in any other language. I do believe that almost any high level language can be used to build a plugin system, but not as flexible as PHP would (or other languages that uses the “Assumption Inversion Principle”). That’s my answer to it:

Types, imports and modules enforce too much for the web. That’s my point of view.

By using only assumptions in your code, you don’t care how those assumptions are met, you just believe they will be somehow. It is like Dependency Injection, but at a more granular level.

Writing a single piece of plugin code that works on multiple versions of WordPress, leveraging new functionality when available is as simple as checking if a function exists (inspecting the environment) and adapting.

Imagine that JS used modules from the very start. A lot of libraries would have require('jquery') to only ever use a minor subset of it. This is where “assumptions” shine, you only pay for the exact subset of assumptions you make, and your code believes they would be fulfilled somehow.

jQuery has alternatives, underscore.js has alternatives, Backbone.js has alternatives. If each module selected one that better fits its need and you end up using those modules, you would end up with a bunch of duplicated JS functionality in your final product.

That’s the main point: when you require/import/etc something. You are locking your code with a preset selection that you made for whatever reason, and you are forbidding others to change that. There are plenty of reasons that other developers would want to change that selections (e.g. add a cache layer, only use a subset for space constraint reasons, completely mock it out for testing, use a proxy pattern to delegate things for a remote service, …).

Coming up with an API that fits every need is completely impossible. IMHO it is better that each code use assumptions about its dependencies, the same way a JS or a PHP function use assumptions about its arguments.

So, what I’ve called as Assumption Inversion Principle may have a 1:1 relation with duck typing of variables, but taken to the module level.

I like how a single function in JavaScript can be used in any type of object, as long as it has some properties that are assumptions of the function itself. Don’t you?

If you are an advocate of duck typing, why not advocate a “duck typing of dependencies”? What is the fundamental differences that I am missing here?

Why JavaScript and PHP rule the web

JavaScript and PHP are excellent languages. It took some time for me to really understand their power, and I hope to clarify my point of view in this post.

I believe that those languages shine and survive for being permissive and by adopting an Assumption Inversion Principle (AIP) — I’ve made up that name, you may suggest a better one in the comments. 🙂

What is AIP?

Raw JavaScript does not have any module definition structure, no statements as “import” or “include”. Symbols available for a piece of code written in JavaScript are pure assumptions. Those assumptions must be satisfied by other pieces of code, and not by itself. It is incredibly easy to change behaviours by loading new script files before the one to be changed by changing the link of its assumptions. This “change by adding” relates directly with the “O” in the SOLID principles.

Old PHP code goes the same way, your piece of code has some assumptions that some symbols are available and you simply use it. It is not the responsibility of your piece of code to link those symbols, you normally end up putting all of your script loading in something like a bootstrap system.

Import statements are bad, because they hardwire the symbols in your piece of code. Then if you need to change something, you actually need to get into the file and change it. In my opinion, “change by changing” is more prone to errors than “change by adding”. Also, “change by changing” does not scale as well as “change by adding”.

JavaScript and PHP code can also inspect its environment and adapt. So it’s possible to keep adding files that keep changing stuff depending on what has already changed or what is currently available for the script. This is pure gold in software development.

Think about WordPress plugins, you don’t need touch a single line of the core code, you just drop a new file and you can get a whole new experience out of your web site. Some plugins add features, other plugins only change behaviours. So, it either “add by adding” or “change by adding.” It’s a win-win situation, core code is hardly changed to add a feature, so you won’t get any bug from features you don’t care. For the features that you care, you get the plugins, drop them in and live with the bugs, if you happen to find a scary security bug, just disable the plugin.

I know a lot of people who criticize this way of developing and would prefer that WordPress be more object-oriented than it currently is. For what? Then we would need a plethora of new abstractions to achieve the same stuff. As code is a liability, the less code we need to achieve something, the better.

I love Haskell and its type system, it’s phenomenal. But it suffers from the same problem as other languages like Java and C# suffer. Modules are hard-wired with their dependencies and code can’t inspect its environment. I’m not saying that those languages are bad and should not be used. They surely has their own good use cases.

For a fast and distributed development effort as the web is, we simply can’t afford anything that is unforgiving or strict. The code needs to be open for changes from the outside (change by adding).

So, for the web, I don’t like new PHP code that uses modules and neither the usage of ES6. They may feel faster for developers starting out new products, but my bet is that in the long run they end up killing productivity and/or quality.

Think about it for the current project you are working on, how much could you change of it by only adding new files? What could you deliver by adding a new file: a whole new story, a feature, a bug fix or nothing?

All this permissive environment with all these code based on assumptions can turn into a real mess. That’s the reason those languages are hated by some developers, then those developers try to fix it by creating new stricter languages for the web, the end of the story is always the same: JavaScript/PHP triumphs over all. Why? Is it because of AIP?

JavaScript and PHP has some hidden properties that newcomers tend to ignore. Those hidden properties make them a perfect fit for the web. What do you think?

Am I just an old-school guy talking bullshit? Please, be kind. 🙂

Haskell is just some steps away from Java

Start with Java, then:

  1. Forbid using null;
  2. Use only immutable objects, add “final” modifier to everything;
  3. Swap methods by static functions with the the original “this” as the first argument, e.g. “foo.bar()” turns into “bar(foo)”;
  4. Add a lot of features to the type system;
  5. Remove type annotations, i.e. “Foo bar(Foo self)” turns into “bar(self)”;
  6. Remove useless parens, i.e. “bar(foo)” turns into “bar foo”;
  7. Add call-by-need evaluation;
  8. Done, you have Haskell.

It’s not that hard, is it?

One, using null references is a recognized bad practice, see “Null References: The Billion Dollar Mistake.” Java 8 already provides the Optional type to stop using nulls.

Two, immutable objects are a win strategy, see posts by Hirondelle Systems, IBM, Yegor, and others.

Three, as you only have immutable objects, there is no reason to use methods instead of static functions, considering you maintain polymorphism (not quite the case for Java, but for the sake of this rant, consider as if it has this feature).

Four, improve the type system. The type system used by Java language misses a lot of features. If you don’t feel it, just consider this as an added bonus. When you start using the type system features in your favor, you end up with much better code.

Five, imagine the Java compiler could infer the type of the arguments, so you don’t need to type them everywhere. You still have the same static typing language, you just don’t need to write the types. Shorter code means less liability to haunt you.

Six, why all those parens? Just drop them. Less code to write, hurray!

Seven, call-by-need just makes a lot of things easier (also makes a lot of things harder), but I really think it is a winner when you talk about productivity. When coding, I feel it a lot easier to express things in terms of values instead of steps (mathematicians have been doing this since long before computers). Expressing things in terms of values in a universe without call-by-need will result in a lot of useless computations, so call-by-need is a must.

Eight, done! This is Haskell. No functors, monads, arrows, categories or lists needed.

Why this post? Well, I don’t know. It just occurred to me that if you really go into following good coding practices in Java (e.g. avoid null, use immutable objects), you will eventually feel familiar with functional code. Add some more things to the mix, and you end up with Haskell. I think people feel a bit scared at first contact with Haskell (and family) because of the academic and mathematical atmosphere it has, but in the end it is just a lot of good practices that you are kind of required to comply with.

Using Facebook’s Flux architectural style for game development in Unity 3D

I decided to work again in an old game project. The game is named “Shotem” and the mechanic is quite simple: coins start falling from the sky and you need to “shot them” (got it?). Tap on a coin to shoot it, you gain score if you hit and you lose score if you miss the shot or if a coin falls off the screen (in case you didn’t tap it). You have seven bullets to use, each shot (finger tap) consumes a bullet and you need to shake the mobile device to reload your bullets.

The game is still a work in progress, but I added the following video in order to show that it actually works in real life:

I’ll write the history of the development process of this game. It started in a very naive form, then I converted it to Flux style and left it alone for three months. Now I’m coming back to it and had a pleasant surprise to read the code after forgetting about it. I think Flux style made it easy to continue the project were I left it. This post is 100% opinion based. Please, take a seat.

The first version I coded was very straightforward. Each coin was a GameObject with rendering and game behavior logic. All game state were inside a Singleton and two other objects were responsible for creating coins and handling user taps. Not organized at all.

I was interested in how to code the “reload by shaking” feature. As soon as I got it working, I lost my interest in the game mechanic itself. This happened quite fast actually, Unity 3D has a very nice class to use for dealing with the mobile device gyroscope: Input.gyro.

At the same time, I got in touch with Facebook’s Flux architectural style. I tried it in some web projects and had a nice feeling about it. It seemed easier to write, maintain and understand code written in Flux style than the code written in MVC fashion. So, I decided to rewrite the code of Shotem in Flux style.

At first, it didn’t seem to fit into Unity’s way of doing things. But I worked it out and coded it anyway. It worked fine, then I left the code alone.

Three months later I’m coming back to this project and I didn’t remember that I tested Flux style in it. At first I thought: “oh no, I’ll need to delete this project and start it over, why did I do it?” Then I did read the code and look at the project structure: I was amazed at how easy it was to get things back on track, I were able to get productive again in less than five minutes! What a pleasant surprise!

Now, I feel that I should share this with the rest of the world. I appreciate feedback, so if you feel that using Flux style in game development is madness or if you feel like giving it a try too, leave a comment.

From now on, I’ll use some terms from Flux, e.g. Store, Dispatcher, Action. I won’t explain what are their meanings, so feel free to take a little detour and read the official Facebook’s Flux website to get a summary of it.

I created a Dispatcher class to register the Stores, dispatch actions, track dependencies between Stores and ensure that the Actions do not cascade. The Dispatcher, in it’s full glory, is here:

using System;
using System.Collections.Generic;

using Shotem.Actions;

namespace Shotem.Flux {

    public class Dispatcher {
     
        private Dictionary<int, Store> stores;
        private HashSet<int> calledStores;
        private ShotemAction handlingAction;
        private int lastKey;
        private bool inDispatch;

        public Dispatcher() {
            stores = new Dictionary<int, Store>();
            calledStores = new HashSet<int>();
            handlingAction = null;
            lastKey = 0;
            inDispatch = false;
        }

        public int Register(Store store) {
            int key = lastKey + 1;
            stores.Add(key, store);
            lastKey = key;
            return key;
        }

        public void Dispatch(ShotemAction action) {
            if (inDispatch) {
                throw new Exception("double dispatch");
            }

            inDispatch = true;

            calledStores.Clear();
            handlingAction = action;
            foreach (int k in stores.Keys) {
                if (calledStores.Contains(k)) {
                    continue;
                }
                calledStores.Add(k);
                stores[k].Handle(action);
            }

            inDispatch = false;
        }

        public void WaitFor(int registrationKey) {
            if (!inDispatch) {
                throw new Exception("wait out of dispatch");
            }

            if (calledStores.Contains(registrationKey)) {
                return;
            }
            calledStores.Add(registrationKey);
            stores[registrationKey].Handle(handlingAction);
        }

    }

}

The core game mechanic is encoded in three Stores: CoinStore, handling all coins in the game; GunStore, handling player’s ammunition; ScoreStore, tracking user score.

Player input may dispatch two Actions in the game: ShootAction and ReloadGunAction. To handle the physics of the game (falling coins), one Action is sent every FixedUpdate: PhysicsUpdateAction.

The Stores handle each action according to simple rules:

PhysicsUpdateAction is handled by CoinStore by spawning new coins, moving the coins in the screen and removing coins that are off the screen. ScoreStore waits for the CoinStore to finish and then updates the score by decrementing the amount of coins that were removed from CoinStore, because they have fallen off the screen. GunStore ignores this action.

ShootAction is handled by GunStore by decrementing player’s ammunition. CoinStore waits for the GunStore and ignores the action if no ammunition was used, otherwise it checks for overlapping coins in the shot area and removes them. ScoreStore waits for GunStore and CoinStore then increases the score by each coin removed or decreases the score in case an ammunition was used and no coin was removed.

ReloadGunAction is handled by GunStore to reset the player’s ammunition to seven. CoinStore and ScoreStore ignores this action.

That’s the whole game logic. Each Store is observable, the Views register themselves to receive update notifications. When the Store handles an Action that changes its state, it triggers a notification. I’ve created an abstract class Store to handle this common behavior:

using Shotem.Actions;

namespace Shotem.Flux {

    public abstract class Store {

        public delegate void StoreObserver();

        public event StoreObserver Observers;

        protected void Notify() {
            if (Observers != null) {
                Observers();
            }
        }

        public abstract void Handle(ShotemAction action);

    }

}

The listing below is the code of ScoreStore, the other Stores follow the same style:

using Shotem.Flux;
using Shotem.Actions;

namespace Shotem.Stores {

    public class ScoreStore : Store {

        private Dispatcher dispatcher;
        private CoinStore coinStore;
        private GunStore gunStore;
        private int lastKnownCoinsCount;
        private int lastKnownCartridgesLeft;

        public ScoreStore(CoinStore coinStore, GunStore gunStore) {
            Score = 0;
            this.coinStore = coinStore;
            this.gunStore = gunStore;
            lastKnownCoinsCount = coinStore.Coins.Count;
            lastKnownCartridgesLeft = gunStore.CartridgesLeft;
        }

        public void RegisterAt(Dispatcher dispatcher) {
            this.dispatcher = dispatcher;
            dispatcher.Register(this);
        }

        public int Score { 
            get; 
            private set; 
        }

        public override void Handle(ShotemAction action) {
            dispatcher.WaitFor(coinStore.DispatcherIndex);
            dispatcher.WaitFor(gunStore.DispatcherIndex);
            int coinsDelta = lastKnownCoinsCount - coinStore.Coins.Count;
            int cartridgesDelta = lastKnownCartridgesLeft - gunStore.CartridgesLeft;
            lastKnownCoinsCount = coinStore.Coins.Count;
            lastKnownCartridgesLeft = gunStore.CartridgesLeft;

            switch (action.Type) {
                case ActionType.SHOOT:
                    // Add points for each coin that is destroyed with a shoot
                    // Remove a point if used a cartridge and did not hit a coin
                    if (coinsDelta > 0) {
                        Score += coinsDelta;
                    } else if (coinsDelta == 0 && cartridgesDelta > 0) {
                        Score -= 1;
                    }
                    break;

                case ActionType.PHYSICS_UPDATE:
                    // Remove points for each coin that is destroyed with a physics update
                    if (coinsDelta > 0) {
                        Score -= coinsDelta;
                    }
                    break;

                default:
                    return;
            }

            Notify();
        }

    }

}

Setup code is done in a Singleton GameObject’s Awake method, I called it StoreHub because I use this to get the reference to the Stores from other Views:

using UnityEngine;

using Shotem.Flux;
using Shotem.Stores;
using Shotem.Actions;

namespace Shotem.Views {

    public class StoreHub : MonoBehaviour {

        void Awake() {
            Dispatcher = new Dispatcher();

            GunStore = new GunStore();
            GunStore.RegisterAt(Dispatcher);

            CoinStore = new CoinStore(GunStore);
            CoinStore.RegisterAt(Dispatcher);

            ScoreStore = new ScoreStore(CoinStore, GunStore);
            ScoreStore.RegisterAt(Dispatcher);

            ActionGenerator = new ShotemActionGenerator(Dispatcher, CoinStore, GunStore, ScoreStore);
        }

        public Dispatcher Dispatcher { 
            get; 
            private set; 
        }
        
        public CoinStore CoinStore { 
            get; 
            private set; 
        }
        
        public ScoreStore ScoreStore { 
            get; 
            private set; 
        }
        
        public GunStore GunStore { 
            get; 
            private set; 
        }
        
        public ShotemActionGenerator ActionGenerator { 
            get; 
            private set; 
        }

    }

}

ShotemActionGenerator is a helper class to create Actions and send them to Dispatcher, nothing fancy.

The View classes are also simple, for example, the game may play three different sound effects when the GunStore is updated: when a bullet is shot, when user tries to shot without ammunition left and when the gun is reloaded:

using UnityEngine;

using System.Collections;

using Shotem.Flux;
using Shotem.Stores;

namespace Shotem.Views {

    public class GunSoundsView : MonoBehaviour {

        public AudioClip ShootClip;
        public AudioClip ReloadClip;
        public AudioClip EmptyGunClip;
        private GunStore gunStore;
        private int lastKnownCartridgesLeft;
        private AudioSource audioSource;

        void Start() {
            audioSource = GetComponent<AudioSource>();
            gunStore = FindObjectOfType<StoreHub>().GunStore;
            lastKnownCartridgesLeft = gunStore.CartridgesLeft;
            gunStore.Observers += OnGunStoreUpdate;
        }

        private void OnGunStoreUpdate() {
            int cartridgesLeft = gunStore.CartridgesLeft;
            if (cartridgesLeft == lastKnownCartridgesLeft && cartridgesLeft == 0) {
                audioSource.PlayOneShot(EmptyGunClip);
            } else if (cartridgesLeft < lastKnownCartridgesLeft) {
                audioSource.PlayOneShot(ShootClip);
            } else {
                audioSource.PlayOneShot(ReloadClip);
            }
            lastKnownCartridgesLeft = cartridgesLeft;
        }

    }

}

Another view shows the quantity of ammunition remaining, which are just children GameObjects with Renderers that I enable or disable based on the GunStore state:

using UnityEngine;

using Shotem.Flux;
using Shotem.Stores;

namespace Shotem.Views {

    public class CartridgesLeftView : MonoBehaviour {

        private GunStore gunStore;
        private Renderer[] bullets;

        void Start() {
            bullets = GetComponentsInChildren<Renderer>();
            gunStore = FindObjectOfType<StoreHub>().GunStore;
            gunStore.Observers += OnGunStoreUpdate;
            OnGunStoreUpdate();
        }

        private void OnGunStoreUpdate() {
            int cartridgesLeft = gunStore.CartridgesLeft;
            for (int i = 0; i < cartridgesLeft; ++i) {
            	bullets[i].enabled = true;
            }
            for (int i = cartridgesLeft; i < bullets.Length; ++i) {
            	bullets[i].enabled = false;
            }
        }

    }

}

There is a View to show the score, one to show a tip to remind the player to reload the gun when it’s empty, another to handle the renderers of each coin visible in the screen, etc. The entire game is made in the same solid base, or may I say “solid flux“. Data always flows in a single direction without cascading, there is always an Action that enters the system and triggers something, nothing happens if no Action is dispatched.

I don’t know if this design can scale to a big game project, as the style as it is now depends on it running in a single core. But, none of my games are that intense, so I will try to finish this game with Flux. I guess that using Flux will also make it easier to create automated tests of the game mechanic, as it is self-contained. Maybe I’ll post some follow up thoughts on it.

Below is an overview image of the current flux of the game. I decided to call “Inception” the layer that generates the Actions, Flux do not give it a name.

Thanks for your time,

Code reuse considered harmful

The title is intended to call for attention. This post is about one perspective of software development in the light of my own experience in the area, it won’t contain anything really revealing and is not to be taken as an absolute true for life. It’s a rant. I hope you have a good time reading it, feel free to leave me any kind of feedback.

I see a bunch of people praising reuse as being the prime thing of good software development, and few talking about replaceability. There seems to be a constant seek to avoid writing code that is used only once, as if it was a really bad thing. Then we end up with software that is made of conceptual factories that create factories that create the things the software really needs, yes there are two levels of factories, or more. Is this really necessary? How much time do we save by this extreme look for reusing code?

First, let me ask and answer a simple question: why duplicated code is annoying? Well, duplicated code makes it harder to change stuff. When you have the same piece of code written multiple times in a code base and you find that it needs a change, e.g. bug fix or new feature, you will need to change it in all places. Things can get worst if you don’t know all places where the code is duplicated, so you may forget to change one of these spots. The result is that duplicated code is a sign of harder maintenance and a fertile ground for further bugs to spawn. That’s why we learned to hate it. We started fighting this anti-pattern with all strength we had.

Code reuse is the perfect counter to code duplication, right? Sure, it is right, if we reuse a piece of code in two places, we have no duplication between these places. So, we did it! We found the Holy Grail of code quality, no more duplicated code, yay! But something unintended happened. Remember the old saying: with great powers, comes great responsibility. People started to be obsessed with it. As soon as they learned to use the hammer of code reuse, everything turned into a nail, when it didn’t work out in the first hit, they adjust the size of the hammer and hit it again with more effort.

This seek after code reuse led us to a plethora of abstractions that seems to handle every problem by reusing some code. Don’t get me wrong, lots of them are useful, these are the ones that were created from observation. The problem is the ones that are created from “it’s cool to abstract”, or other random reason that is not true observation. We see frameworks after frameworks that try to fit every problem of the world into a single model. Developers learn to use these frameworks and suddenly find out that the framework creator is wrong and create yet another abstraction over it or creates yet another framework that tries to use a different model to solve the world.

What happens when we have a bug in one of these abstractions or we need to enhance it? Silence, for a while, then the sky turns black, you take a break, go for a walk, come back to your computer and start blaming the other developer that created the bug or that “got the abstraction wrong”, because your vision was the right one. What happened? We reused code to avoid code duplication, but we are still having the same problems: code that is hard to maintain and evolve.

My guess? We missed the enemy. Code duplication is not our enemy. Maintenance problem and rigidity of code is.

My tip? Give more focus on replaceability of code instead of reuse in your talks, codes, classes, etc. Create the right abstraction to fix the problem at hand in a way that is easy to replace the underlying code when needed. Some time in the future, you will need to change it anyway. That’s what agile methodologies try to teach us: embrace change. Planning for a design to be reused says: “my design will be so awesome, that I will reuse it everywhere.” That’s what agile says: “your design will need to change sometime, because the requirements will change, plan for the replaceability of it.” People are doing things like service oriented architecture in the wrong way because they are looking for reuse of services and not for replaceability of services, they end up with a Big Web of Mud.

That’s all folks. Thanks for your time.