ES6 Structuring and Destructuring

JavaScript ES6 contains a great new feature called  "Destructuring Assignment". It is great because among other things it allows you to do things like:

  [a, b] = [b, a];

In other words it allows you to swap the values of two variables without the help of any extra temporary variable!

More typically and usefully Destructuring Assignment can be used to de-struct an object saving values of its chosen properties into individual variables:

  var {a, b} = {a: 1, b: 2}
  // a -> 1, b -> 2


Another great ES6 feature is called "Shorthand property name". That allows you to create objects out of variables so that the  name of the variable  becomes the property-key and  value of the variable becomes the value (of the property). Like this:

  var ding = 55;
  var myOb = {ding};
  ok (myOb.ding === 55);


What may not be immediately obvious is that Destructuring Assignment and Shorthand Property Name are two sides of the same coin.  In fact I think Shorthand Property Name could and should be called simply "Structuring".

Here's an example of how structuring followed by destructuring gives us back the original (like flipping a coin):

  var ding           = {};
  var originalDing   = ding;
  var myOb           = {ding};   // STRUCTURING
  ding = "forget about it";
  ok  (ding !== originalDing);
  var {ding}         = myOb ;    // DE-STRUCTURING
  ok  (ding === originalDing);


(Note, "ok()" is my simple assertion utility-function)

LINKS:

• Destructuring
• Structuring

Copyright © 2017 Panu Viljamaa. All rights reserved 

Why Prototypical Languages (like ES6) need Classes

In "prototypical languages" like JavaScript you can use object-instances to do much anything. Typically you do this  by defining "constructors" to specify the DEFAULT properties of the group of objects created by that constructor.

After the constructor gives you the new instance you can  re-assign its properties including methods  any way  you like. Then, and this is the big draw of  Prototypical Programming,  you can use that modified object as the prototype for further objects. Any object can serve as the prototype for any number of further objects ... which can serve as the prototype of yet further objects and so on. Convenient.


So why does ECMAScript 2015 need "classes"?

In the prototypical paradigm any object can be a "version" of any other object. This may sound like a great idea at first, a great extension, instances can act as "classes" too.  Why not!  More power to you. Why artificially limit the ability to use any object as a "prototype" from which new objects similar to it are derived?

The short answer is:  Classes are  constraints. Classes are contracts . Classes are invariants. Those make your program's behavior  easier to reason about.

Classes describe the properties of all their instances, so when you see an instance, and you know its class, you know what properties, especially, what methods it has.  If you know the class you also know what those methods do, or are supposed to do.

Now if any object can have its own set of methods, which is possible in the prototypical paradigm, it becomes harder to know what properties and methods any instance has, what are its methods and what can you expect from their behavior. That  makes it harder to UNDERSTAND such a program, whether written by you or someone else.

Why understandability is the most important property of Software?

Understanding what software does, is THE great big challenge of Software Engineering. If you don't understand how a program works you can't modify it because any small change in one place could have big effects in other parts of the program, possibly crashing it under some conditions. If you can't modify it you can't improve it.  Therefore, if you have to modify it you do it very carefully. Which  means you can only improve it very slowly. And each improvement is getting more expensive (assuming each improvement is as difficult to understand as the previous ones).

If you can understand your program, you can improve any other property of it. If you can't, you can't.

A class is a declaration of the properties and behavior of the set of objects created by that class. It means you know much about any object simply by knowing its class. That makes it much easier to  understand  what your program does, as a whole.

If it walks like a Duck it may be a Duck. But it may bark like a Dog. It might. You just don't know.

If it IS a Duck, it will  not  bark like a Dog. If it is an instance of a class, it will behave as instances of that class do in all the ways prescribed by that class. That's why we need classes.

LINKS:

• ES6 Classes
• panulogic
• WhyES6Classes

Copyright © 2017 Panu Viljamaa. All rights reserved 

Technical Debt Increases Agility

You might think that "Agility" is a good thing, and "Technical Debt" is bad. Right?
Well it depends.

Of course it's great to have no debt. But if you had taken that loan last year you could have invested in the stock-market and become rich and it would be even greater than just "having no debt".

When you're working on a programming project you might spend most of your time refactoring your code, to avoid technical debt. Or you could spend your time getting the software out to the users, no matter how much technical debt it carries.

Making sure your software has "no technical debt" will help you in the FUTURE when you need to change and adapt and maintain your software. But using resources now to get rid of technical debt decreases your CURRENT AGILITY, your ability to produce value to the users right now. If you can't help users fast you're not very agile.

There's no clear-cur rule as to how much debt a business should carry, or how much technical debt a given software project should have. Debt is not a bad thing if it helps you be agile, right now.

https://twitter.com/panulogic/status/849331316218896385


Copyright © 2017 Panu Viljamaa. All rights reserved