DEV Community: SlimTim10

TypeScript's Hidden Feature: Subtypes

SlimTim10 — Thu, 07 Dec 2023 13:25:18 +0000

This is a really cool thing in TypeScript I've been exploring recently. It turns out you can make subtypes without any extra libraries or tools! And the code to do it is really easy.

Imagine you could finally have types for positive integers or non-empty strings where you need them:

type PositiveInteger = ???
type NonEmptyString = ???

type Product = {
  name: NonEmptyString
  description: string
  priceCents: PositiveInteger
}

const addToCart = (product: Product, quantity: PositiveInteger, cart: Cart) => Cart {
  // add a product, not having to worry about the quantity being a negative number or 0
}

Then you wouldn't have to handle weird edge-cases like a product with an empty name, or a quantity that's fractional or negative.

You could even strictly accept pre-validated parameters:

type ValidName = ???
type ValidBirthYear = ???

// This function will only accept a valid name and birth year.
const register = (name: ValidName, birthYear: ValidBirthYear): void => {
  console.log(`Registering user "${name}" born in ${birthYear}.`)
}

What are subtypes?

In simple terms, a subtype is when you narrow down a type to be more specific.

In logical terms, B is a subtype of A when all Bs are As. For example, all cats are mammals. So, Cat is a subtype of Mammal. And Mammal is a subtype of Animal. Prime number is a subtype of Natural number. You get the picture.

You can think of making a subtype of type A by choosing a certain property that some As may have. This means B is a subtype of A defined by some predicate over A. In other words, any value of type A can be of type B if it has that chosen property. If this sounds complicated, don't worry—it will make more sense in a moment.

✨ The code ✨

Subtype: Positive Number

Starting with an example, this is how you can make a subtype for positive numbers:

type A = number
type PositiveNumber = A & { readonly __type: unique symbol }

const isPositiveNumber = (x: A): x is PositiveNumber => {
  return x >= 1
}

const x: A = 2
if (isPositiveNumber(x)) {
  const y: PositiveNumber = x
  console.log('y:', y)
}

Looks weird, right? I'll break it down line by line.

type A = number

You don't really need this line; I added it for clarity. This is just making A a type alias for number. When you're making a subtype of some custom type (instead of a primitive type), A would be that custom type.

type PositiveNumber = A & { readonly __type: unique symbol }

This is the weirdest line you have to write. This makes a new type PositiveNumber, defined as the type A along with a new property with a unique symbol. Everything about the added property is to prevent you from being able to make a value of type PositiveNumber directly, while retaining the original properties of type A.¹ You don't need to worry about exactly how this works. The cool thing is, this line doesn't change! Anytime you make a subtype, you can write this line the same way (substituting A for the (super)type of your choice). Notice that this line doesn't actually say anything about what a positive number is; it just gives the subtype a name. This line should always be paired with a predicate function:

const isPositiveNumber = (x: A): x is PositiveNumber => {
  return x >= 1
}

This is where the meaning of PositiveNumber is actually defined. More than that, without this function, you can't even make a PositiveNumber value!² This is using TypeScript's feature of type predicates. You can think of this function as returning a normal boolean value, though TypeScript gives it special treatment that brings this all together:

const x: A = 2
if (isPositiveNumber(x)) {
  const y: PositiveNumber = x
  console.log('y:', y)
}

This is where things get really interesting. Like I said, the only way to make a PositiveNumber value is to invoke the isPositiveNumber predicate function on some value x of type A. And the only place where TypeScript will accept that you can actually have a PositiveNumber value is in the scope where isPositiveNumber(x) returned true. The way I think of it, you need to use the predicate function to provide a proof that you have a value of your subtype. After all, your subtype is defined by that predicate. So in this code, y is allowed to be of type PositiveNumber if you set it to x in scope of where isPositiveNumber(x) returned true.

Shorter Version

In practice, I would write and use the PositiveNumber subtype a little differently:

type PositiveNumber = number & { readonly __type: unique symbol }

const isPositiveNumber = (x: A): x is PositiveNumber => {
  return x >= 1
}

const x: A = 2
if (isPositiveNumber(x)) {
  console.log('x:', x)
}

All I've done is remove the superfluous A type alias and the y variable. In the scope where x has been proven to be a positive number, x itself can be of type PositiveNumber. In fact, x can be treated as being a number or a PositiveNumber within that context.

General Subtype Template

The general structure for making and using a subtype looks like this:

type A = {} // some specific type
type B = A & { readonly __type: unique symbol }

const isB = (x: A): x is B => {
  // return a boolean value
  return true
}

const x: A = {} // some value of type A
if (isB(x)) {
  const y: B = x
  console.log('y:', y)
}

Why does this matter?

If you're not yet convinced of the usefulness of subtypes, reflect on why you're using TypeScript in the first place: you want to have a type checker catch any obvious mistakes during compile-time as opposed to you discovering them later during runtime. You want to make sure the data you're working with conforms to the types you've decided it should. Why not extend that notion to even more useful types? Do you really think a general number type is the best case for any numeric scenario? Surely a non-negative number or a whole number would be better for many cases.

And if you're still not convinced, maybe the next two sections will change your mind.

You can test subtypes!

Maybe you're worried your predicate function doesn't define your subtype correctly. Not a problem! You can always treat the predicate function as if it returns a normal boolean and write tests for it.

type ValidBirthYear = number & { readonly __type: unique symbol }

const isValidBirthYear = (year: number): year is ValidBirthYear => {
  const thisYear: number = new Date().getFullYear()
  return year >= 1900 && year <= thisYear
}

console.log('Tests for ValidBirthYear:')
console.log(isValidBirthYear(1900))
console.log(!isValidBirthYear(1800))
console.log(isValidBirthYear(2023))
console.log(!isValidBirthYear(2100))

More examples

I want to finish off with a bunch of pragmatic examples to show some different ways of how you might use subtypes in your own projects.

NonNegativeInteger

type NonNegativeInteger = number & { readonly __type: unique symbol }

const isNonNegativeInteger = (x: number): x is NonNegativeInteger => {
  return !(x < 0) && Math.floor(x) === x
}

const betterRepeat = (s: string, n: NonNegativeInteger): string => {
  return s.repeat(n)
}

const ex1: number = 3
if (isNonNegativeInteger(ex1)) {
  // This will run.
  console.log(betterRepeat('hello', ex1))
}

const ex2: number = 3.1
if (isNonNegativeInteger(ex2)) {
  // This won't run.
  console.log(betterRepeat('hello', ex2))
}

const ex3: number = -3
if (isNonNegativeInteger(ex3)) {
  // This won't run.
  console.log(betterRepeat('hello', ex3))
}

In the third example usage, where ex3 is -3, normally giving a negative number to the String.prototype.repeat() function would produce a runtime error. Instead, we caught it in compile-time and prevented it from happening at all!

NonEmptyArray

Non-empty arrays are very useful in functional programming.

Normally, functions like head() and last() would return undefined when given an empty array, breaking the type rules:

const head = <T>(xs: Array<T>): T => xs[0]
const last = <T>(xs: Array<T>): T => xs[xs.length - 1]

const arrEmpty: Array<number> = []
console.log('head(arrEmpty):', head(arrEmpty)) // undefined
console.log('last(arrEmpty):', last(arrEmpty)) // undefined

We can make better versions with a NonEmptyArray subtype:

type NonEmptyArray<T> = Array<T> & { readonly __type: unique symbol }

const isNonEmptyArray = <T>(xs: Array<T>): xs is NonEmptyArray<T> => {
  return xs.length >= 1
}

const head = <T>(xs: NonEmptyArray<T>): T => xs[0]
const last = <T>(xs: NonEmptyArray<T>): T => xs[xs.length - 1]

const arr1: Array<number> = [1]
const arrEmpty: Array<number> = []

if (isNonEmptyArray(arr1)) {
  console.log('head(arr1):', head(arr1))
  console.log('last(arr1):', last(arr1))
}

if (isNonEmptyArray(arrEmpty)) {
  // None of this will run.
  console.log('head(arrEmpty):', head(arrEmpty))
  console.log('last(arrEmpty):', last(arrEmpty))
}

ValidWardrobe³

I like this example because it shows how far you can stretch the predicate function. Which, it turns out, is as far as you want! As long as it returns a boolean in the end, you're good.

