The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says Hmm. I think I’ve seen something like this before – John D. Cook
In the early years, software applications were tiny, compared to what we build today. In any given application, one could say, there were only a handful of error scenarios to deal with. Besides, error reporting, if not error handling, lacked finesse. Just slap the user with something red enough, and just say An error occurred.
Continue reading A Rambling on Error Handling
Enough! JavaScript had us in its grip for long with its foot guns. The first time I heard the term Hoisting, I had no idea about it and misheard as hosting. You declare variables using var happily, and you have to come to peace with yourself that it is okay to hoist the vars (lift’em all to the top-most scope). I can’t believe JS convinced the rest of us that it was okay. Then came ES6 and saved us. let fixed the scoping. const provided immutability. At least now, you can say JavaScript supports functional programming.
JavaScript got feathers on its hat –
letandconst.
Immutability, the cornerstone of functional programming, has many facets.
Not every (mainstream) language supports all the facets; at least not per what each facet stands for. That’s what I will talk about today. The various facets of immutability from a theoretical perspective, and briefly show how some of the mainstream languages have adopted and support these facets in their own way.
A great deal of thought goes into language design. Eric Lippert’s posts is a living testament, at least for C#. Syntax and idioms are also part of the language design. When designing a language, the designers have to also consider its future. For instance, when designing C#, Anders and others should have thought of and planned for what’s coming in then upcoming version(s) of C#. Such level of forethought might be seem daunting for an outsider. But the language designers are good at what they do, and most importantly, they know what they are doing. Well, in most cases!
Functional programs treat functions and data alike. No discrimination, if you will. That means, you can declare and use functions – assign to variables, pass to other functions etc., the same way you would play with variables.
A canonical example of a functional program would show how to pass functions as parameters to other functions (higher order functions). It would also show how one can create functions on the fly (lambdas or anonymous functions) and also assign it to a variable, which is of a predefined function type; either the compiler deduces or aligns to the calling context.
There is one important attribute of data that is mostly forgotten. It can be declared almost anywhere, particularly within functions. Local variables, remember? If we agree to treat data and functions alike then we should be able to declare a function inside another. Errrk! Why would anyone want to do that? Seems like JavaScript.
Logging? What’s there to talk about logging? It’s straightforward. Use the one of the log levels and log it.
The ubiquitous log4j‘s website says …
ERROR level designates error events that might still allow the application to continue running
FATAL level designates very severe error events that will presumably lead the application to abort
INFO level designates informational messages that highlight the progress of the application at coarse-grained level
WARN level designates potentially harmful situations
That is the theory of it. Let me tell you my opinion on a more practical matter.
Creating objects without defining types is considered a great flexibility in JavaScript. JavaScript treats objects nothing more than key-value pairs. Yeah, you can declare functions in the object but they are still part of the key-value philosophy. Bottomline: JavaScript did not start out as an object oriented language.
Typically, objects are created on the fly1 using the object literal syntax:
let obj = {
name: "Will",
age: 26
};
There are scenarios when creating objects on the fly is indeed a flexibility.
