I’ve been talking about functional JavaScript for a few posts, but, to be honest, it’s nice to put the theory aside and just practice thinking and writing functionally. With that in mind, let see what we can do about fixing some “copy-n-paste” code. […]
READ MORELast time I took a quick look at why JavaScript can be used in a functional manner, primarily though the use of higher-order functions. Another way of putting this is that functions are objects in JavaScript, in the sense that they can be passed to and returned from other functions. And once you say “objects” as a programmer, you start thinking about things like composition, state, inheritance, and so on. […]
READ MOREOver the Christmas break, when traditionally things are a little quieter at work, I do a bit of research into topics that interest me and that might have some bearing on our future products. This year was no exception and I decided to investigate React, Facebook’s library (framework?) for building user interfaces for the web. It’s a fascinating library to be sure (and I’ll talk more on it in another post), but there was one paradigm it uses which I haven’t really talked about before: immutability. Don’t get me wrong: sure, React components have properties and state, but the way they change (or rather are allowed to change) is very circumscribed. […]
READ MOREThe one issue that’s weird about JavaScript that I’ve found is that it has no compiler: the first time you find a bug is when you run your code, not when you compile it. So, since I’m adamant about writing “good” JavaScript code as I write it, I’ve installed a couple of JSLint plug-ins, one for Visual Studio and one for Sublime Text. JSLint is Douglas Crockford’s linter for JavaScript and, although utterly (perhaps barmily?) strict in certain areas, is the one I’ve settled on for checking/validating my code before I run it. […]
READ MORESo, I read a blog post about declaring functions in JavaScript recently. It was just about technically correct as far as it went, but, ow, the way it was written hurt (missing semicolons, invalid code samples, etc). I’ll decline to link to it, thanks very much, but instead I’ll bring out its main points together with a recommendation or two (that, in fact, the original blog post did not). […]
READ MOREIt started like this: I was reading some JavaScript code, written – he says charitably – some years ago. Much simplified, it looked something like this, with all identifiers renamed to protect the guilty: […]
READ MOREThis whole thing started out as a nice-to-have. I have a blog (you’re reading it). I have a URL shortener (jmbk.nl). They are separate apps on separate domains. When I publish a post here, I diligently create the short URL for it manually in order to publish that short URL on social sites (the URL shortener has some minimalist stats associated with each short URL; so minimal, it’s only a count of the number of times it was used). Yeah, I know, silly, huh: why can’t each post generate its own short URL? […]
READ MOREI was reading some JavaScript code the other day, because, you know, reading someone else’s code gives you insights and inspirations to improve your own, when I came across this function to calculate the maximum element in an array: […]
READ MOREThere’s a concept in functional programming called currying which gives you the ability to create one function from another, and have the created function call the original but with some arguments prefilled in. To be ultra-rigorous, we assume the original function has n arguments, and currying produces a chain of n functions each taking one argument to produce the same results as the original. We, however, will skip that rigorous definition since it’s too constricting for our discussion here. Instead we’ll talk about partial function application, but call it currying anyway. In essence: we want to call function A that takes lots of parameters, but since some/most of them are preset to some default values, we’d prefer having another function B that calls A filling in those presets to save time/effort. […]
READ MOREIn C#, we have implicit and explicit conversions. In both cases the idea is that we, the readers of the code, are not surprised by any conversions that happen. That’s why we can freely intermix ints with floats in a floating point calculation and everything turns out just fine. The ints are implicitly converted to floats (there’s no data loss) and the calculation comes out right. However, when there’s a possibility of some kind of data loss (say, converting a ulong to a long variable) you have to explicitly state the conversion in order to say “yep, I know what I’m doing; move along, nothing to see here.” Of course, the explicit conversion does come with an implied contract – that you have, you know, actually determined that the possible loss of data is benign – but otherwise just have at it. […]