type Colour = 'white' | 'cream' | 'blue' | 'navy' // ...

type Wardrobe = {
  owner: {
    name: string
    age: number
  }
  tops: Colour[]
  pants: Colour[]
  shorts: Colour[]
  skirts: Colour[]
  desiredNumberOfOutfits: number
}

type ValidWardrobe = Wardrobe & { readonly __type: unique symbol }

const isValidWardrobe = (wardrobe: Wardrobe): wardrobe is ValidWardrobe => {
  const numOutfits: number =
    wardrobe.tops.length * wardrobe.pants.length
    + wardrobe.tops.length * wardrobe.shorts.length
    + wardrobe.tops.length * wardrobe.skirts.length

  return numOutfits >= wardrobe.desiredNumberOfOutfits
}

const suggestOutfits = (wardrobe: ValidWardrobe): void => {
  console.log(`Printing suggested outfits for ${wardrobe.owner.name}...`)
  // Do stuff here, knowing that wardrobe has already been validated.
}

const ex1: Wardrobe = {
  owner: {
    name: 'Alice',
    age: 22
  },
  tops: ['blue', 'white', 'cream'],
  pants: ['navy', 'blue'],
  shorts: ['navy'],
  skirts: ['navy', 'blue'],
  desiredNumberOfOutfits: 15
}
if (isValidWardrobe(ex1)) {
  suggestOutfits(ex1)
}

Validated Form Input

Let's say you have some input from a user registration form. And you have a register function whose job is to save this user data somewhere. Rather than clouding the concerns of register by validating the user data within the function, you can have it only accept data that has been previously validated!

type ValidName = string & { readonly __type: unique symbol }
const isValidName = (name: string): name is ValidName => name.trim().length > 0

type ValidBirthYear = number & { readonly __type: unique symbol }
const isValidBirthYear = (year: number): year is ValidBirthYear => {
  const thisYear: number = new Date().getFullYear()
  return year >= 1900 && year <= thisYear
}

const register = (name: ValidName, birthYear: ValidBirthYear): void => {
  console.log(`Registering user with name "${name}" born in ${birthYear}`)
}

const nameInput: string = 'test'
const birthYearInput: number = 1800

if (!isValidName(nameInput)) {
  console.log('Name cannot be empty')
} else if (!isValidBirthYear(birthYearInput)) {
  console.log('Invalid birth year')
} else {
  register(nameInput, birthYearInput)
}

PositiveInteger, NonEmptyString

You can nest subtypes in other types, too.

type PositiveInteger = number & { readonly __type: unique symbol }

const isPositiveInteger = (x: number): x is PositiveInteger => {
  return x >= 1 && Math.floor(x) === x
}

type NonEmptyString = string & { readonly __type: unique symbol }

const isNonEmptyString = (s: string): s is NonEmptyString => {
  return s.trim().length > 0
}

type Product = {
  name: NonEmptyString
  description: string
  priceCents: PositiveInteger
}

type Cart = {} // Use your imagination

const addToCart = (product: Product, quantity: PositiveInteger, cart: Cart): Cart => {
  // Add a product to the cart, not having to worry about the quantity being a negative number or 0.
  // ...

  return cart
}

Footnotes

¹ TypeScript intersections between primitives and objects are enabled to allow for making "branded primitives", which is intended to allow for nominal typing. See TypeScript FAQ. With subtypes, we're leveraging that feature for an entirely different purpose.

² Without using type assertions, which would bypass the type checker altogether.

³ Based off of my partner's Personal Stylist app.

Originally published at https://timjohns.ca.

The Dangers of Learning to Code With Training Wheels

SlimTim10 — Sun, 15 Oct 2023 13:59:19 +0000

Did you know it's not recommended to learn how to ride a bicycle using training wheels anymore?¹ It's true!² What people found is that using training wheels don't enable the rider to learn the crucial skill of balancing on a bicycle. So, while training wheels do lower the stakes when falling, they also remove the activity's essential components.

As a teacher, I've noticed the same sort of problem can come up with people learning to code. The problem is, if you learn with "training wheels" on, at some point you have to take them off. And that can be a rough transition. And, if you don't know you're using training wheels in your learning, you may not even know what skills you're missing out on.

What do I mean by "training wheels" in learning to code? Well, they can come in different forms:

Online editors
Custom libraries, frameworks, or languages designed for teaching
Code-along video tutorials

For example, the ever-popular site freeCodeCamp provides coding lessons paired with a custom-built online editor. That means you're typing code in a sandbox environment. If you make a mistake in your code, you're given a kind of error message that's different from anything a professional developer would see. You're also not able to experiment and try things that you would be able to do if you simply ran your code on your own computer, which is a huge part of being a programmer! Now, I'm not saying freeCodeCamp is bad, but you should be aware that this is a very different environment than any practicing developer uses. On freeCodeCamp, you're having your hand held so tightly that you can't find your balance on your own.

What I find is, by the end of a student taking a course with a sandbox environment, they're lost as to how to code on their own computer. They don't know how to set up a project, how to debug their code when things go wrong, or how to share their finished app with other people. These are all essential skills for any developer.

The story is similar when a student learns to code using a custom library, framework, or language. After they're finished the course, they don't know where the course's custom material ends and the stuff they can use in the real world begins. With frustration, they ask themselves, "How do I make an app without using the course tools?"

When it comes to code-along video tutorials, you're not free to make your own mistakes. So you never really get a sense of what to do when things go wrong. Believe me, in programming, things go wrong all the time. That's part of the fun! Figuring out what went wrong and why it's happening, then solving the problem is one of the biggest and best parts of programming. If you're just copying down someone else's thoughts, you're not learning how to think on your own.

Now, I'm not saying this to discourage readers from using certain resources. I just think you should be aware of when you're using training wheels and whether there may be a better option.

When I wrote Intuitive JavaScript, I purposefully left the exercises as plain *.js files to encourage the student to save the code and run their solutions on their own computer. This is closer to how a professional developer works. Getting used to the tools of the industry, like Visual Studio Code and Node.js, is essential for anyone who wants to become a working developer, and probably easier than you think!

Footnotes

1 https://www.twowheelingtots.com/training-wheels-faq/

2 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8834827/

Originally published at https://timjohns.ca.

When to use currying in JavaScript

SlimTim10 — Wed, 12 Apr 2023 22:01:45 +0000

This post is about the concept of currying, from functional programming, and when you should use it in JavaScript.

I'm going to be honest. You probably don't need to use currying in JavaScript. In fact, trying to fit it in your code is going to do more harm than good, unless it's just for fun. Currying only becomes useful when you fully embrace functional programming, which, in JavaScript, means using a library like Ramda instead of the standard built-in functions.

In this article, I'm going to start by explaining what currying is, then show how it can be useful in a functional programming context.

What is currying?

Currying is the concept that functions never need to take multiple arguments; every function only takes a single argument. If a function needs to behave as if it takes multiple arguments, it returns another function instead.

A regular, non-curried function is what you're used to seeing:

const add = (x, y) => x + y

console.log(
  add(2, 3) // 2 + 3
) // prints 5

This is a simple function that takes two numbers and returns their sum.

A curried version of the same function looks like this:

const addCurried = x => y => x + y

console.log(
  addCurried(2)(3) // 2 + 3
) // prints 5

Instead of the function taking two arguments, it takes one argument, then returns another function that takes one argument and returns the sum. Notice how we have to pass the arguments to the function using more brackets, since the arguments are passed one at a time to each nested function.

We can have as many arguments as we want this way:

const addMore = a => b => c => d => e => a + b + c + d + e

console.log(
  addMore(1)(2)(3)(4)(5) // 1 + 2 + 3 + 4 + 5
) // prints 15

Because of the way a curried function works, we can do something called partial application. This is when we give a function fewer arguments than it can take:

const addCurried = x => y => x + y

console.log(
  addCurried(2) // y => 2 + y
) // [Function (anonymous)]

If we only pass addCurried one argument, the result is a function that expects another argument. In other words, the 2 went into the x argument, so we're left with y => 2 + y. If we want, we can store this partially applied function into a variable so we can use it after the fact:

const addCurried = x => y => x + y
const add2 = addCurried(2)
// This is the same as:
// const add2 = y => 2 + y

console.log(
  add2(3) // 2 + 3
) // prints 5

