Thursday, August 30, 2018
Moving to Medium
I have started to do much of my public writing on "Medium", at
https://medium.com/@panuviljamaa
Somehow it seems a more modern simpler platform than Blogger ever was (?). It has "Edit" and "Publish", and formatting commands in popup-menu. The User Experience (UX) of Medium is clearly better engineered than at Blogger. Default editor font is Sans Serif. So editor is much more Wysiwyg than what you see in Blogger.
"Blogs" are so last century. Medium is the Message :-)
Thank you for reading these older blog-spots as well however.
I think there's some good stuff in them.
Nuggets of thought and links to published articles I tweet at https://twitter.com/panulogic .
There's also the Twitter account of my company https://www.classcloud.com/ focused on product information about its open source and commercial products at https://twitter.com/ClassCloudLLC .
Thank You
Wednesday, November 8, 2017
Smalltalk's collection iterators implemented with ES6 arrow-functions
const not = f => a => ! f(a);
const collect = f => a => (a).map (f);
const select = f => a => (a).filter (f);
const reject = f => a => (a).filter (not(f));
const detect = f => a => (a).find (f);
const inject = f => (a,i) => (a).reduce (f,i);
let double = collect (x => x * 2);
let odd = select (x => x % 2);
let even = reject (x => x % 2);
let firstOdd = detect (x => x % 2);
let addAll = inject ((x, s) => s + x);
let numbs = [2, 4, 3, 1, 5];
let doubles = double (numbs); // -> [4, 8, 6, 2, 10]
let odds = odd (numbs); // -> [3, 1, 5]
let evens = even (numbs); // -> [2, 4]
let three = firstOdd (numbs); // -> 3
let sum = addAll (numbs, 0); // -> 15
The equivalents of Smalltalk's collect:, select:, reject:, detect: and inject: can be implemented simply with the help of ES6 arrow-function as above.
Except this is not quite the same thing, and may help to clarify the difference between Object-Oriented and Functional Programming. In Smalltalk #select: etc. are methods of collection classes which can be and are re-defined for several Collection subclasses in the standard library. You call these methods upon collection instances. What the above "functional style" code does instead is create free-standing functions select() etc. which when called with a function return another function, which then can be called with an Array instance.
Once you have the definitions for select() etc. above the code becomes about as simple as it would be with the O-O approach of having reusable predefined methods like #select: etc. in the standard library. Using Smalltalk's collection primitives you would in fact also be creating "throw-away functions" as arguments of those methods. Such arguments are instances of "BlockClosures" which is what functions are called in Smalltalk.
So what's the point of implementing the above when map() filter() reduce() and find() already exist in JavaScript? Well first I think there is value in naming all of these operations somewhat similarly, to make them easy to remember and to make it clear they really are part of the same group. Collect, select, reject, detect and inject all rhyme with each other, they are all different ways of iterating over arrays.
Secondly the above definitions do not simply duplicate the behavior of map() etc. The functions collect() etc. are not methods of Array. They are functions which take a function as argument and return another function - which can then be called with an array argument to iterate over it with the specific behavior given by the argument-function of collect() etc. This gives you a bit more reuse, you can call functions like 'even()' from many places without having to duplicate the original argument that was given to 'reject()' every time you need this behavior.
Copyright © 2017 Panu Viljamaa. All rights reserved
const collect = f => a => (a).map (f);
const select = f => a => (a).filter (f);
const reject = f => a => (a).filter (not(f));
const detect = f => a => (a).find (f);
const inject = f => (a,i) => (a).reduce (f,i);
let double = collect (x => x * 2);
let odd = select (x => x % 2);
let even = reject (x => x % 2);
let firstOdd = detect (x => x % 2);
let addAll = inject ((x, s) => s + x);
let numbs = [2, 4, 3, 1, 5];
let doubles = double (numbs); // -> [4, 8, 6, 2, 10]
let odds = odd (numbs); // -> [3, 1, 5]
let evens = even (numbs); // -> [2, 4]
let three = firstOdd (numbs); // -> 3
let sum = addAll (numbs, 0); // -> 15
The equivalents of Smalltalk's collect:, select:, reject:, detect: and inject: can be implemented simply with the help of ES6 arrow-function as above.
Except this is not quite the same thing, and may help to clarify the difference between Object-Oriented and Functional Programming. In Smalltalk #select: etc. are methods of collection classes which can be and are re-defined for several Collection subclasses in the standard library. You call these methods upon collection instances. What the above "functional style" code does instead is create free-standing functions select() etc. which when called with a function return another function, which then can be called with an Array instance.
Once you have the definitions for select() etc. above the code becomes about as simple as it would be with the O-O approach of having reusable predefined methods like #select: etc. in the standard library. Using Smalltalk's collection primitives you would in fact also be creating "throw-away functions" as arguments of those methods. Such arguments are instances of "BlockClosures" which is what functions are called in Smalltalk.
So what's the point of implementing the above when map() filter() reduce() and find() already exist in JavaScript? Well first I think there is value in naming all of these operations somewhat similarly, to make them easy to remember and to make it clear they really are part of the same group. Collect, select, reject, detect and inject all rhyme with each other, they are all different ways of iterating over arrays.
Secondly the above definitions do not simply duplicate the behavior of map() etc. The functions collect() etc. are not methods of Array. They are functions which take a function as argument and return another function - which can then be called with an array argument to iterate over it with the specific behavior given by the argument-function of collect() etc. This gives you a bit more reuse, you can call functions like 'even()' from many places without having to duplicate the original argument that was given to 'reject()' every time you need this behavior.
Copyright © 2017 Panu Viljamaa. All rights reserved
Thursday, July 27, 2017
Factory Pattern
Much has been written about the Factory-pattern, I assume. Here's my viewpoint on it.
I was puzzled a bit when I first read about it. Why? Because I was mostly programming in Smalltalk at the time. In Smalltalk the ONLY way you can create objects is by using the Factory Pattern. You create new objects by calling the class-method 'new'. So if you always follow a pattern, it's not really a pattern any more, is it? It's like fish in the water. What is this thing "water" they keep talking about?
I take it a bit further. For a Smalltalker the Factory-pattern is like air. Without it they would be dead. Without it they couldn't create any objects and thus couldn't write any Smalltalk programs and thus couldn't make a living as a Smalltalker.
But it is easy to see the benefits of using Factory (as opposed to not using it) in languages like C++ and Java and JavaScript. You create object-instances by calling (typically static) methods, not by calling constructors directly. This means you can have more than one such method per class. And you can have more than one class implementing a factory-method of the same name.
In Smalltalk in contrast there are no "constructors". You don't need them _because_ every Smalltalk-class implements the Factory pattern, because the class-method 'new' is inherited to every class, from the root-class Object.
What the Factory pattern does is it abstracts away from the IMPLEMENTATION of the results of the class- (or "static") methods used to produce the objects. Think about the proverbial Sausage Factory. You don't really need to know what goes on inside the factory. You only care that you get a Hot Dog when you order one, and you get a Bratwurst when you order that.
Depending on the class upon which you call the (same) class-method the result can be an instance of any number of different classes. You need not care which exact class it is, as long as it behaves like you expect. And depending on the (different) class-method you call on any of the classes the result can be an instance of a different classes, giving it different properties.
Above may sounds like a complicated descriptions, but it's just trying to express the two main properties, two main features of Factory-pattern:
1. A Factory can produce multiple different products, depending on what you order
2. There can be multiple factories which return their own different product even though you make the exact same "order" to each of them .
This separates the implementation = the way a factory manufactures its products, from their specification = what their products are. And it gives you flexibility in deciding whether you create one factory with many products, or many factories each producing just one or a few products.
Factory Method Pattern (Wikipedia)
Copyright © 2017 Panu Viljamaa. All rights reserved
I was puzzled a bit when I first read about it. Why? Because I was mostly programming in Smalltalk at the time. In Smalltalk the ONLY way you can create objects is by using the Factory Pattern. You create new objects by calling the class-method 'new'. So if you always follow a pattern, it's not really a pattern any more, is it? It's like fish in the water. What is this thing "water" they keep talking about?
I take it a bit further. For a Smalltalker the Factory-pattern is like air. Without it they would be dead. Without it they couldn't create any objects and thus couldn't write any Smalltalk programs and thus couldn't make a living as a Smalltalker.
But it is easy to see the benefits of using Factory (as opposed to not using it) in languages like C++ and Java and JavaScript. You create object-instances by calling (typically static) methods, not by calling constructors directly. This means you can have more than one such method per class. And you can have more than one class implementing a factory-method of the same name.
In Smalltalk in contrast there are no "constructors". You don't need them _because_ every Smalltalk-class implements the Factory pattern, because the class-method 'new' is inherited to every class, from the root-class Object.
What the Factory pattern does is it abstracts away from the IMPLEMENTATION of the results of the class- (or "static") methods used to produce the objects. Think about the proverbial Sausage Factory. You don't really need to know what goes on inside the factory. You only care that you get a Hot Dog when you order one, and you get a Bratwurst when you order that.
Depending on the class upon which you call the (same) class-method the result can be an instance of any number of different classes. You need not care which exact class it is, as long as it behaves like you expect. And depending on the (different) class-method you call on any of the classes the result can be an instance of a different classes, giving it different properties.
Above may sounds like a complicated descriptions, but it's just trying to express the two main properties, two main features of Factory-pattern:
1. A Factory can produce multiple different products, depending on what you order
2. There can be multiple factories which return their own different product even though you make the exact same "order" to each of them .
This separates the implementation = the way a factory manufactures its products, from their specification = what their products are. And it gives you flexibility in deciding whether you create one factory with many products, or many factories each producing just one or a few products.
Factory Method Pattern (Wikipedia)
Copyright © 2017 Panu Viljamaa. All rights reserved
Thursday, April 20, 2017
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:
Copyright © 2017 Panu Viljamaa. All rights reserved
[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:
Copyright © 2017 Panu Viljamaa. All rights reserved
Thursday, April 13, 2017
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:
Copyright © 2017 Panu Viljamaa. All rights reserved
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:
Copyright © 2017 Panu Viljamaa. All rights reserved
Tuesday, April 4, 2017
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
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
Saturday, March 25, 2017
Misssing Pattern in Model-View-Controller
MVC confusion must largely stem from the fact that the original MVC pattern was implemented in Smalltalk and in Smalltalk everything is an Object. With the Web this is not so. You have HTML, you have web-server, you have browser and you have database. It gets confusing trying to fit it all into "MVC". Understanding Model-View-Controller is an example of a great explanation of Model-View-Controller for the Web. Still I think it misses one crucial part of MVC as originally envisioned, and implemented in Smalltalk.
What is the main point of Smalltalk MVC seldom included in descriptions of "Web-MVC"? It is not that Model View and Controller are "separate". It is pretty obvious they should be. No spaghetti-code please. The main point is what makes M V and C capable of working together EVEN THOUGH they are "separate"...
The original MVC solution for connecting the parts is the Observer-pattern. A View subscribes to events broadcast by the model which are of relevance to that particular View. This means the model is unaware of the existence of the view, yet it is able to notify the view(s) when specific aspects of it change. Yes "aspect" is a key term in early descriptions of MVC.
The Model "broadcasts" events about changes happening to it. But implementation-wise the "system" must take care those events are propagated to the proper recipients. This invisible part of MVC, its event-delivery sub-system goes largely missing in most explanations of "Web-MVC".
So, MVC is more than M + V + C. It is M + V + C + event-delivery sub-system that allows M V and C to communicate with each other by event subscription, thus remaining minimally dependent on each other.
Another misconception must be that there is a Model, a View and a Controller. In the original Smalltalk MVC a major emphasis was on the idea that there were MULTIPLE VIEWS for each model, each displaying a different "aspect" of it, and having its own controller. Models are often composed of parts which tmelselves are models too. It is really more like Models-Views-Controllers. In Web-MVC the web-page is typically the one and only "view" presenting some underlying something, vaguely referred to as "model".
There is value in categorizing parts of any application into a Model, View and Controller. But that is not close to being the same as the MVC-pattern in Smalltalk.
A pattern is in the eye of the beholder. The pattern I see in Smalltalk called MVC is multiple Views presenting different aspects of the model, communicating with it via event-subscription, driven by user-interaction events produced by multiple Controllers, of different classes. Controller modifies the model, model broadcasts information about changes to its different aspects, views that are "tuned in" to the specific channel for that aspect receive notifications of changes to it, so they can update their state, their "looks" by asking the view for the current value or state of the "aspect" in question.
The essence of MVC is not that there is M, V and C. It is how the M and V and C communicate, with each other.
Links:
Understanding model-view-controller
Model-View-Controller
Observer-pattern
Copyright © 2017 Panu Viljamaa. All rights reserved
https://twitter.com/panulogic
What is the main point of Smalltalk MVC seldom included in descriptions of "Web-MVC"? It is not that Model View and Controller are "separate". It is pretty obvious they should be. No spaghetti-code please. The main point is what makes M V and C capable of working together EVEN THOUGH they are "separate"...
The original MVC solution for connecting the parts is the Observer-pattern. A View subscribes to events broadcast by the model which are of relevance to that particular View. This means the model is unaware of the existence of the view, yet it is able to notify the view(s) when specific aspects of it change. Yes "aspect" is a key term in early descriptions of MVC.
The Model "broadcasts" events about changes happening to it. But implementation-wise the "system" must take care those events are propagated to the proper recipients. This invisible part of MVC, its event-delivery sub-system goes largely missing in most explanations of "Web-MVC".
So, MVC is more than M + V + C. It is M + V + C + event-delivery sub-system that allows M V and C to communicate with each other by event subscription, thus remaining minimally dependent on each other.
Another misconception must be that there is a Model, a View and a Controller. In the original Smalltalk MVC a major emphasis was on the idea that there were MULTIPLE VIEWS for each model, each displaying a different "aspect" of it, and having its own controller. Models are often composed of parts which tmelselves are models too. It is really more like Models-Views-Controllers. In Web-MVC the web-page is typically the one and only "view" presenting some underlying something, vaguely referred to as "model".
There is value in categorizing parts of any application into a Model, View and Controller. But that is not close to being the same as the MVC-pattern in Smalltalk.
A pattern is in the eye of the beholder. The pattern I see in Smalltalk called MVC is multiple Views presenting different aspects of the model, communicating with it via event-subscription, driven by user-interaction events produced by multiple Controllers, of different classes. Controller modifies the model, model broadcasts information about changes to its different aspects, views that are "tuned in" to the specific channel for that aspect receive notifications of changes to it, so they can update their state, their "looks" by asking the view for the current value or state of the "aspect" in question.
The essence of MVC is not that there is M, V and C. It is how the M and V and C communicate, with each other.
Links:
Understanding model-view-controller
Model-View-Controller
Observer-pattern
Copyright © 2017 Panu Viljamaa. All rights reserved
https://twitter.com/panulogic
Subscribe to:
Posts (Atom)