Literacy
I'm in training for two days this week (which is annoying, to an extent, because I have 2 days of work that needs done this week, and only one day in which to do it before going on vacation, which means I'm likely going to need to work on Friday, not that this has anything to do with anything). The training is focused on applying "Lean" principles to data analysis. "Lean" is a buzzword laden approach to evaluating and improving the efficiency of a process. Stripped of buzzwords, it's not a bad set of techniques. Nor is it gospel, contrary to some of the enthusiasm of its pointy-haired proponents.
Regardless, I'm looking for the good parts of the training. One of the key focuses has been on value stream maps. Essentially this is a flow-chart used to understand who does what in which sequence to generate output. In a factory analysis, you'd use it to analyze the manufacturing process so that you could identify waste.
The key thing to note about them is that they focus on inputs and outputs. There are some raw materials at the start, which are the initial step to the first process, which does something to the raw materials. This process hands its output to the next step, which does its own thing generating yet another output. And so on, until eventually, you get the finished good. Along the way, you want some metadata about each step, like its costs and the value it adds to the final product.
I'm sitting there in class, and thinking: wait, inputs, outputs, and chains of processes? This is functional programming.
So I started taking notes, but not in English. I start scribbling away in Haskell, prototyping some functional programming ideas that relate to the problems represented by a Value Stream Map. I'm till not too experienced with Haskell, so it's a little cumbersome, but there's a distinct value, to me, in being able to explain ideas in code.
But then, I remember: Haskell is a literate language.
In most languages, you write code and annotate it with natural-language comments to explain what that code does. In most cases, this means that you have to mark your comments with some special character, for example, in C, you'd write something like this:
/*
Take two numbers and add them
*/
int MyFunc(int a, int b) { return a + b; }
The comment is on the line that starts with "/*" and ends when it hits the "*/".
Haskell, by default, takes a similar approach (one line comments start with "--", and multi-line comments are enclosed in "{-" and "-}". But you can tell it, "Hey, be literate." Instead of requiring you to mark your comments, you instead need to mark your code. A literate Haskell program would look something like this:
Take two numbers and add them
> MyFunc a b = a + b
When you're trying to take notes and then illustrate them with code, or when you're writing code in an experimental fashion, this becomes a really good way to sketch out your ideas.
I'm still not blown away by Haskell's dependency on whitespace, but it's got a lot of other features that make it really good for rapid prototyping of logic. I still don't grok "monads", which means non-functional problems (like IO or random numbers) are still a challenge for me, but it's still a really fascinating language. As parallelism gets more important in software design, so will languages like Haskell.
Regardless, I'm looking for the good parts of the training. One of the key focuses has been on value stream maps. Essentially this is a flow-chart used to understand who does what in which sequence to generate output. In a factory analysis, you'd use it to analyze the manufacturing process so that you could identify waste.
The key thing to note about them is that they focus on inputs and outputs. There are some raw materials at the start, which are the initial step to the first process, which does something to the raw materials. This process hands its output to the next step, which does its own thing generating yet another output. And so on, until eventually, you get the finished good. Along the way, you want some metadata about each step, like its costs and the value it adds to the final product.
I'm sitting there in class, and thinking: wait, inputs, outputs, and chains of processes? This is functional programming.
So I started taking notes, but not in English. I start scribbling away in Haskell, prototyping some functional programming ideas that relate to the problems represented by a Value Stream Map. I'm till not too experienced with Haskell, so it's a little cumbersome, but there's a distinct value, to me, in being able to explain ideas in code.
But then, I remember: Haskell is a literate language.
In most languages, you write code and annotate it with natural-language comments to explain what that code does. In most cases, this means that you have to mark your comments with some special character, for example, in C, you'd write something like this:
/*
Take two numbers and add them
*/
int MyFunc(int a, int b) { return a + b; }
The comment is on the line that starts with "/*" and ends when it hits the "*/".
Haskell, by default, takes a similar approach (one line comments start with "--", and multi-line comments are enclosed in "{-" and "-}". But you can tell it, "Hey, be literate." Instead of requiring you to mark your comments, you instead need to mark your code. A literate Haskell program would look something like this:
Take two numbers and add them
> MyFunc a b = a + b
When you're trying to take notes and then illustrate them with code, or when you're writing code in an experimental fashion, this becomes a really good way to sketch out your ideas.
I'm still not blown away by Haskell's dependency on whitespace, but it's got a lot of other features that make it really good for rapid prototyping of logic. I still don't grok "monads", which means non-functional problems (like IO or random numbers) are still a challenge for me, but it's still a really fascinating language. As parallelism gets more important in software design, so will languages like Haskell.