console.log(
  add2(10) // 2 + 10
) // prints 12

Now we have a function add2, which is expecting a single argument. Whatever we give it, it will add 2 to it.

When is currying useful?

Like I said, in a typical JavaScript codebase, it's not. You can probably tell that the addCurried example is very contrived and doesn't demonstrate any real benefit. But if you want to go deeper down the functional programming rabbit hole, let me show you how using curried functions can be even more elegant than the typical practice.

It's all about composition.

In functional programming, composing functions is a fundamental concept. This means using one function after another on some data. It's in using composition that curried functions really shine.

In JavaScript, the way to compose two functions looks like this:

const compose = (f, g) => x => f(g(x))

const addCurried = x => y => x + y

console.log(
  compose(addCurried(2), addCurried(3))(10) // 10 + 3 + 2 = 15
) // prints 15

When using composition, you should read it as operations being done on some data from right to left. In the above example, the starting data is 10, which goes through adding 3, followed by adding 2, resulting in 15.

Let me show by example how composing a series of curried functions looks when compared to idiomatic functional JavaScript. I'm going to use an example based on a real problem I had to solve that doesn't call for any particular programming style or language.

The objective is to make a function cleanExpression that takes in a basic math expression as a string (e.g., "1 + 10 / 2") and returns a cleaned version of it. The cleaning process is to remove extra spaces and make sure the expression alternates numbers and operators (there should never be two numbers or two operators next to each other). We're dealing with single-digit numbers only.

For example, "1 + 2 2 / 3 *" cleaned would be "1 + 2 / 3".

The following is an idiomatic functional JavaScript solution. Let's call this "functional-lite".

// Helper functions
const isOperator = x => "+-*/".includes(x)

const isDigit = x => "1234567890".includes(x)

const last = xs => xs[xs.length - 1]

const init = xs => xs.slice(0, -1)

const intersperse = (sep, xs) => xs.map(x => [sep, x]).flat()

// The main function
const cleanExpression = expr => {
  const parseNext = ([acc, shouldBe], x) => {
    if (shouldBe === 'digit' && isDigit(x)) {
      return [[...acc, x], 'operator']
    } else if (shouldBe === 'operator' && isOperator(x)) {
      return [[...acc, x], 'digit']
    } else {
      return [acc, shouldBe]
    }
  }

  const chars = expr.split('')
  const alternating = chars.reduce(parseNext, ['', 'digit'])[0]
  const cleaned = isOperator(last(alternating)) ? init(alternating) : alternating
  return intersperse(' ', cleaned).join('')
}

console.log(
  cleanExpression('1    + 2 2 / 3 *')
)

And here is a more functional JavaScript solution using the Ramda library in-place of built-in functions:

const R = require('ramda')

const isOperator = x => R.includes(x, "+-*/")

const isDigit = x => R.includes(x, "1234567890")

const cleanExpression = expr => {
  const parseNext = ([acc, shouldBe], x) => {
    if (shouldBe === 'digit' && isDigit(x)) {
      return [acc + x, 'operator']
    } else if (shouldBe === 'operator' && isOperator(x)) {
      return [acc + x, 'digit']
    } else {
      return [acc, shouldBe]
    }
  }

  return R.compose(
    R.join(''),
    R.intersperse(' '),
    (xs => isOperator(R.last(xs)) ? R.init(xs) : xs),
    R.head,
    R.reduce(parseNext, ['', 'digit']),
    R.split('')
  )(expr)
}

console.log(
  cleanExpression('1    + 2 2 / 3 *')
)

Fewer helper functions are needed because Ramda implements the others, but that's not what's important. The main lines to compare are in the body of cleanExpression:

// functional-lite
const chars = expr.split('')
const alternating = chars.reduce(parseNext, ['', 'digit'])[0]
const cleaned = isOperator(last(alternating)) ? init(alternating) : alternating
return intersperse(' ', cleaned).join('')

// more functional
return R.compose(
  R.join(''),
  R.intersperse(' '),
  (xs => isOperator(R.last(xs)) ? R.init(xs) : xs),
  R.head,
  R.reduce(parseNext, ['', 'digit']),
  R.split('')
)(expr)

Ramda's compose function extends function composition to any number of functions instead of only two. Still, it should be read from right to left (or bottom to top). The above example can be understood as:

Feed in expr as the data to be operated on, which in this case should be a math expression as a string.
Split the string, turning it into an array of characters.
Use reduce to walk through the expression, building a new version that alternates digits and operators (beginning with a digit).
Take the first element of the previous result (because it returned a pair and we only need the new expression).
Remove the last character if it is an operator.
Intersperse the new expression with spaces.
Finally, Convert the new expression into a string.

This way, we can think of the solution as processing some data through a pipeline (bottom to top). The output of each step feeds into the input of the next one until we reach the end, which gets returned as a final result.

The steps of the solution are the same in both versions, but the second version looks more linear and we can clearly see each step.

For the most functional version, here's the same solution in Haskell, where all functions are curried by default and the composition operator is a dot (.):

isOperator :: Char -> Bool
isOperator x = x `elem` "+-*/"

isDigit :: Char -> Bool
isDigit x = x `elem` "1234567890"

intersperse :: Char -> String -> String
intersperse sep = init . concat . map (\x -> [x, sep])

cleanExpression :: String -> String
cleanExpression =
  intersperse ' '
  . (\xs -> if isOperator (last xs) then init xs else xs)
  . fst
  . foldl parseNext ("", "digit")
  where
    parseNext :: (String, String) -> Char -> (String, String)
    parseNext (acc, shouldBe) x
      | shouldBe == "digit" && isDigit x =
        (acc ++ [x], "operator")
      | shouldBe == "operator" && isOperator x =
        (acc ++ [x], "digit")
      | otherwise = (acc, shouldBe)

main :: IO ()
main = do
  print $ cleanExpression "1    + 2 2 / 3 *" == "1 + 2 / 3"

Conclusion

Currying is not a very complicated concept, but most people are unfamiliar with it because they have no use for it. And for good reason! It only shines when you decide to write very functional code and use composition everywhere. Languages like Haskell take advantage of this by defining all functions to be curried by default and having a very small operator for composing functions (like a dot).

For a fun exercise, try implementing Ramda's compose function on your own! It should be able to compose any number of functions, not just two.

Originally published at https://timjohns.ca.

How to Learn Web Development On Your Own

SlimTim10 — Fri, 16 Dec 2022 20:32:20 +0000

How do you learn a complex skill like web development without going to school or hiring a mentor?

Although I've taught programming for a long time, I am primarily self-taught. That's not to say I didn't learn from others along the way, but I didn't have a dedicated mentor or teacher that I learned from, and I don't attribute my knowledge to my school experiences. The tips here are from personal experience and my experience in observing and teaching others.

Choose good material

There are so many courses and books on programming and web development topics. How do you choose? In the long run, the material you start with doesn't make much difference. But in the shorter term, like the next 1-2 years, taking one path versus another can make a big difference.

One thing to look for is material that emphasizes foundational concepts. Web development is very much a trend-based industry. Programming languages, libraries, and frameworks form and disappear like bubbles in boiling water. But programming foundations last for decades. You don't want to focus on a particular trend that goes out of fashion while still having shaky foundational knowledge.

You also want to make sure the material is not spoon-feeding information. For example, I've had students come to me after taking a Udemy course on React, and even after making it through the course and building a final project, they still didn't understand the fundamentals. They couldn't build a new project and couldn't explain how state works (which is a fundamental concept in React). The problem is that the course had them follow along with videos showing what code to write, so it was a lot of "monkey see, monkey do" without helping them understand why they were writing things the way they were.

Good material will assign you work that makes you think and exercise your problem-solving skills.

Some decisions are more straightforward, like choosing which programming language to learn. Since we're talking about web development, JavaScript is your best bet. It's ubiquitous on the web and the most in-demand programming language on the market. The second best would be Ruby because the Ruby on Rails framework is very popular for building web applications. Whichever language you pick, learn one language thoroughly before moving on. Once you've grasped the logic of programming in one language, it's much easier to pick up another.

My top recommendations for starting out are:

Intuitive JavaScript
The Odin Project
Udemy (depending on the course)

I hesitate to recommend freeCodeCamp and Codecademy because they do more "monkey see, monkey do" than good teaching.

Learn to google all the things

