Constructors, superconstructors and Swift

Recently I was looking at the language tutorial of Swift. It is totally different from Java. It resembles more to C++ in its structure. It is compiled code, no VM, no garbage collection (it uses reference counting that is more like C++ smart pointers). At the same time it is a modern language that tries to get all the good constructs from other languages. Some part of the tutorial is easy to read when the construct is similar to Java. In that case terminology and the way the language designer was thinking is the same as in Java that I know well. In other cases the approach is totally different. In that case it is harder to understand the language construct but the same time there is some intellectual reward.

One such aspect is class constructor. It has lots of similarities to Java constructors. The functionality of the constructor is the same as in Java: it has to initialize the object. Fields have to be initialized almost the same way as in Java. Though Java allows you to have non-final fields to keep some default value (zero or null), Swift requires that all fields are initialized or have explicit default values. Some way I can understand that restriction: Swift tries to get rid off the one million dollar mistake, the null value. (It calls it nil, and has build-in optional value handling.)

The interesting thing is how superclasses are initialized. In Java the super constructor has to be invoked by the constructor before any other code is executed. There is a good reason for it. The class inherits fields from the super class and before executing the super constructor the part of the object that belongs to the super class is not properly initialized. Initializer blocks make it even more complex, but the essence is the same.

Swift on the other hand allows you to call the super constructor any time from the child constructor. You may think that Swift in this sense is not so restrictive. But it is a modern language and avoids all messy constructs, like uninitialized variables, half initialized objects or even implicite null values in variables. Knowing that I could soon realize reading the tutorial that Swift is not less restrictive. It has more complex rules.

Swift defines a two phase initialization process. It does not require that the very first thing an initializer does is invoking the super constructor, but it does not allow the initializer to do much before doing so. Very specifically the constructor can not access any of the fields in the first phase.

The only extra functionality is that this way the constructor can use the constructor arguments to decide which super constructor to invoke. This is not possible in Java.

These are the facts. The rest is subjective.

Should I miss this possibility in Java? Several years of experience show that we can program with the restrictions of Java successfully and I have never felt the lack of this feature as a huge burden.

At the same time I feel that Swift’s more complex rules may be confusing and complex to learn and get experience with for a novice programmer.

But neither languages are for novice programmers, and also I got used to the restrictions of Java I live with. If you, as a programmer, get too much freedom from a programming language you also get the numerous possibilities to create bad code. Restrictions are good. Freedom is slavery. Or not? This may lead too far.

Do Not Create DSL for the Customer

Domain Specific Language (DSL) solutions are many times created with the intent to give a tool to the hands of the customer representatives (business people) to do the configuration of the application on their own. Most of these attempts fail miserably: the DSL ends in the hands of the developers. (Sometimes there can be exceptions those I have never experienced.) Why can’t business people use DSL?

That is because

customers are stupid.

After all this is the rule number one when you are working in a support organization on L1 level. And it will never change. So long as long “never” means the time until you are the customer in a situation. In that case

the customer is always right.

Right? Although it may seem funny, stupid or exagarating both of these ideas have some background and can be true to some limit no matter how contradicting they are.

The harsh and offending formulation “customers are stupid” comes from the fact that customers are not expert in your area. If you are a mechanic your customers do not know about the injectors and the valve settings. They just want the car running from A to B. If you are plumber your customers just want to have a shower and drink fresh water but they are not really interested nor knowledgable about fittings. If you are electrician your customers just want light and wiring is an unavoidable nuisance.

Customers are not stupid. They just see the world from a different angle and they do not know your profession. And this is very good, otherwise you would be jobless.

On the other side of the scale customers are not entirely right all the times. It is just the fact that they have the money you want to work for and if they are not satisfied they will not pay.

Customers pay for the value they get and not for the work you do.

Generally: you have to find a job where you can create great value with minimal work. Some people are good at it some are not that good.

You can fix their cars but it has to be a value for them. If you just refill the water in the screenwash: that is not a huge value as compared to the effort. They could do it themselves and actually today they do. Likewise if you are a plumber your service is not requested each time the client wants the water to run. Similarly there is no need for an electrician to switch the light on and off.

This is the idea of DSL. A switch on the wall is a DSL. Does it work?

Why do most of the DSL projects fail then?

What I see is that most of these project implement first the switch on the wall and the outlet to plug in the TV, washing machine and so on but then they start to go on and try to invent other tools that would support the reorganization of the wiring. Someting like a cross connection table at the electric center of the house where the customer can plug in wires to have 12V direct current in some of the outlets, 120V alternating current in other outlets and 220V in the guest room when visitors come from Europe.

I hope you get the point: DSL solutions become just too complex for the customers. First it starts off with a simple text file. Later on it is an Excell table. Then a whole buch of sheets with many columns. Even later somehow scripts emerge that help the editing and the conistency maintenance of the data. And it all supposed to be maintained by the customer.

The house will burn down! Call the firebrigade!

And you do call the firebrigade and you realize that you, as a programmer do nothing but edit XLS files and maintain scripts that edit XLS files and fix bugs that were introduced by the customer. To avoid that you invent new XLS files that the customers fills in and that the developers use as a definition manually entering, copy pasting data to the XLS that controls the application. (Btw: Excell could be anything else, some other tool, but it is just the fact of life: it is Excell.)

You wanted to focus on more advanced programming tasks and offload the everyday burden of configuration and you ended up editing XLS 10 hours a day. You made the right choice, didn’t?

So what is the right way to do it? Are DSLs doomed and should not be created?

The fact is that you can create DSL for the customer but they have to be as simple as a light switch or a tap. You can build DSL that is more complex but do not expect a customer to use it. Layer the tasks, and separate who can do what so that everybody is working on tasks where he/she can have the most added value.

Yes, this is a simple advice that is hard to execute. But we can try.