Get used to googling things as you're coding. Like, more than you think. Professional developers google even the smallest things because it's usually faster than trying to remember the answer or checking your own notes.

The critical skill is learning how to search. You'll have to experiment to see what works and what doesn't, but as a quick tip, use quotes when you want to search something literally, like an error message (e.g., "psql: could not connect to server: No such file or directory"). Also, you don't need to click the first link and read the whole page. When I search, I open a few of the results in new tabs, then quickly skim through them to see which one is relevant. I'll often accumulate a whole bunch of tabs (usually 5-10, often more) while I'm trying to solve one problem, then close them all afterwards to make space for the next problem.

Even if you're able to google and solve a problem eventually, you can always improve your searching process. Good searching skills can make you solve problems ten times faster, literally.

Build projects

There are so many good reasons for building projects to learn web development. For one, it's as close as you can get to replicating the actual work you would be doing as an engineer on the job, so it's the best way to practice. Another reason is that you will encounter the most interesting and important problems when building projects that you can't find in exercises or books. Also, having built projects that you're proud of is the best way to combat imposter syndrome, which is too common among software engineers. When you can look back at your projects, you feel a sense of accomplishment and confidence that you have what it takes to do the work. After all, building things is what it's all about.

Of course, if you're starting from scratch, you may not be ready to start building a project. But you'll get there soon. You don't need a lot of coding knowledge to start a project. Once you've learned some of the basics, you can start building a small project right away, like a command-line app.

How do you choose a project to build?

Make sure you're not overreaching with what you want the project to do. In other words, make sure the project isn't too complex and doesn't have too many complicated features. Lots of people like to build tools for themselves. Something that makes their life easier. Don't try to make a tool for someone else; that adds a layer of complexity you don't need (trying to understand your client's needs). If you're into games, coding a game can be a great project idea. It can be a simplified clone of a game you like to play.

It's important to choose a project that you're genuinely interested in building. Research shows that interest leads to the use of deep comprehension processes, meaning you'll learn better if you're interested.¹

Join communities

Even though you're self-teaching, you don't have to be alone. You can join many communities to be surrounded by people talking about code. Chatting with people of various backgrounds and experiences can be a great way to build your network. When it comes to the job search, one of your new contacts might be just the connection you need. It can also help you feel motivated and accountable to do your work. You'll also learn to talk like an engineer by interacting with actual engineers, which helps with landing a job.

As of writing this article, these are some awesome communities you can join right away:

TorontoJS (Slack)
- Local to Toronto, Canada
- Try to find a community local to where you live!
Women in Tech
CodeBuddies (Slack)
The Programmer's Hangout (Discord)
devcord (Discord)
The Odin Project (Discord)
- More information
Reactiflux (Discord)
- Tailored to React JS and related technologies

If you need a bigger list of communities, check these out:

Be consistent

Programming concepts take time to sink in. You won't understand every concept the first time you read it. You'll have many moments along the way where you just don't get it, and you need to keep at it. Being consistent in studying will get you to the good moments where things will click, and suddenly it all makes sense.

Just like building muscles at the gym, you need to get your reps in. The difference is your brain doesn't need as much time to recover as your muscles. Do at least a little bit of coding every day. In the long run, being consistent will get you to a high level of proficiency.

Look at code on GitHub

Being a programmer isn't all about writing code. It's also about reading code. On GitHub, you can find code in virtually any programming language and on any subject. Of course, you don't want to browse random projects on GitHub and start reading any code you come across.

It's not hard to find a project on GitHub similar to something you want to make. From there, you can observe how the code is set up and what approach the author(s) took to solve the project's challenges. You can see how certain features were implemented, perhaps differently from what you imagined. You may start to notice specific patterns you hadn't thought of before that you can adopt in your own code. Keep in mind that GitHub has a very low barrier of entry, so not every project will use best practices (in fact, many projects probably don't even work!). Still, you can learn from bad code as well as good code. As much as picking up new strategies, you may also learn what not to do.

Sometimes documentation for a particular library or framework lacks helpful examples, and the only place to find it in use is in a small project on GitHub. I frequently use GitHub in this way.

Use a mix of resources

Books, websites, forums, blog posts, tutorials, videos… there are so many different places to learn from. Take advantage of the abundance of information!

Don't limit yourself to a single resource or medium when learning a concept. When you don't understand something, you might blame yourself for not being smart enough, but it's probably the case that it just hasn't been presented to you the right way. For instance, you might be stuck with understanding what a REST API is after reading a few articles, then find a great video on YouTube that clears it up in a visual way that no article or book could.

Official documentation, like reactjs.org or nodejs.org, is great for being accurate, but it's not always the best for learning. It's often too verbose or lacking in examples. Instead, find a resource that's more accessible and then cross-reference the information with the official documentation if you're worried about correctness or best practices.

If you want to learn from books, be aware that very few programming books are meant to be read from front to back like a novel. Instead, it's better to use books as references, consulting them when you need answers to specific questions.

Footnotes

¹ Tobias, S. (1994). Interest, Prior Knowledge, and Learning. Review of Educational Research, 64(1), 37–54.

Originally published at https://timjohns.ca.

5 Tips to Make the Most of a Coding Mentorship

SlimTim10 — Wed, 16 Nov 2022 18:28:17 +0000

I've been mentoring coding, programming, software development, or whatever you want to call it, for over 7 years. I choose the mentorship model over lecturing because I like to connect with each student and take a quality-over-quantity approach to teaching. If you're interested in having a coding mentor, here are some tips to give you the best chance of success.

Tip 1. Come up with project ideas

When it comes to coding, most of your real learning is going to come from building projects. And when it comes to deciding on what a project to build, it's best if it's an idea that you came up with. Sure, you can pick from a list of project ideas, make a clone of a popular app, or have your mentor suggest an idea to you, but it's never as good as thinking of a problem you want to solve or an app you wish you had. You get to be more creative and you'll be more invested in the result. It's a great feeling when you bring to life an idea you had in your head.

People sometimes find it hard to come up with their own ideas for projects, but trust me, you can do it! You have tons of great ideas in you; you just need to find them. If you like games, maybe you can make a different version of a game you like to play. Maybe you're into budgeting and you've always wanted a specific kind of tracker to help you stick to a budget.

Be ambitious! Don't worry if you think your project idea might be too big or beyond your skill level. Your mentor can help you decide on features, make sure the scope of the project is manageable, and provide support as you build it.

Tip 2. Ask lots of questions

In contrast to being a student in a course/class/cohort, when you have a mentor you can ask as many questions as you want. Take advantage of it! A mentoring session can be dedicated entirely to one question or a concept you want to delve into; it's all about you. Don't be afraid to ask about things outside of your planned learning path, like other libraries or frameworks. Be curious!

Many questions will come up as you're doing exercises or building projects.

Do I understand this concept right?

Is there a better way to write this function?

What's the difference between Git and GitHub?

Between sessions with your mentor, as soon as you think of a question you want to ask be sure to write it down. You may not remember everything you wanted to ask the next time you meet with your mentor.

Tip 3. Be honest about your time commitment

Be honest with yourself and your mentor about the amount of time you are committing to doing the work between sessions. If you frequently under work, you will not make the progress both of you were expecting and your planned timeline will not be possible. You will likely burn out before you get very far. Diligence will pay off. Put in the hours and you'll do great.

Tip 4. Put in the work to get a job

If your end goal is to get a job as a developer, there will come a point when you need to apply for jobs. This part you have to do mostly on your own. Your mentor can help you with personal branding, like updating your LinkedIn profile and making a great portfolio, but you're the one who has to search for jobs, send out your resume, and make connections.

Treat it like a full-time job. There's always something you can be doing to improve your chances at finding a job. Set targets for yourself, like sending out 10+ resumes per week. Join online communities centered around programming to meet people in the industry.

Tip 5. Make sure it's a good fit

A mentorship is a two-way street. You should be making sure it's a good fit just as much as the mentor. Aside from obvious compatibilities like scheduling times and technical knowledge, it's about the environment your mentor provides when you're learning. You should feel comfortable to approach your mentor with any question. Your mentor should never make you feel stupid. Your environment should be constantly supportive.

Like all people, different mentors will have personalities that will affect how they teach you. Maybe you want someone who's really stern and doesn't let you get away with small mistakes. Or maybe you want someone who's going to hold your hand every step of the way. As for myself, for example, I'm not the kind of mentor to push you to stay on top of the work. If you struggle with self-discipline and you need someone to constantly be on your case about doing the work, I'm probably not the right mentor for you.

Originally published at https://timjohns.ca.

6 Tips to Make the Most of a Coding Bootcamp

SlimTim10 — Wed, 09 Nov 2022 14:31:00 +0000

I was a mentor and instructor for the Web Development Bootcamp at Lighthouse Labs for over 3 years. I've seen countless students go through the bootcamp, some more successful than others. Many students get to the end of the bootcamp only to struggle to land their first job in the industry. Some never make it at all. I want to share some tips that can help you make sure your time at a coding bootcamp ends in success. As with most things in life, you get out what you put in. If you put in the bare minimum, don't expect great results out of the bootcamp. You need to put in the effort, the more the better.

Tip 1. Do the prep work

A bootcamp might market itself as 12 weeks, but in reality it's more like 6 months (or more!). The students who enter the bootcamp with some practice under their belt are the ones who will keep up and succeed in the end. You should do a bare minimum of 2 months of prep work, and more if you've never been exposed to coding in the first place. Learning to code takes time to sink in; there are no shortcuts or hacks to quickly force it into your brain. Taking a bootcamp without first trying to learn the basics on your own would be a big mistake. After the first two weeks, you would be lost and there's no time to catch up.

A good bootcamp will have suggestions for prep work materials. It doesn't really matter where you learn from, as long as it's teaching you the basics and you're writing code (not just reading!). Some of my favourites are:

Tip 2. Make connections

This is the same advice you hear about going to college/university. Talk to your teachers! They're a great connection to have, but they'll be more inclined to help you outside of the bootcamp if you separate yourself from the herd. Ask them about programming or their hobbies. You may have more in common with them than you think!

Of course, talk to your classmates too. In a way, you're all competing since you're all trying to get jobs in the same industry. But the job pool for developers is huge, so you probably won't end up competing directly with your peers. And more importantly, once you've all moved on from bootcamp your connections in the industry become even more valuable, so it's important to keep in touch. Job openings come up all the time and they're not always public. By knowing the right person at the right time, you can land your dream job before anyone else has a chance to apply.

Don't sleep on networking. It can be the best tool for your career. And remember, it's just talking to people.

Tip 3. Don't fall behind

Bootcamps have a strict, full schedule. That's what makes it a bootcamp. Everything has been planned down to the hour, and whatever time is left over, you should use it to rest. As a result, there's no time in a bootcamp for catching up. The unfortunate reality is, if you fall behind, you're left behind. So do everything you can to stay on top, or ahead, of the work.

Of course, life happens and you might have things outside of your control preventing you from keeping up. In that case, you should talk to your bootcamp manager to see what accomodations can be made for you to not be left behind (this usually means rolling over to the next cohort).

Tip 4. Practice communicating clearly

Communication is a huge part of every job interview. People want to make sure you'll be easy to work with because you communicate well. Effective communication doesn't come naturally to everyone. In a bootcamp, you will have lots of opportunity to practice, but nobody will force you to improve, so it's up to you to put in the effort.

When you ask for help from a mentor or your peers, try your best to explain your problem clearly. If you notice they have trouble understanding how to help you, try to figure out what you can do better and put it to the test with the next assistance.

When it's time to demo your project to the class, take it seriously. This is a great skill to have and you'll make use of it on the job more than you think. There will be many times where you're leading the work on a product feature and you need to bring your colleagues up to speed on it. This uses the same communication skills as a project demo.

I can't tell you how many project demos I've seen where I don't understand what the product does or who it's for. Some visual diagrams or a clear explanation can make a huge difference. When you've spent so much time on your project, it's easy to forget that someone seeing it for the first time doesn't know anything about it. It's your job to educate the audience in a clear manner what the project is, what it's for, and how it works.

Another mistake I've seen countless times is when a presenter reads from a script, in a monotone voice. Don't do this. Everyone can tell you're reading a script and they're instantly bored. It's the least engaging way to present, and therefore poor communication. Have fun with the presentation! You had fun building your project and you're proud of it, so show it with enthusiasm!

Tip 5. Be resourceful

Use the resources that your bootcamp recommends. I mean use them a lot. More than you probably think. Seriously, developers don't just remember every function name and how it works. We look things up constantly.

Also, use resources other than the ones your bootcamp recommends. In the real world, developers don't consult a trusted list of books and websites whenever they run into a problem. They simply google the error message and look at whichever results seem useful. Don't even limit yourself to written material; sometimes a video is just right for the occasion. Learning to find relevant results by searching the right terms is a skill in itself, and a surprisingly uncommon one. The solution to your problem won't always be on one of your favourite websites, but it's out there somewhere. You need to know how to find it.

Discover libraries and frameworks that the course doesn't mention. I was always impressed when a student would come up to me and say, "I found this library called X and I want to use it in my project. I read the docs and saw some examples, and it seems like a good way to do Y. Do you know how to use it?" My answer was typically, "No, but I can figure it out with you." Those students always did well in the end. Even if you don't end up using what you found, it's good to know what's out there for future projects.

Tip 6. Immerse yourself

One of the best things a bootcamp has to offer is an environment for deep immersion. Take advantage of it! Allow yourself to be immersed in coding. You'll be surprised how much knowledge you can absorb. It's the same reason the fastest way to learn a language is to live in a country where you're surrounded by it.

Spend more time thinking about coding than you thought you could. If you're not having dreams about coding, you're not doing enough.

Originally published at https://timjohns.ca.

Breaking the Order | Coding Challenge & Analysis 1

SlimTim10 — Fri, 04 Nov 2022 14:16:25 +0000

JavaScript Coding Challenge: Breaking the Order

Given an array of numbers, find the last index before the ordering breaks. Indexing should begin with 0. If the numbers start by increasing, find last index where the numbers are increasing. If the numbers start by decreasing, find the last index where they are decreasing. If there is no break in the ordering, return -1. The array will contain at least 3 numbers and the first two will be increasing or decreasing.

For example, given the array [10, 9, 8, 7, 9, 10], the result should be 3, because the 7 at index 3 is the last index where the numbers are decreasing.

More examples:

[1, 2, 4, 7, 2, 3, 1] -> 3
[1, 2, 3, 4, 5] -> -1
[10, 11, 12, 12, 13] -> 2

If you want to give this challenge a try, stop reading here and go do that now. For my solution and analysis, continue on.

Solution

There are lots of ways to approach this challenge. My first thought was to use findIndex, since the goal is to find the index of a number based on something. However, it's not as straightforward as it first seems. Take the example array [10, 9, 8, 7, 9, 10]. If we're to look at each value individually, as findIndex allows, we don't actually have enough information to deduce the break in the ordering. After all, it's not a number by itself (e.g., 9) that indicates a break in the ordering; it's the fact that a 9 came after a 7. So really, we're looking between the numbers, or at the pairs of numbers. We could still use findIndex and use its second argument, each index of the array, and work things out looking at the current number and one ahead, but then we also have to make sure the index is in bounds and it's just not as elegant as dealing with pairs.

To get the right pairs, we can make a helper function called zip. This is something I use a lot in Haskell and it's a shame that JavaScript doesn't have such a useful function in its standard library. But it's easy to make. The goal of zip is to take in two arrays and "zip" them together, making an array of pairs, where each pair has an element from the first array and an element from the second array. For example, if we zip [1, 2, 3, 4] and [7, 8, 9, 10], we should get [ [1, 7], [2, 8], [3, 9], [4, 10] ]. Disregarding special cases where the arrays are different sizes, we can make zip using map.

const zip = (xs, ys) => xs.map((_, i) => [ xs[i], ys[i] ])

Now, what do we want to zip together? Well, from the array [10, 9, 8, 7, 9, 10], it would be nice to have the consecutive numbers as pairs [ [10, 9], [9, 8], [8, 7], [7, 9], [9, 10] ]. Then we can just get the index of the pair where the numbers stop decreasing and we're done! So, the two arrays we need to zip are: [10, 9, 8, 7, 9] and [9, 8, 7, 9, 10]. The first array is the original, without the last element. The second array is the original, without the first element.

const arr = [10, 9, 8, 7, 9, 10]
const init = arr.slice(0, -1)
const tail = arr.slice(1)

All that's left is to find the index where the ordering is broken. Although, we still need to know how to code where "the ordering is broken". We can't just assume the array will start off increasing or decreasing. The first thing that comes to mind is a conditional based on the start of the array. If the first pair is increasing, then find the index where the pairs stop increasing, and repeat the logic for decreasing. We can put this all together and include the tests.

const zip = (xs, ys) => xs.map((_, i) => [ xs[i], ys[i] ])

const breakingTheOrder = arr => {
  const init = arr.slice(0, -1)
  const tail = arr.slice(1)
  const pairs = zip(init, tail)
  return pairs.findIndex(([x, y]) => {
    const [firstX, firstY] = pairs[0]
    return firstX < firstY
      ? !(x < y)
      : !(x > y)
  })
}

console.log(breakingTheOrder([10, 9, 8, 7, 9, 10]) === 3)
console.log(breakingTheOrder([1, 2, 4, 7, 2, 3, 1]) === 3)
console.log(breakingTheOrder([1, 2, 3, 4, 5]) === -1)
console.log(breakingTheOrder([10, 11, 12, 12, 13]) === 2)

Abstracting the Ordering

Something that came to my mind after coming up with the solution is that the change in ordering doesn't have to be thought of as a condition; it can be a value itself. This also comes from Haskell, which has an Ordering type whose values are LT, EQ, and GT. With this idea in mind, what we really care about is finding the first pair whose ordering value is different from the first pair's ordering value. All we need is a compare function that returns an ordering value given two numbers.

const compare = (x, y) => (
  x < y ? 'LT'
    : x > y ? 'GT'
    : 'EQ'
)

We can now use this function in the final solution.

const zip = (xs, ys) => xs.map((_, i) => [ xs[i], ys[i] ])

const compare = (x, y) => (
  x < y ? 'LT'
    : x > y ? 'GT'
    : 'EQ'
)

const breakingTheOrder = arr => {
  const init = arr.slice(0, -1)
  const tail = arr.slice(1)
  const pairs = zip(init, tail)
  return pairs.findIndex(([x, y]) => {
    const [firstX, firstY] = pairs[0]
    return compare(x, y) !== compare(firstX, firstY)
  })
}

console.log(breakingTheOrder([10, 9, 8, 7, 9, 10]) === 3)
console.log(breakingTheOrder([1, 2, 4, 7, 2, 3, 1]) === 3)
console.log(breakingTheOrder([1, 2, 3, 4, 5]) === -1)
console.log(breakingTheOrder([10, 11, 12, 12, 13]) === 2)

Imperative Solution

For fun, I wanted to try the same solution idea using a more old-school imperative programming style. So, instead of zip and findIndex, we can use a for loop.

The first time I wrote this imperative solution, I had a mistake in it. Can you spot it?

const breakingTheOrder = arr => {
  for (let i = 0; i < arr.length; i++) {
    if (compare(arr[i], arr[i+1]) !== compare(arr[0], arr[1])) {
      return i
    }
  }
  return -1
}

console.log(breakingTheOrder([10, 9, 8, 7, 9, 10]) === 3) // -> true
console.log(breakingTheOrder([1, 2, 4, 7, 2, 3, 1]) === 3) // -> true
console.log(breakingTheOrder([1, 2, 3, 4, 5]) === -1) // -> false
console.log(breakingTheOrder([10, 11, 12, 12, 13]) === 2) // -> true

The mistake is in the indexing. In the last iteration of the loop, arr[i+1] is out of bounds (thus undefined). To correct this, the loop should stop one index earlier.

const breakingTheOrder = arr => {
  for (let i = 0; i < arr.length - 1; i++) {
    if (compare(arr[i], arr[i+1]) !== compare(arr[0], arr[1])) {
      return i
    }
  }
  return -1
}

console.log(breakingTheOrder([1, 2, 3, 4, 5]) === -1) // -> true

But Tim, you could have made the same mistake in the functional code! True, let's see if it plays out differently. Let's say I made the mistake of using the entire array as the first one.

const breakingTheOrder = arr => {
  const init = arr // should be arr.slice(0, -1)
  const tail = arr.slice(1)
  const pairs = zip(init, tail)
  return pairs.findIndex(([x, y]) => {
    const [firstX, firstY] = pairs[0]
    return compare(x, y) !== compare(firstX, firstY)
  })
}

console.log(breakingTheOrder([1, 2, 3, 4, 5]) === -1) // -> false

Now that the code fails in the same way, how would I discover this mistake and debug it? Well, I could easily print out the list of pairs to see if it looks right.

const breakingTheOrder = arr => {
  const init = arr
  const tail = arr.slice(1)
  const pairs = zip(init, tail)
  console.log('pairs:', pairs)
  return pairs.findIndex(([x, y]) => {
    const [firstX, firstY] = pairs[0]
    return compare(x, y) !== compare(firstX, firstY)
  })
}

console.log(breakingTheOrder([1, 2, 3, 4, 5]) === -1) // -> false
// pairs: [ [ 1, 2 ], [ 2, 3 ], [ 3, 4 ], [ 4, 5 ], [ 5, undefined ] ]

From here, I can easily tell the last pair shouldn't be there, so the arrays need to be the same length to fix it.

In contrast, how would I debug the imperative code?

const breakingTheOrder = arr => {
  for (let i = 0; i < arr.length; i++) { // should be: i < arr.length - 1
    if (compare(arr[i], arr[i+1]) !== compare(arr[0], arr[1])) {
      return i
    }
  }
  return -1
}

console.log(breakingTheOrder([1, 2, 3, 4, 5]) === -1) // -> false

For me, this code is much more difficult to debug. It's hard to decide what to print first: i, arr[i], or arr[i+1]. And then I have to sift through the many lines in the console because the printing is inside a loop.

Now, you may be wondering why the imperative code is shorter than the functional code. Make no mistake, this is not inherent to the paradigm; I simply decided to use more variables in the functional code and wrote the imperative version idiomatically. Here is a more similar comparison:

const zip = (xs, ys) => xs.map((_, i) => [ xs[i], ys[i] ])

const compare = (x, y) => (
  x < y ? 'LT'
    : x > y ? 'GT'
    : 'EQ'
)

const breakingTheOrderFunctional = arr => (
  zip(arr.slice(0, -1), arr.slice(1))
    .findIndex(([x, y]) => compare(x, y) !== compare(arr[0], arr[1]))
)

const breakingTheOrderImperative = arr => {
  for (let i = 0; i < arr.length - 1; i++) {
    if (compare(arr[i], arr[i+1]) !== compare(arr[0], arr[1])) {
      return i
    }
  }
  return -1
}

Final Thoughts

I mentioned Haskell a few times, because it always comes to mind when I'm solving coding challenges like this. When I first learned Haskell and started practicing with challenges on Codewars, it felt really different from any other language I had used–in fact it often felt like cheating. Haskell's built-in library is so well-equipped that you really feel handicapped when you go back to other languages. And this has to do with the power of functional programming, which comes from abstracting patterns and recognizing these patterns in the wild. Once you harness that ability, solving problems becomes really easy. You get to know which functions and techniques come up a lot and how to recognize the situations to use them. Like the concept of zipping a list together with its shifted self (I never would have thought of it before using Haskell!).

With all this talk about Haskell, it's only fair to show the equivalent Haskell solution.

Haskell Solution

import Data.List (findIndex)
import Data.Maybe (fromMaybe)

breakingTheOrder :: [Int] -> Int
breakingTheOrder lst =
  fromMaybe (-1)
  $ findIndex ( \(x, y) -> compare x y /= compare (lst !! 0) (lst !! 1) )
  $ zip (init lst) (tail lst)

main :: IO ()
main = do
  print $ breakingTheOrder [10, 9, 8, 7, 9, 10] == 3
  print $ breakingTheOrder [1, 2, 4, 7, 2, 3, 1] == 3
  print $ breakingTheOrder [1, 2, 3, 4, 5] == -1
  print $ breakingTheOrder [10, 11, 12, 12, 13] == 2

However, if this were really a problem to solve in a Haskell mindset, the problem should be tweaked a bit. Instead of returning -1 in the case where the ordering doesn't break, we can use a Maybe type of value. So, return an index number where the ordering breaks, or nothing. This is naturally what Haskell's findIndex function is built around; maybe finding an index. The new solution is even simpler:

import Data.List (findIndex)

breakingTheOrder :: [Int] -> Maybe Int
breakingTheOrder lst =
  findIndex ( \(x, y) -> compare x y /= compare (lst !! 0) (lst !! 1) )
  $ zip (init lst) (tail lst)

main :: IO ()
main = do
  print $ breakingTheOrder [10, 9, 8, 7, 9, 10] == Just 3
  print $ breakingTheOrder [1, 2, 4, 7, 2, 3, 1] == Just 3
  print $ breakingTheOrder [1, 2, 3, 4, 5] == Nothing
  print $ breakingTheOrder [10, 11, 12, 12, 13] == Just 2

Originally published at https://timjohns.ca.

Imperative vs Declarative With Pumpkin Pie

SlimTim10 — Mon, 31 Oct 2022 01:30:37 +0000

The discussion of imperative vs declarative programming comes up a lot. The difference between the two paradigms can be confusing. I often see examples that present an unfair comparison or are plain wrong. It's time to set the record straight. The declarative paradigm is not about conveying less information; that's abstraction (more about that later). It's about conveying information in a different way.

Definitions

First, an introduction or reminder of what defines declarative and imperative clauses in plain English.

Declarative

Declarative clauses most commonly function as statements. The usual word order is: subject, then verb, then other elements. Declaratives can be affirmative or negative. They make statements about how things are and how they are not.¹

Examples:

I saw them last week.
Some courses begin in January.
The door was left open.
Those are not the only tickets left.
You could pass me the spoon.
I am happy.
x is equal to 5.

Imperative

Imperative clauses most commonly function as commands, instructions, or orders. They usually begin with a verb. We do not usually include the subject in an imperative clause.¹ In the context of programming, the implied subject is the computer running the code.

Examples:

Go see them!
Don't begin a course in january.
Don't leave the door open.
Get the last tickets.
Pass me the spoon.
Be happy.
Set x to 5.

Pumpkin Pie

Before we get to code comparisons, let's look at a plain English example using delicious pumpkin pie.

Ingredients

3 egg yolks
1 large egg
1/2 teaspoon salt
2 teaspoons ground cinnamon
1 teaspoon ground ginger
1/4 teaspoon ground nutmeg
1/4 teaspoon ground cloves
1 (15 ounce) can of pumpkin puree
1 (12 oz.) can of evaporated milk
1 frozen pie crust

Imperative Recipe

Preheat oven to 425 degrees F (220 degrees C).
Whisk together pumpkin puree, egg yolks, and egg in a large bowl. Add evaporated milk, cinnamon, ginger, cloves, nutmeg, and salt; whisk until thoroughly combined.
Fit pie crust in a 9-inch pie plate and crimp edges.
Pour filling into the pie shell and lightly tap on the work surface to release any air bubbles.
Bake in the preheated oven for 15 minutes.
Reduce heat to 350 degrees F (175 degrees C) and bake until just set in the middle, 30 to 40 more minutes. Allow to cool completely before serving.

Declarative Recipe

The base is the pumpkin puree, egg yolks, and egg whisked together in a large bowl.
The filling is evaporated milk, cinnamon, ginger, cloves, nutmeg, and salt whisked into the base until thoroughly combined.
The pie shell is the pie crust fit in a 9-inch pie plate with crimped edges.
The raw pie is the pie shell with the filling poured in and lightly tapped to release any air bubbles.
The semi-cooked pie is the raw pie baked in an oven preheated at 425 degrees F for 15 minutes.
The cooked pie is the semi-cooked pie baked at 350 degrees F for 30 to 40 minutes.
The cooked pie can be served after being allowed to cool completely.

What's the difference?

As you can see, the imperative recipe is a set of step-by-step instructions. They are intended to be followed in the written order. In contrast, the declarative recipe is a set of statements. They each simply state a fact about the pumpkin pie, or some part of it. The statements can be rearranged and read in any order.

Declarative Recipe (Rearranged)

The cooked pie can be served after being allowed to cool completely.

The raw pie is the pie shell with the filling poured in and lightly tapped to release any air bubbles.

The base is the pumpkin puree, egg yolks, and egg whisked together in a large bowl.

The pie shell is the pie crust fit in a 9-inch pie plate with crimped edges.

The cooked pie is the semi-cooked pie baked at 350 degrees F for 30 to 40 minutes.

The semi-cooked pie is the raw pie baked in an oven preheated at 425 degrees F for 15 minutes.

The filling is evaporated milk, cinnamon, ginger, cloves, nutmeg, and salt whisked into the base until thoroughly combined.

If you want to end up with a finished pie, you will end up reading every statement in the end because of how they depend on each other for information. These dependencies are the key to forcing some kind of order. In fact, you will end up doing the steps in the same order as the imperative recipe.

Something interesting to notice is that the declarative recipe does not force the baker to start by preheating the oven. It would still work to preheat the oven after making the raw pie, but we would miss out on the potential time savings by preheating the oven as the first step and multitasking. This is similar to optimizations that programming compilers do; things that programmers shouldn't need to worry about.

Programming comparison (JavaScript)

The difference between imperative and declarative programming is defined by the concept of state.² ^,³ Imperative programming involves the use of explicit state, which is information that gets remembered over time.⁴ Declarative programming is described as stateless. We can use recursion in (functional) declarative programming, which can be thought of as keeping implicit state, but since the context changes with each recursive call of a function there isn't an explicit state that is persisting over the entire operation.

Now let's compare imperative and declarative code. I'm choosing to use JavaScript because the language caters to both imperative and declarative ways of writing code.

Get even numbers, imperative

The goal is to get all the even numbers from a given list of numbers.

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

const even = x => x % 2 === 0;

let evensImperative = [];
for (const num of numbers) {
  if (even(num)) {
    evensImperative.push(num);
  }
}
console.log(evensImperative);

The explicit state is evensImperative, which changes its value over time, accumulating all the even numbers.

Get even numbers, declarative version 1

The same goal, using (functional) declarative programming.

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

const even = x => x % 2 === 0;

const getEvens = (xs, acc) => (
  (xs.length === 0) ? acc
    : even(xs[0]) ? getEvens(xs.slice(1), [...acc, xs[0]])
    : getEvens(xs.slice(1), acc)
);
const evensDeclarative = getEvens(numbers, []);
console.log(evensDeclarative);

I consider this version to be the most fair comparison. To accomplish the task, we define a function that uses recursion to build a new list of only even numbers from the given list. Any version which refines the code to use the help of other functions is using the principal of abstraction. It would not be more declarative, but rather more abstract.

Get even numbers, declarative version 2

Using reduce is a refinement on the previous version, a step up in abstraction. Reduce is a more specific, yet still quite expressive, function to transform an array into something new.

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

const even = x => x % 2 === 0;

const evensDeclarative = numbers.reduce((acc, x) => (
  even(x) ? [...acc, x] : acc
), []);
console.log(evensDeclarative);

Get even numbers, declarative version 3

For even more refinement, the most idiomatic functional solution to this problem is to use a filtering function, which is commonly provided in functional languages.

const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

const even = x => x % 2 === 0;

const evensDeclarative = numbers.filter(even);
console.log(evensDeclarative);

So which one is better?

One is not necessarily better than the other, but it's fun to think about how they are different depending on the context.

An important distinction is the difference in goals between recipes and programming. For cooking recipes, the goal is to give instructions to a human to follow. Imperative recipes are naturally easier because we need to perform step-by-step actions in the end. Trying to bake a pumpkin pie based on the declarative recipe would involve translating the statements into a sequence of steps, making us do extra work. However, in programming, the goal is not to tell the computer what steps to take to solve a problem. The goal is to write a solution to a problem and have the computer execute it, however it may. The fact that computers run imperatively at their lowest level doesn't matter because it is abstracted away by the compiler, so the solutions we write can be in any paradigm, imperative or declarative.

One difference when we write things in a declarative way is that it becomes easier to break the problem down, which is extremely helpful in both finding and verifying a solution. Looking at the declarative recipe, we can see each statement as its own small piece of the recipe. And each of those can be broken down further into smaller pieces if necessary. When each statement is very small, it's easy to look at it and see that it is correct, thus it becomes easy to verify that the entire solution is correct. At the same time, the dependency structure of the statements can be analyzed to verify that the entire solution makes sense and is not missing any pieces.

Another consequence of this breaking down of problems is the ability to reuse the pieces. An individual statement might be pulled apart from the solution as a whole and be reused to solve another problem. For example, the declarative pumpkin pie talks about the filling. Maybe we want to use a blueberry filling instead. If we have a similar declarative recipe for blueberry pie, we can simply swap in the blueberry pie's filling and leave the rest the same. Now we have a blueberry pie recipe! (This won't actually work for the given pumpkin pie recipe because it's too different from making blueberry pie, but I hope the point still stands.)

To make all of this more clear, imagine you're the pumpkin pie baker and you have 3 helpers. It's your job to assign each helper their own tasks so all your jobs are easier. With the imperative recipe, you would need to have a good idea of the all the steps before you can decide how to assign tasks to your helpers. You can't simply say to one, "It's your job to pour the filling into the pie shell" without also explaining when that needs to happen and what the filling is. With the declarative recipe, you can assign the task "Make the raw pie" to one helper, with the relevant statement "The raw pie is the pie shell with the filling poured in and lightly tapped to release any air bubbles." When the helper asks, "What is the filling?" you can simply direct them to the helper who has the task of making the filling. All of the statements can be assigned as tasks to whoever you want and the information will sort itself out.

What about abstraction?

Even though the declarative paradigm does not force abstraction⁵, it does seem to lend itself better to it. That's why so many other examples comparing imperative and declarative unfairly involve abstraction; it's hard to avoid it! And that's a good thing. Abstraction is what lets us focus on what's important and ignore the rest. I don't know about you, but I can only keep so much information in my head before feeling overwhelmed.

As an example, let's say you are already familiar with making pumpkin pies. In the declarative recipe, we can remove some statements that you don't need and leave only the ones you find hard to remember. This is harder to do with the imperative recipe where the dependencies aren't clear.

Declarative Recipe (Trimmed)

The pie shell is the pie crust fit in a 9-inch pie plate with crimped edges.

The raw pie is the pie shell with the filling poured in and lightly tapped to release any air bubbles.

The semi-cooked pie is the raw pie baked in an oven preheated at 425 degrees F for 15 minutes.

The cooked pie is the semi-cooked pie baked at 350 degrees F for 30 to 40 minutes.

Related to abstraction, the declarative recipe also lets us identify what's important. With the imperative recipe, it's hard to tell where things are headed. What's the point of whisking together the ingredients in a bowl? Are we making a soup at the same time? In the declarative recipe, it's clear that whisking together the ingredients makes a base, which is then used to make the filling.

In programming, abstraction is even more clear. Whenever we substitute a bunch of code for a function, we're replacing that code with an abstract blob that we don't need to look inside. In the even numbers example above, each subsequent declarative version is an abstraction on the previous one. This is easy to do in declarative programming because we can pick any statement and abstract it since we know what things depends on or not. Each statement is like its own bundle of stuff that can be put in a box and closed up. This is very useful and happens a lot in programming.

Correcting the misinformation

I said I've seen many examples that don't do a good job of showing the difference between imperative and declarative programming. Let's look at a few of them and where they went wrong.

Book: "Essential LINQ"

(Calvert, C., & Kulkarni, D. (2009). Essential LINQ. Addison-Wesley Professional)

Imperative programming requires developers to define step by step how code should be executed. To give directions in an imperative fashion, you say, “Go to 1st Street, turn left onto Main, drive two blocks, turn right onto Maple, and stop at the third house on the left.” The declarative version might sound something like this: “Drive to Sue’s house.” One says how to do something; the other says what needs to be done.

"Drive to Sue's house" is a command, so this example is clearly wrong. Not to mention the information provided in the two versions isn't the same. Sue isn't even mentioned in the imperative directions.

Imperative vs Declarative Programming, post by Tyler McGinnis

"Imperative programming is like how you do something, and declarative programming is more like what you do."

I don't find that definition helpful because "what you do" seems confusing or plain wrong. Declarative programming is something that people do, but that can't be what it means. Maybe it means "what you tell the computer to do", but that sounds like a command which makes it imperative. I don't know how to interpret this. I know this definition isn't meant to be taken seriously, but I think it makes things even less clear.

An imperative approach (HOW): "I see that table located under the Gone Fishin' sign is empty. My husband and I are going to walk over there and sit down."

A declarative approach (WHAT): "Table for two, please."

Is it just me or are these backwards? The first one is a couple of statements (declarative) and the second one is a command (imperative).

Sorry Tyler, I'm a fan of your work, but I think you got this concept wrong. To be honest, I think the only part of the post that is right is the collection of definitions at the end, which the rest of the post doesn't properly take into consideration.

Stack Overflow accepted answer to "Difference between declarative and imperative in React.js?"

https://stackoverflow.com/a/33656983

Imagine you have a butler, who is kind of a metaphor for a framework. And you would like to make dinner. In an imperative world, you would tell them step by step how to make dinner. You have to provide these instructions:
Go to the kitchen
Open fridge
Remove chicken from fridge
...
Bring food to the table
In a declarative world, you would simply describe what you want
I want dinner with chicken.

A more fair declarative version would be "I want chicken from the fridge which is in the kitchen, and I want to eat it at the table."

If your butler doesn't know how to make chicken, then you cannot operate in a declarative style.

This doesn't make sense. As we've seen, we can easily translate an imperative recipe to a collection of statements, which the butler can be told.

Footnotes

¹ Cambridge Dictionary

² Fahland, D., Lübke, D., Mendling, J., Reijers, H., Weber, B., Weidlich, M., & Zugal, S. (2009). Declarative versus Imperative Process Modeling Languages: The Issue of Understandability. Lecture Notes in Business Information Processing, 353–366.

³ Roy, P.V., Haridi, S.: Concepts, Techniques, and Models of Computer Programming. MIT Press, Cambridge (2004)

⁴ https://www.info.ucl.ac.be/~pvr/paradigms.html

⁵ As far as I can tell, this is true in general terms. However, in computing, declarative programming is an abstraction on low-level machine code which is imperative. But high-level imperative programming languages are far abstracted from machine code as well. So let's compare apples to apples and leave the low-level oranges to the machine… or something.

Originally published at https://timjohns.ca.

DEV Community: SlimTim10

TypeScript's Hidden Feature: Subtypes

What are subtypes?

✨ The code ✨

Subtype: Positive Number

Shorter Version

General Subtype Template

Why does this matter?

You can test subtypes!

More examples

NonNegativeInteger

NonEmptyArray

ValidWardrobe3

Validated Form Input

PositiveInteger, NonEmptyString

Footnotes

The Dangers of Learning to Code With Training Wheels

Footnotes

When to use currying in JavaScript

What is currying?

When is currying useful?

Conclusion

How to Learn Web Development On Your Own

Choose good material

Learn to google all the things

Build projects

Join communities

Be consistent

Look at code on GitHub

Use a mix of resources

Footnotes

5 Tips to Make the Most of a Coding Mentorship

Tip 1. Come up with project ideas

Tip 2. Ask lots of questions

Tip 3. Be honest about your time commitment

Tip 4. Put in the work to get a job

Tip 5. Make sure it's a good fit

6 Tips to Make the Most of a Coding Bootcamp

Tip 1. Do the prep work

Tip 2. Make connections

Tip 3. Don't fall behind

Tip 4. Practice communicating clearly

Tip 5. Be resourceful

Tip 6. Immerse yourself

Breaking the Order | Coding Challenge & Analysis 1

JavaScript Coding Challenge: Breaking the Order

Solution

Abstracting the Ordering

Imperative Solution

Final Thoughts

Haskell Solution

Imperative vs Declarative With Pumpkin Pie

Definitions

Declarative

Imperative

Pumpkin Pie

Ingredients

Imperative Recipe

Declarative Recipe

What's the difference?

Programming comparison (JavaScript)

Get even numbers, imperative

Get even numbers, declarative version 1

Get even numbers, declarative version 2

Get even numbers, declarative version 3

So which one is better?

What about abstraction?

Correcting the misinformation

Book: "Essential LINQ"

Imperative vs Declarative Programming, post by Tyler McGinnis

Stack Overflow accepted answer to "Difference between declarative and imperative in React.js?"

Footnotes

ValidWardrobe³