Universal Primitivism

Prelude: Creating The Logic Engine

2012-08-24T14:55:00.001-07:00

Gathering the Resources

Despite the complete absence of Logic in modern Socio-Political rhetoric, there are no shortages of resources about the Categorical Syllogisms on which the Logic Engine is to be based. This is not due to any particular quality of greatness in our current world-society at all. This is entirely the legacy of the better men and women of the classical, renaissance, and enlightenment eras who toiled tirelessly to ensure that the resources for this critical tool be available for all generations to come.

The feckless university systems of this world have almost completely eliminated it from nearly all courses of study and thus condensed it to one specific type of 'humanities' class which is entirely optional and which glosses over the subject of logic to make room for the impossibly mammoth amount of corollary subjects and personalities which must be covered in order to justify a course named "Introduction to Philosophy and Ethics".

Here's a list of resources which you can use to educate yourself on the forum for logical debate known as the Syllogism or (more specifically) the Categorical Proposition:

The last one is a list of all of the 256 possible combinations of Categorical syllogism. Once you learn how to read that last page, you can merely 'plug-in' the form of any argument and determine whether-or-not a syllogistic argument is invalid. This is important, because an Invalid argument can never be True; it can only ever be 'undetermined' at best.

If an arguer cannot phrase his argument in a Valid form, the argument is worthless as far as decision-making is concerned. This is what the Logic-Engine is all about. Here's an example, if you are going to send a county to war and kill hundreds of thousands of people in the process, you must make that decision based upon an argument which is, at the very least, valid in form. The argument may turn out to be False. However that is not the fault of the arguer per se, rather, that is the fault of the premises used to make the argument. In the world of decision making, the entity or process which determines the truth-value of a premise is completely separate from the entity which makes the decision. This is incontrovertibly True in the world of Executive Government. The President does not go into Iran personally and collect intel about Iran's theoretical quest to declare a nuclear war on America. In fact, the President will likely never even meet any of the people who did.

The executor must trust the efforts of the information gatherers she uses first, then trust the sources the information-gatherers cite indirectly. This can never occur in any other fashion lest the gatherer and source be one in the same person; in this case organizational association through the likes of research institutes and corporations are completely irrelevant due to distortions in interpretation and observer-bias which is introduced, willingly or not, by each agent in turn -- remember the telephone game?

Once you separate the scientific process of premise-proving from the Syllogistic process of decision-making, you are halfway to the point of creating an entirely new form of human governance: the reign of the categorical syllogism. This is because one can take any form of argument and evaluate it using the categorical syllogism. We can trust the categorical syllogism because it is one of the founding structures used to create of all modern mathematics. Every modern structure, tool, or organization has been influenced or completely sired by mathematics and the scientific method. If you refute the consistency of the categorical syllogism, you might as well refute all science. Give-up the computer you are reading this on, the phone, camera, television, gaming set, car, watch, air-conditioning unit, building-you-live-in, justice system which protects you, and government whose freedoms you enjoy. If you don't trust the categorical syllogism you can't explain the presence of any (and much much more) of these things in your life; because they were all founded upon it.

Simply put: the categorical syllogism and it's children: mathematics, philosophy and science are the foundation of civilization as we know it. To reject it is to return to the bronze-age.

The task before us is simply to take the tools before us and formalize them into a public forum and private decision-making system which will be understandable to all members of society and with which we can build a new more logical form of governance.

The way I will contribute to this is to create a computer program which allows us to feed arguments into it and make determinations of validity or invalidity.

I would also like to create a public forum and invite pundits to participate. We can then use logic to determine the course of human activity.

In short, if we had used the Logic Engine when Bush Jr. was proposing a war in Iraq, hundreds of thousands of lives would have been saved. The Logic Engine is no mere curiosity of classical pre-science, it is the structure around which most or all of the world's greatest problems can be solved. However, the rule of might will forever dominate human affairs: The strongest entities will make the rules and write the histories. It is thus our charge to ensure that the strongest entities use the categorical syllogism as the basis for decision-making. It is thus our charge to ensure that the majority of human-beings use it.

Our work is cut-out for us and will not be completed in any living-persons lifetime. However, by merely pooling our resources and popularizing our efforts, we can and will succeed. The power of the syllogism is readily-apparent to all thinking-persons who use it. For now, we need only concern-ourselves with demonstrating that power for the world to see.

Look for my breakdown of the Logic-Engine in the posts to come.

Haskell Chapter 2

2012-08-17T18:20:00.000-07:00

Program Flow

Once you have learned how to create functions and manipulate standard IO in a programming language, you quickly begin to run-in to situations where you need your module to make decisions. Around this time you also discover the need to save large amounts of data and then cycle through that data one-at-a-time in order to pick-out items on which you must perform some sort of work. This really has nothing to do with computer programming per se, this is just how the civilized human world works. At the end of the day, a computer program is just a way to mechanically perform human activities. The need for artificial intelligence arises from the need to perform human activities. Human activities are long, complex, and usually involve large amounts of data (whether computerized or not). Just imagine the huge amount of data and diagnostic metrics which would be required to maintain a healthy large farm or a prosperous township during the bronze-age. If all we ever did was hunt and gather, there would be no need for computers. Indeed, computers (in the form of counting machines like the abacus) started popping-up around the same time as organized agriculture and thus civilization itself.

All counting machines and computers (whether primitive or advanced) utilize the concept of leverage in order to perform their feats of prodigy. The idea is that a symbol (like a bead in the tenths-position on an abacus) can represent a whole-other set of ideas and values. Then by merely manipulating the list of symbols, you can manipulate all of the other values and thus perform calculations which would be daunting or impossible to primitive man and woman-kind (more daunting for man-kind). This is called symbolic leveraging and it's the foundation of civilization as we know it.

The programming paradigm that represents this is sometimes called program-flow or workflow. The tools we use to control the flow of work being performed in Haskell are: conditional statements, lists and list operations, recursion, counters, and list comprehensions. Ultimately, the mentality behind these sorts of programs can be boiled-down to this: Test every element of a list for some arbitrary condition. If the condition is True, perform a function on the element. If not, move on to the next element.

If we begin by examining conditional-statements, we can illustrate the process with a minimum amount of prerequisite knowledge and give you real-world skills which you can use to create all sorts of useful modules. Yes, conditional statements are based on boolean operations. However, most high-school graduates already know everything they need to know about booleans in order to create expert conditional statements. There's no point beating you over the head with abstruse knowledge which you will not be using anytime soon. Most of what you need to know about bools will be instantly apparent upon viewing the code.

Conditional statements lead directly to counting. Conditional statements are the fun and easy part of programming in Haskell. However, you will eventually find yourself needing to count the amount of items in a list which meet a specific boolean condition, or to look for an item in a specific index of a list (which also requires counting and a subsequent condition-test). The act of counting is where Haskell starts to get advanced. This is because Haskell does not have a feature which other programming languages have built empires upon: mutable-state variables. This is not a shortcoming either. The designers created Haskell that way on purpose. You're probably thinking: Wait, go back a sentence. What the hell is a mutable-state variable? Here's the long and the short of mutable-state variables:

When you write-down a number or value on a notepad, you can go back and erase it or add to it or subtract from it; whatever you want. Once you lift your pencil from the page, the data is saved exactly as you left it. Haskell doesn't allow this. When you give a variable some value in Haskell, Haskell takes that value and locks it away in a safe-deposit box. If you try to modify the value in any way, Haskell will force you to save the new value to yet another deposit box or risk losing it forever. In short, the original value can never be changed or mutated. The only thing you can do to it is to delete it and start over again. This is true for every data-type in Haskell. You can only ever do three things to a variable in Haskell:

Create a new variable (Num, Char, List, etc.).
Read the value of a variable you already created.
Destroy a variable you previously created.

This makes counting extremely challenging. However, once you master counting in Haskell, you will have officially become a Functional Programmer. If I could send you a badge for that accomplishment, I would because it is mind-expanding and will probably change the way you think about computer programs. But right now I can't afford it. Anyways, don't worry too much about that. Counting Happens in the next Chapter . For now we get to concentrate on something far less challenging yet still pretty rewarding. Conditional Statements.

Conditional Statements

Bools are the main unit of conditional statements. As mentioned before, they are also the main unit of formal logic; which is a system of making decisions based on truth values. Haskell has a very rich feature-set to deal with truth values; and they come in the form of conditional statements known as 'guards'. So, in this text, conditional statements will be your intro into logic. Anyways, conditional statements are where things start to get really interesting in Computer Science. They allow you to begin designing artificial intelligence modules, instead of mere calculators.

Many of the functions you write in Haskell won't ever use Bools like True and False directly. Instead, they use conditional statements. Haskell will check whether a condition is True or False for you, without you even needing to see the words 'True' and 'False'. This is immensely convenient and makes your code both easier to read and write. In the 'Bools' section of the appendix, we will show you how to manipulate Bools discretely using logic statements like not-and and not-or etc. But for now, we will focus on how to create conditional statements because they are easier to understand, more powerful to use, and more fun to write than Bools.

There are different ways to create a conditional statement in Haskell. You can use 'if-then statements' like this: 'if x is higher than 100 then putStrLn ("Too high!") else function x.' However, 'if-then' statements are rather rigid and require special indentations and other syntax. It is much easier to create conditional statements using Haskell's dedicated tool for logic: 'Guards'.

Guards look a little funny, but they are really quite easy to understand. A guard in plain-English could be written like this :

'If this condition is True (list condition here), then do this: (insert activity here).'

In Haskell's guard syntax, we would write the above line like this:

| x = y = function x

| otherwise = x

Notice that there is the traditional 2-space indent. That's because guards are only-ever used inside of function definitions. Also, you will notice that the second line says 'otherwise'. This means that, if x is NOT equal to y, return x unchanged. 'otherwise' is required to compile the function. After all, Haskell needs to know what to do when the first-line is NOT True. Haskell calls this an 'exhaustive pattern'. An 'exhaustive pattern' is one which covers or exhausts all of the possibilities in a conditional statement. As a general rule of thumb, conditional statements need at least two lines: one line to cover what to do when the condition is met, and one line to cover what should be done otherwise.

' | ' is the same as 'If the following condition is True...'
'x = y' is the same as ' the condition is 'x = y'. Of course, you can make any logically-consistent condition you want.
'=' means 'then do the following...'
'function x' is the activity you would like to have done. It doesn't have to be a function. However, any activity which requires a definition or statement of equality must be defined separately. As a result, the activity in question usually ends-up being a function of some sort.

There is one final ingredient to a guard, and that's called a 'where cluase'. A 'where clause' is not strictly necessary. However, it is necessary when the activity you wish-to-be done is so complicated that it needs further definition in its own right.

Consider the following scenario:

Imagine you purchased a new HDTV which you connect to the PC in your dorm-room. The sound it produces is wonderfully lush and dynamic in an almost 3-dimensional way. However, it tends to go from a whisper to a cacophony without warning; anytime there is an action scene. Your neighbor is ready to call the cops on you over the noise it creates. The problem is that whenever you turn it down for an action scene, you can't hear the dialogue during the normal scenes! Arggg! What to do? The bass-player in your band explains that you should create a 'software limiter' for your PC which will turn the volume down automatically, whenever the levels go above -5 dbv. That way, the dialogue will be louder and the action will be quiter.

This is a perfect job for a guard. All you need to do is setup a function which tests the input level. If the input level is greater than -5, the function will return an output of -5. If the function is less than -5, the output level will remain the same. We'll call that volume-level 'x'.This is such a simple function that you shouldn't even need a where clause. Here's what it would look like in Haskell.

limiter x

| x > -5 = -5

| otherwise = x

Notice that the first line does not have an equals-sign ('='). For some reason, functions that use guards don't use equals-signs before the definition. I suppose the Haskell folks just decided that guards have enough equals-signs in them as it is. This can be a little strange at first. It's another one of those Haskell idiosyncrasies you need to get used to.

Because Haskell is designed to emulate formal mathematical notation, we must always be aware of order-of-operations. This means we need to be aware of when and when not to use parens. 'limiter x' is designed to use negative numbers. However, if we input a negative number into Haskell WITHOUT parens, Haskell thinks you want it to perform a subtraction operation on x while simultaneously inserting x into the function 'limiter'. This creates a conflict in the order-of-operations. You can resolve this the same way you did in your high-school algebra class: put the negative-number inside parens, like this:

'Prelude> limiter (-7)'

In other words, 'If in doubt, use parens!'

Now, let's say you've used your limiter module for a few weeks now and you are starting to become dissatisfied with the results. There seems to be no urgency or suspense in the audio; and this is one of the things that made you choose that model of HDTV in the first place! Once the volume hits -5, it sort of falls flat. Once again, the bass-player comes to the rescue. He immediately diagnoses the problem and suggests that the solution here is to make a compressor instead of a limiter. An audio compressor takes every output and modifies it according to some middle-value. That is, it takes the quiet parts and makes them all louder, yet simultaneously takes the loud parts and makes them all quieter. In a way, it compresses the dynamics into a smaller-range while still preserving the roller coaster-like ups and downs which make a movie soundtrack so exciting.

To do this, we use guards in conjunction with 'where-clauses' as well as the Float data-type. The guards will be setup around an adjustable middle volume which we will call 'center'. When you run the program yourself, try inputting a center value of (-5). I also hate variable-names like 'x' because they tell us nothing about what value x is supposed to be. It only takes a second to find and apply a more descriptive name than 'x'. In this case, I will call the input value 'volumeLevel' because that is what we are modifying with this module; the volume level.Then we will use the 'where-clauses' to define mini-functions which raise and lower the input volume by some percentage. Since we are using a percentage to modify the volume, we need to output 'volumeLevel' in the form of a Float; which is the only way to achieve an accurate output value. Here's what our compressor looks like:

compressor volumeLevel center

| volumeLevel > center = cut volumeLevel

| volumeLevel < center = boost volumeLevel

where

boost volumeLevel = volumeLevel - (volumeLevel * 0.25)

cut volumeLevel = volumeLevel + (volumeLevel * 0.25)

Notice that 'where' lines up exactly with the guard-symbol (' | '). This is crucial syntax if you want your module to compile properly. Also, notice that there is no equals-sign after where. However, the following lines are indented two-spaces in from 'where'. Again, the two-space indent is a common pattern you will see in Haskell syntax. Make sure you check your first several functions to see that they maintain this unique spacing. If you haven't already, take a minute to try-out both functions on your own.

The next section will consist of exercises which concentrate on using guards to modify the previous modules you created in the last section. Once you master guards, you will have all of the required skills to start writing programs which are both fun and useful. Of course, some of you may not remember much about Bools. We'll review Boolean operations and offer a complete treatment of classical logic in the appendix at a later date. Simple Boolean operations like and (&&) and or (||) will be covered whenever it applies to an exercise. They are so simple to use, that they don't warrant a dedicated section for most students. What matters is that you get a good grasp of conditional statements and functions. After that, the bulk of the hard-stuff will be behind-you!

Haskell 1.2.4

2012-08-16T21:58:00.000-07:00

Basic IO Exercises

Before we start on the exercises, I'll quickly recap the workflow concerning the two applications we use to write Haskell modules: the text-editor and ghci. All of the exercises below should be written-out in your text-editor first. Use the comment operator '--' at the beginning of lines containing notes to yourself on what each part of the program does. Ghci will automatically skip over commented notes. Make sure to start your code in the upper-leftmost corner of the text-editor to eliminate the possibility of weird compile-time errors. When you are ready to save the file, save it within your 'haskellPrograms' folder under a name that has no spaces, punctuation-marks, or other uncommon characters. For the interest of consistency, I urge you to use the Haskell naming-convention; something like this: 'exerciseChp1.hs'. Remember that '.hs' is the required suffix, and 'haskellPrograms' is the required folder.

Now navigate to 'haskellPrograms' within your terminal application. Once there, type 'ghci' in the terminal. Now you are ready to load your programs! Remember, to load a program you type ':l programName' into ghci.

Exercise 1.1

This is a basic exercise to help you get a feel for how to use 'putStrLn'. Create a short IO script using the 10 IO Rules of Haskell which apply. First, create a script that takes a number from the user, multiplies it by two, and prints the results onscreen. The idea with this first script is to collect a number from the user into a variable, use that variable as an argument in a separate arithmetic function, pipe the output of the arithmetic function back into a variable within main, and finish by printing the last variable along with some message like 'Two times the number you entered is:' followed by the correct answer. The main tools you need will be:

*
<-
let
putStrLn
++
Parens and Double-Quotes

You will need to use every rule here except rule #8. If you don't remember, go back and carefully read the special rules for using 'let','read', '++', and 'putStrLn' which are listed and highlighted in Chapter 1.2.

Exercise 1.2

Now modify the successful script you created for the last exercise. Try using the arithmetic function as an argument for putStrLn. Now read the compiler-errors. Can you see how the compiler-error messages reflect which specific rule have been broken? Modify the arithmetic function so that it uses 'read' in the argument. Check the error-messages for clues to what is happening. Although the error-messages are difficult to understand, they do give you hints when things go wrong.

Exercise 1.3

In this exercise, you must create a simple program which asks for the user's first and last name separately, then displays a message welcoming them to Haskell by their full-name. You must then load the program module (module for short) into ghci and run it. Shown below is the logical breakdown of each step within the program. For starters, it's always good to create a vision of how you think the program should ideally function, despite the fact that you may not know how to accomplish it.

Here's how I imagine the program to work. Notice the term 'main>'. This is the ghci 'prompt' which (as you might expect) prompts the user to action. As such, it is not part of our program's design. Likewise, the red-colored text represents data typed by the user, and is also not part of the code we expect to write.

main>Please enter your first name below:

Ryan

main>Now enter your last name below:

Johnson

main>Haskell officially welcomes Ryan Johnson to the world of code!

To accomplish this simple program you will need to do four things:

Create a 'main=do' function since this is an IO program.
Create two separate functions which display a unique message and retrieve the first and last names of the user.
Combine the first and last name into one unit, as shown above, which features correct spacing*.
Display a greeting which 'pastes' the first and last name of the user into the middle of a pre-written phrase, thus creating a customized greeting message.

To do this you will need these operators, covered in section 1.2:

putStrLn
getLine
<-
++
Parens and Double-Quotes

You must carefully apply these rules of Haskell IO:

Rule #1
Rule #2
Rule #3
Rule #4
Rule #6
Rule #7

Ok, now start writing and trying out your creations. You will know you have succeeded when you get the same results as those listed in our creative vision above.

*HINT: Did you know that a space is also a Character in Haskell? You can even make a String of spaces using double-quotations like this: " ".

Haskell Chapter 1.2.3

2012-08-15T16:18:00.000-07:00

Your first assignment pt2: Program your Wizard

Warning: This may turn out to be the hardest chapter in the entire online book! It's filled with rules upon rules; which nobody likes to read. However, once you are through with Chapter 1, you will have a strong working-knowledge of practical Haskell. Stick with it and I'll keep looking for better ways to rewrite the following article!

One if the best things about functional programming is that it forces you to separate your code into logical chunks. This is great because you can look at the code and immediately tell what each chunk does. It's also frustrating because Haskell enforces this mentality rather strictly; you must undergo a few disheartening failures before you get to experience success. Here's the code I used for this simple little wizard:

main = do

age <- askUser

prediction age

askUser = do

putStrLn "Tell me your age and I'll magically predict your mother's age: "

getLine

addToAge x = read x + 25

prediction z = do

putStrLn "Your mom's current age is: "

print $ addToAge z

If you come from a dynamic programming background, you will already see that it takes a LOT more code to implement this program in Haskell than it does in a good dynamic language; Haskell isn't always more elegant.

What you see above are four discreet functions. The overall program is referred to in Haskell as a module. So, here we have four functions which work together to create one module.

The first function is the 'main = do' module. This is the spine. Notice how each line after 'do' is indented. Also notice that each of the four functions are composed mostly of IO actions like 'putStrLn'. The indentation is very important in 'do' functions. Make sure you always check it before you try to compile your finished program.

So, logically you can break this whole 'momsAge' module down into two core activities:

Ask your classmate how old she is and write that number down.
Enter your classmate's age into a function and speak the results to her.

Likewise, 'main' is broken into two functions that reflect this: 'age <- askUser' takes care of activity number one. 'prediction age' takes care of activity number two.

If you look closely at both activities above, you will see they each consist of two more separate sub-activities. So, following these two logical core activites as they break down into two more subserviant activities we can directly construct the code above. Of course, it's not that easy. Haskell has all those rules we talked about earlier. Here's the break down of the 'momsAge' code using each of the 10 IO Rules of Haskell that apply; starting with the 'main=do' chunk:

main = do

age <- askUser

prediction age

Rule #1: Gotta have a 'main=do' function.

Rule #2: Make sure you indent each line in the function's definition by exactly two spaces.

Rule #3: Separate your input function from 'main'. For now, we can call the input function: 'askUser' because it asks the user for her age.

Rule #4: Bind the output of 'askUser' to a variable within 'main' -- in this case we call the variable 'age' because terse variable names like 'x' are practically useless. Otherwise, Haskell will not save the results of 'askUser'; and you won't be able to use it for our second 'core activity'.

Rule #7: The last line of a 'main=do' function needs to return some kind of value. The 'prediction' function prints out the results along with a message to the user. This qualifies as a 'return value'.

Whew! See what I mean about rules on top of rules! All of the rules above and reasoning we made earlier about the logical structure of the program come together to make this little function.

If you have read the other non-CS sections of this blog, you'll know that this is a prime example of symbolic leveraging gone wrong. Anyways, we're still not done. We need to define 'askUser' and 'prediction'; right now they're just meaningless placeholders. We'll start with 'askUser' because it's first in the logical order. Here's the rules that govern 'askUser':

askUser = do

putStrLn "Tell me your age and I'll magically predict your mother's age: "

getLine

Rule #2: Make sure you indent each line by exactly two spaces.

Rule #3: Separate your input function from 'main'. We can call the overall input function: 'askUser' because it asks the user for her age. However, the input 'action' which retrieves the user-data is 'getLine'.

Rule #6: 'askUser' has an IO action inside of it. In fact, it is basically nothing-but IO actions. That means we need to employ the magic 'do' word.

Rule #7: The last line of a 'do' function needs to return some kind of value. 'getLine' takes the user's keyboard input and immediately returns it to whoever invoked it (in this case 'askUser'). If you run 'askUser' from a ghci interactive session (whose parent function is 'std IO'), it will return the output value on screen (which is also 'std IO'). Likewise, if you run 'askUser' from inside of another function, it will return the output value to that other function (in this case 'main=do'). This is why Rule #4 works!

And now the rules that govern the next chunk of code called 'addToAge':

addToAge x = read x + 25

Rule #5: 'addToAge' has no IO actions. 'read' sure seems like an IO action, but Haskell doesn't require 'do' notation for read. Since 'read' is not an IO action, we must follow rule number five and separate the whole operation off to it's own function. This is nice, if the median age of new motherhood increases, or if we want to give the result as a range instead of one answer (which is bound to be wrong) all we have to do is change 'addToAge'. The rest of the 'momsAge' module remains intact and bug free! This is what functional programming is all about!

Rule #9: We know that 'addToAge' is going to receive a variable which has been bound to the output of 'askUser'. We also know that 'askUser' uses 'getLine' which only delivers strings for outputs; regardless of what kind of input you give it. Since Haskell is statically-typed, we know that it will refuse to perform arithmetic operations on strings -- even if they look like numbers to you and me. What we need then is some way to convert our variable (age) into a number long enough to perform arithmetic on it.

Rule #10: 'read' is a way to convert a string to a number and back again. It doesn't work for a string of letters like 'bananas', but it works great for a string of numbers like '20'. So, using rule #9, we anticipated that 'age' would be a string. Now we apply 'read' to age, and continue to operate on it using arithmetic. The output of 'addToAge' will still be a string, but 'read' allows us to calculate it as if it were a number.

And finally (make it stop please!), the rules that govern 'prediction':

prediction z = do

putStrLn "Your mom's current age is: "

print $ addToAge z

Rule #2: Make sure you indent each line by exactly two spaces.
Rule #6: 'putStrLn' is an IO action, so it means that 'prediction' requires 'do' notation.

Rule #7: We need to finish with an output function. The logical choice is to finish with 'addToAge' because we know it outputs a concrete value (x + 25).

Rule #8: We also need a way to print the output of 'addToAge'. We know 'addToAge' is not a 'do' function; and thus it has no IO capabilities of it's own. However, 'print $' gives us a tool to print the output of any function onscreen AND it satisfies rule #7 at the same time!

Wrapping it all up: Save, Compile and Load your Module

Whew! All done! Now all we need to do is save the code to a '.hs' file and load it into ghci. Here's how:

Copy the text above to a good text-editor (I use KATE). Make sure that there are no empty lines or spaces before 'main=do'; remember Haskell is very sensitive to spacing and indents.

Next, save the file as 'momsAge.hs' within the haskellPrograms folder we created earlier. Open a terminal, navigate to /haskellPrograms and type 'ghci'. When you see the 'Prelude>' prompt, type:

':l momsAge'

As long as there are no weird empty lines or spacing issues, the program will compile and you will be greeted with this prompt:

*Main>

This means that ghci has loaded-up 'momsAge'. 'Main>' is sort of a generic-prompt which Haskell uses for user-created functions. To run your module, you need to 'call' the main=do function by typing 'main' (lowercase m). Of course, you can call other functions in 'momsAge' too (if you feel like testing them out) by simply typing the name of the function and pressing enter. From there, it's pretty self-explanatory.

Prologue

Wow, that was a helluva lot of rules to remember. I agree. Way too many in fact. But, once you master this section, we can go on and practice writing programs instead of spending the entire book ONLY talking about theory (like in Learn You a Haskell and Haskell:TCoFP 1st Ed). Its a pain and you will probably need to re-read this section several times. However, there really is no other way to do this. This leads to the last rule (for now), but don't worry; it's easy to remember:

The Golden Rule of Coding: The only way to learn how to code is to code, code, code!

In the next section we will concentrate only on practical IO excercises until (hopefully) it becomes natural for you. In section 1.3 we will introduce Bools briefly, and then finish with some more exercises. All that theory and verbose explanation is great -- to a point. But you need to practice until your fingers 'just know what to do' without even thinking about rules.

Haskell Chapter 1.2.2

2012-08-14T22:19:00.000-07:00

Your first assignment pt1: Create a Wizard

When you install a piece of software for the first time, it will proceed to ask you some basic questions about you so that it can set the software up correctly. As you probably already know, that sequence of questions is called a wizard.

Wizards are an excellent example of precisely what it is that software really does. A wizard asks you for information, takes that information and processes it. Then, the wizard spits out a result. All the while, the inner-workings of the wizard are invisible to the user. Anyone can use a wizard because a wizard uses natural language; in our case English. This allows the programmer to create algorithms of infinite complexity which are, all the while, still accessible to anyone with basic communications skills and perhaps some arithmetic. This is what all software should ideally be: an intuitive user interface that gathers data, invisibly executes it with unfettered complexity, and returns the data in terms that the user can understand without knowing how the program works.

This is not so easy to do in Haskell; a weakness if ever there was one. Still, Haskell can do so many other things, so well and with so little effort, that we just have to bite the bullet here!

The perfect analogy for the wizard is the algebraic function. If you don't remember this, or never learned it, you need to stop here and seek out a good introductory Algebra textbook. In several years from now I may have one written for you (eh just go check one out from the library)!

OK, now that you're back, let's continue with the algebraic function. A function is the first program anyone learns how to write. Long before learning to code, we learn to write functions and they work like 50% of the wizard which we are attempting to write. In this section, we will create a function along with a set of instructions and save them as a '.hs' file. We call this file a 'script' because it contains not only functions, but a general order in which the functions are-to-be performed. Whereas a module can be a very short '.hs' file consisting of only one line, a script is a collection of functions and instructions; a collection of multiple-lines of code. Here's the real-world scenario which we want to model as a mathematical function:

Start by finding a classmate who is either an only child or a firstborn child.
Ask the user (your classmate) how old she is. For demonstration purposes, we'll say that she says 20 and you write that down in your notes.
Let x = your classmate's age. Now, let x = 20.
Next, you tell her that you will guess her mom's age within +/- 5 years.
In america, the average new mother is about 25 years old. So, we can extrapolate that your classmate's mother was probably close to that age when she gave birth. On your notepad, add the classmate's age (x) plus 25.
Finally, perform the calculation (x + 25) and speak the results to your classmate: "Your mother is most likely 45 plus or minus 5 years"

There's a pretty good chance you'll be right. Maybe not. The point is, you just made a function which (if you remember algebra class) can be written like this:

function(x) = x + 25

The anatomy of a function can be divided into five parts:

First we have the name of the function: 'function' -- a rather boring name.
Second we have the input of the function: '(x)'
Next we have the declaration of equality, which signals the end of the arguments section: '='
Then we have the definition, which explains how the function works: 'x + 25' -- this can consist of nearly an infinite number of lines.
Lastly we have the return value. It is not usually listed in the function itself, but rather it is inferred from the definition. In non-conditional functions, the return value is usually the product of the last line of the function

In Haskell we don't use parenthesis (parens) for function input; in this case 'x'. Haskell automatically infers that the data following a function-call is the input (also called the argument). We also don't need to actually use the word 'function'. This is a relief. It allows us to give the function a name which helps us separate one function from the countless others your programs may have. Using Haskell notation, we'll give it a nice descriptive title: 'momsAge'. In Haskell-eese we write the above function like this:

momsAge x = x + 25

Not much of a difference there, so we'll move on.

OK, but wait, where's all the stuff where I asked her how old she was and took the notes and then spoke the answer to her? That's all IO. You will no doubt remember that none of your math classes covered anything like that. As it turns out, simple stuff like asking a chick in your class a question is really hard to describe in mathematical terms. The only way to do it is to use an abstract tool called a monad, which we won't talk about for awhile. All that matters is that monads are what allow IO in Haskell and, more succinctly, monads are what allow Haskell to exist in the first place! No monad, no Haskell. By learning Haskell IO from the start, you are learning a little about monads from the get go; for now you don't need to know much more than that; other than to say: monads are nothing to be afraid of.

Forget about monads for now. Haskell IO is really composed of a mix of tools and structure. The tools consist of a set of built-in operations which Haskell calls 'IO Actions' or just 'actions' for short. In any other language these actions would be just another primitive operation like plus, minus or divide. But in Haskell, they are quarantined from the rest of the language under the rubric: 'actions'.

Common actions are: 'print', 'getLine', and 'putStrLn'. Of course, there are many others. Then there is the IO structure which is really what makes IO on Haskell so confusing for the unitiated.

The Haskell IO structure is dominated by rules on top of rules. In good dynamic languages, IO is so easy that the pupil learns it instinctively with only a few syntactic definitions from the author. With Haskell, you need to make sure that your code is laid-out according to a merciless set of rules. The rules are extensive and they don't come naturally. There are aspects that don't really make sense at first. As I gain insight, I will add posts to the subject of Haskell IO in order to create a methodical approach. The idea being that once you understand the rules, you should be able to synthesize your own code with impunity. 'Showing you how' just does not work with Haskell IO. Now, if I haven't scared you away yet, here's the core set of rules:

Haskell IO Rules of the Road

1. All IO scripts require a "main = do" function which acts as a spine around which the other functions of the script are attached. Think C/C++. This makes for easier-to-read code, but Haskell also requires it. In this way, main becomes the entry point for the program but also becomes the 'director' of the other functions. In other words: always start your IO script with 'main = do'.

2. Remember to give each separate step in your function it's own carefully indented line. The exception here is 'do'. Put 'do' on the same line as 'main' without any particular indents.

3. Create seperate functions for standard input (outside of 'main'), then bind them to a variable within main using '<-' . Avoid putting any standard input commands directly within "main = do". Haskell has no problems with you putting specific output commands like ' putStrLn "Hello World" ' directly into main. But, it prevents input actions altogether. Thankfully, you can bind the output of a seperate input function within main for usage with later functions. This means that you will have multiple separate functions for even the simplest of IO scripts; weaving in and out of 'main' continuously.

4. Use '<-' only for binding IO functions. Any other (non-IO) binding can (and should) be performed with 'let x = n' syntax. This is also true when piping the output of a (non IO) function to a local variable. Like 'let a = momsAge 9'. Just remember that functions can be renamed in the same way. 'let a = momsAge'. You will find that a large portion of your compiler-errors come from missing arguments!

5. Separate non-IO functions from all other 'do' functions. Any mathematical operation or algorithm should be separated from IO functions like 'main'. You can still call those functions from within 'main'. This makes your programs easier to read and maintain but it also keeps your code from crashing during compile-time!

6. Use ' function = do' (do notation) for all functions that have IO actions in them. Get used to the fact that you will see many many instances of 'do' in large programs!

7. All 'do' functions must end with some sort of return value; even if that return value is only a print statement or onscreen command. This is especially true with 'main' statements.

8. Use 'print $ function x' to print the output value of a function (which itself has no IO actions) onscreen. You'll learn what the $ sign means later. For now, just think of it as the second part of this command with 'print' being the first.

9. Always be aware of the type of data you pass to an operator. Haskell is statically typed, unlike most other popular languages. This takes a lot of getting used to. 90% of the mistakes newbies make when writing their first IO programs come from type conflicts. If Haskell catches you trying to use an Integer operation (like multiplication) on a piece of data that was input as a String, it will refuse to compile the program! This happens all the time with numbers (numbers can be both integers and strings). The getLine function only outputs Strings, regardless of the input you give it; which leads us to rule #10.

10. The read command is your best friend! If you bring in a variable (a number) with getLine, and you need to perform an arithmetical operation on it, use read to convert it (temporarily) into a Number just long enough to perform the operation. Remember that the variable will revert to its original type once the operation is finished.

In part 2, we'll look at the actual Haskell code used to automate the momsAge function from beginning to end. In every section where one of the 10 IO rules is implemented, I will mark the applied rule and how it interacts with the structure of the overall module.

Haskell Chapter 1.2

2012-08-13T14:29:00.000-07:00

"I'm the operator with my pocket calculator!" -- Kraftwerk

On Basic Operators and Calculators

Most first-semester programming students know enough about computer-languages to understand that each language has operators -- which are miniature programs that are 'built-in' to the language. There are, of course, a whole library of operators around which the programming language is built. In many ways, the process of learning to program revolves around learning to expertly use the most crucial operators of the given language.

In this text I will attempt to explain operators and basic data-types that apply specifically to the lessons at hand. However, since this text is also an attempt to implement scaffolding in literary form, those operators and data-types should provide the student with a well-rounded set of tools which can be used to explore their own extra-curricular questions and experiments.

Basic Data-Types

Numbers

The Number or 'Num' is the most basic data-type. There are different types of Num: Integers, Floats, Ints, Doubles and variables as well as a few less common types. We will mainly use three types: Integers, Floats and variables. Variables are a 'universal type' in that they are merely memory slots with no type of their own; that leaves us to Integers and Floats. You should already know what an Integer is. A float is just a decimal of some sort; called Float because that decimal can 'float' around depending on the accuracy specified by the programmer. The important characteristic of numbers or Nums, is that you can perform all sorts of mathematical operations on them. However, you cannot do this with Strings or Chars. This is an important distinction because a Char can be ANY symbol at all; including a number.

Characters

The Character type is any symbol you can find on your keyboard. These symbols are standardized by an organization called ASCII. They have a binary value, which you can manipulate to create some interesting text-processing modules. However, they are mostly meaningless to Haskell. Characters are there for the reader to read. In order to perform arithmetic on a Char, you need to convert it to a number first using an operator like 'read' -- which we will read about later.

Strings
Strings are lists of Characters. As such, they are the first lists you will use in this text. There are different types of lists. Lists have there own large set of operators; and all of those operators work on Strings in the same way. Lists are complicated enough that they need their own Chapter to do them justice. However, for now just remember that Strings are really just special lists which consist of 2 or more Chars. Instead of the brackets used in other types of lists, Strings are enclosed by double-quotation marks.

Variables

Variables are different from Chars because they don't use quotation marks or any special IO operators. A variable is just a label for a memory slot in which you can deposit values for later use. Other than that, they are identical to variables in algebra and thus take on the characteristics of whatever data you put into them. Variables should always be given descriptive names. Avoid variable-names like x or y. In real-world scripts, terse variable names will drive you crazy and significantly reduce your productivity.

Literals
Literals are anything other than a String or Char. Numbers and Bools are literals. Literals are what we use in the language of mathematics. Strings and Chars are what we use in human languages like English.

Bools

Bools consist of two symbols: True and False. Written just like that, always with the first letter capitalized. As you probably already know, Bools are the core units of Logic. Either a statement is True or False. Bools are also great for running tests: 'if x is higher than 100, return True'.

GHCI the Calculator

One of the best things about having an interactive programming environment, like GHCI, is that it allows you to utilize the power of the language on-the-fly. You can perform complex algebraic calculations on Nums that would put a top-of-the-line graphing calculator to shame. You can also test out and casually use a whole library of interactive modules by simply loading the necessary module. As a result, the environment itself becomes a tool for learning and troubleshooting.

Below is an explanation of some of the most common operators and the syntax required to use them. Open up your favorite text editor and give them a try as you read. If you have a Linux OS, you can right-click on the terminal and select 'Always On Top'. This will allow you to view and scroll the background blog-text while working within the terminal. If you have an Ubuntu variant of some sort, you can probably set the transparency of the terminal window too. This allows you to see any text which runs behind the terminal window -- very handy.

Before we get to the good stuff, there is one final concept behind operators which we must explain. There are three types of basic operators: Inline, Infix, and Modified.

Infix Operators are the most familiar type of operator. Examples include most of the common arithmetic operators like add ('+'), multiply ('*'), and exponentiate ('^'). If you want to find the square of two you type '2^2' at the GHCI prompt ('Prelude>'). Infix operators go between the values you are calculating: 'Prelude> 2 * 2'
Inline Operators are a little less common. These work much the same as an algebraic function. Inline operators always come at the beginning of the operation. The values which you plug in to an operator are called 'arguments'. Those arguments come after the inline operator you are using. A good example is the modulo or remainder operator. This nifty tool allows you to find only the remainder produced by dividing two numbers. It is used like this: ' mod 4 2 '. Here we are trying to find out if there is any remainder left after we divide four by two. The answer is, of course, zero. 'Prelude> mod 4 2'
Modified Operators can be either Infix or Inline. This is helpful when you want to make a piece of code more readable. You can modify any operator by placing the modifier symbol ( ` ) directly before and after the operation you are trying to modify. Notice that this is NOT the same symbol as the single-quote, which looks like this: ( ' ). You could modify the modulo operation so that the dividend comes first, the modulo operator comes second, and the divisor comes last; just like you would do in formal mathematical notation: 'Prelude> 4 `mod` 2'

We won't waste time specifically stating whether something is Infix or Inline, unless it is not immediately apparent or it needs to be modified to facilitate the flow of the code. Usually you can tell by looking at the example.

We'll start with:

Arithmetic Operators

Add: +
Subtract: -
Multiply: *
Divide: div x y
Exponentiate: ^
Square-Root: sqrt x
Modulo: mod x y
Associate: ( )

OK, so there's not much in arithmetic which is different than what you or any grade-school student are already used to. Of course, there are others not listed here. For example, '/' can be used to divide literals (Nums that are not in variable-form). However, 'div' is more versatile. Checkout www.Haskell.org for complete lists of 'Prelude' operators.

Basic IO Operators

Now we will move on to IO operators because you will need them in the next section. IO operators just send an output (whatever you decide) to the screen. In this case, they send it to the onscreen display of the terminal.

Most IO operators deal with 'Strings'. Strings are just groups composed of Characters or Chars. Haskell has no ability to find meaning in Strings unless you write a program telling it how. So, to Haskell the Char '2' has the same meaning as the Char 'P'. This is important to remember. In later exercises, this knowledge is crucial. We'll start with the two most basic IO operators: 'getLine' and 'putStrLn':

IO Operators for Strings and Chars

getLine This is an input command -- as opposed to an operator. This command has no arguments. If you put getLine into a module, Haskell will stop what it is doing, record any keyboard input until the user presses enter, and immediately spit-out that input in the form of a String. If you enter a number into getLine, it will spit it out as a String, so Haskell won't know that it is actually a number.
putStrLn This is an output operator. It takes only one argument which must be enclosed in double-quotations. I find it is best to use putStrLn with parens like this: ' putStrLn ("Hello World!")'. putStrLn automatically displays the argument you give it in the terminal screen; without displaying the double-quotes or parens. One crucial rule to remember when using putStrLn is that it only accepts two kinds of argument: Strings and literals. If you try to sneak a function into the output of putStrLn, your module will fail to load!
<- This is the IO-Bind operator. This is a special operator which is mostly used with IO operations. It takes the output of any IO function, IO command, or IO operator and saves it to a variable-name of your choosing. So, if you write 'name <- getLine' in a script, it will run getLine and pipe the output into the variable 'name'. This is how you save important IO values for future use.
++ This is the join or Concatenate Operator. This allows you to join two strings together. This is usually used in an instance of 'putStrLn'; inside the parens but outside of double-quotations. Remember that last sentence. This is crucial when you are using Concatenate: ++ Goes inside of parens but outside of quotes.
read This is not really an IO operator at all. However, you almost always use read in conjunction with some previous IO operation. So I include it here. 'read' converts a Character into a number. This is a vital operator. If you use getLine to retrieve a number from the user, getLine will save that number as a Char or String of Chars. The problem is that arithmetic operators do not work on Chars! They only work on Numbers! So, use read (inline) in order to convert a Char into a Number just long enough to perform an operation on it. Once the operation is done, the variable containing the Char will revert to it's original state. There's one more rule about 'read' which you must understand in order to use it correctly: you must avoid using read in the argument of a function. This is because read changes the type of the argument and, as we have already learned, Haskell is based on a static (unchanging) type system. It is better to use read inside the definition of a function; where the rule is generally 'anything goes'.
let This is also not exactly an IO operator. However, you do use it to input and save data to a variable within ghci or within a function. It is a Bind Operator like the arrow ( <- ). Try this: 'Prelude> let x = 9'. Now you can add x, multiply, subtract or use any other one of the arithmetic operators on x. In this way we have 'declared the variable x'. That is, we declared that x is the name of a memory slot which we want to save data in. The stupid thing about 'let' is that we can't always use it in scripts (modules). For instance, for variable declarations which occur outside of a function and within a script, you simply type 'x = whatever'. This is also the case with 'Where' clauses, which we will learn about later. Because of this confusing inconsistency, I sincerely hope that the Glasgow Haskell folks will eliminate 'let' in the future. For now, we just need to remember that 'let' is only used within ghci and the body of functions. 'let' is only designed for non-IO applications like arithmetic functions and variable declarations.

For the moment, don't worry too much about IO operations. Instead, try using ghci as a simple calculator. Open up an old algebra book and try out some problems which use variables and parens. Use the 'let' operator to deposit values into variables and test the results. You will find that parentheses (parens) work the same in Haskell as they do in your algebra textbook. Haskell is designed to use as much mathematical notation as possible. This makes it familiar and easy to use for anyone with secondary-school education under their belt.

Warm-Up Exercises

Use ghci as a basic calculator using the arithmetic operators above.
Use 'let' to declare a variable. Try performing different arithmetic operations on the variable.
Try-out some basic problems from an old algebra text which make use of variables and parens.
Find the most difficult order of operations problem you can and calculate it in ghci. Check the results.
Use 'putStrLn' using the rules listed above in order to display 'Hello World' within ghci.
Use 'getLine', '<-' and the variable 'n' to save your numeric keyboard input.
Use 'read n' with the arithmetic operators listed above. Use parens to insert 'read n' into the arguments of Inline operators -- just as you would in formal mathematical notation.

Haskell Chapter 1: Getting Started

2012-08-12T20:22:00.000-07:00

If you're not using Linux (or Unix) already, you should be. Sure, you can install Haskell on just about any kind of pc, but the Linux OS was designed by coders for coders. Trying to learn programming on Windows or Mac is a bit like trying to become a gourmet chef by getting a job at McDonald's. Why would you do that? Linux is Le Cordon Bleu and everything else is McDonald's. Besides, modern Linux distros cost nothing and are actually easier to install and setup then their corporate counterparts. If you're worried about transitioning to a new OS, don't be. You'll find modern versions of Linux work in virtually the same way as the OS you are used to. Particularly if you stick to the Ubuntu-family; you'll quickly see that there really is no learning curve to speak of. I'll even pick a distro for you, click here: Mint 13 MATE

In Linux, you automatically get an unfathomably large library of free applications which usually work better than the paid kind, have better support (strange but true), and are open-source; so they are constantly being debugged, improved and upgraded. To get the software resources that automatically come with a good Linux distribution on an OS like Windows, you would need to pay tens-of-thousands of dollars in licensing fees. Then there's the fact that Linux is the most reliable OS ever made. The reduction in frustration-level alone makes it worthwhile. There's no reason to put it off, make the switch now! If you still insist on spending money on crappy ripoffs of programs that were originally written for either Linux or Unix, then you can go here and find an installer: the Haskell Wiki.

Now, if you have Ubuntu or Mint you can just open Synaptic Package Manager and search for 'ghci'. Install the latest version. See how much easier that is? Regardless of your system, the next steps are relatively the same.

One final note before we begin: You will see a lot of quotations in any text dealing with programming. This is a little confusing when you are starting out. When I tell you to type something a certain exact way, I will use single quotations to separate that code from the rest of the neighboring sentences.

I don't want you to actually type the single quotation marks themselves. Instead, type what's in-between the single quotation marks. Like, if I say type 'ghci', you type this: ghci . On the other-hand, if you see double quotation marks ("), go ahead and type those. Haskell uses double quotation marks to process certain types of data. If there are no surrounding lines of text (see step 7 below), I will omit the single quotes for simplicity's sake. Likewise, Haskell will present a 'prompt' which prompts you to type something. It usually takes the form of some library (like Prelude) followed by ' > '. I don't won't you to type 'Prelude>'. I do want you to type the text that occurs after it -- like 'Prelude> let x = 9'.

OK, let's Haskell!

1. Create a folder for your Haskell programs. This is a good time to start using the Haskell naming convention. In Haskell, we never capitalize the first word in a name. However we always capitalize the subsequent words -- all the while leaving out any spaces because Operating Systems don't like spaces (go-figure). So my Haskell program folder is called haskellPrograms. If you prefer, HaskellPrograms and Haskell_Programs will work for file names too.
2. Open up your terminal application and navigate to /haskellPrograms. This is important. Once you run the haskell interactive environment (ghci) in the next step, you will eventually need to load-up the programs you write. In order to do this, ghci needs to 'know' what programs you are referring to. It will automatically look in whatever folder you were in when you called ghci. In this case, that folder will be haskellPrograms.
3. Open your favorite text-editor (I use KATE). If you are using Linux or a Linux ripoff (Mac), you can just switch to another empty workspace with the click of a button. If you are still using windows, you must minimize your current screen etc, open the Programs menu, then open up some text editor and finally maximize the browser window every time you need to see this blog. Oh wait, you also have to do all that stuff with your terminal application too. Why are you still using Windows?
4. Go to the Edit>Preferences section of your text-editor. Now, locate the 'tabs' settings and change it to this: Tabs>Use Spaces>Number of Spaces = 8. Next, set the indent to Use Spaces>Number of Spaces = 2. This is crucial. Haskell is very sensitive to tab spacing. There is still no standard for tab spacing; some companies use 3 spaces, some use a fixed pixel width. If your text-editor doesn't use the exact settings above, you are in for a world of frustration! However, if you are using KATE, you can skip this step: KATE comes with the correct spacing out-of-the-box.
5. Open a new file in your text editor. Save the blank file as test.hs within your /haskellPrograms file. Dot hs is the suffix for Haskell source-code. Later when you compile your first program, the suffix will change. But, the suffix you will work with the most is ' .hs '. Now, you are ready to enter code into test.hs and load it into ghci.
6. Go back to your terminal and type 'ghci '. This will launch the ghci interactive environment. This is a program that lets you experiment with the Haskell language without compiling a program. Using ghci is a little bit different from writing an actual Haskell script, so I will try to concentrate on scripts instead -- that way you don't get too confused.
7. Go back to your text-editor and write this all the way on the top-left corner (do NOT skip a line) of the 'test.hs' file, which you should already have open:

main = do
putStrLn "Hello World!"

8. Now save test.hs. Go back to ghci (in the terminal) and type this ':l test.hs'. Colon l is the command for "load the following file", in this case the file we want to load is test.hs.
9. Now type 'main' and observe! If everything was entered into your text editor as described above, you should now see 'Hello World' on the line below, like this:

*Main>main
Hello World!
*Main>

Ya, I know what your thinking: that's a pretty lame program dude. Just bear with me here, it will get better real soon. For now, you have accomplished that famously devilish programming task: Haskell IO! Take a short break, drink some water, have a cookie. Next I'll explain the basic Haskell operations like arithmetic and IO. Using these, you can start experimenting with ghci and get a feel for what it's like to program in Haskell. But before we do that, you'll want to know how to leave your current ghci session and possibly load up another one: type ' :quit '. Be careful however, this doesn't always work! Some programs will endlessly read your keyboard input; even reserved commands like :quit.

One final word about the 'Prelude>' prompt. In Haskell, whenever you load a program module or library of program modules, Haskell conveniently displays the module or library that you have successfully loaded at the prompt. When you first start-up 'ghci', it automatically loads the standard-library known as 'Prelude'. Prelude is a collection of modules which the Glasgow Haskell folks believe to be vital to daily usage. It is a large library and it changes from time to time as the Haskell committee vote to insert or remove modules. There are other libraries which are just as crucial. In fact, I am often perplexed to find that basic common-sense modules are missing from Prelude but available in other places like Data.Char.

Haskell Prologue: Introducing Functional Programming

2012-08-11T18:58:00.000-07:00

All programs are IO

The questions is: how or why?

Yep, that's about it. All a computer program is is an automated method of taking some input (usually from the user), processing it according to some algorithm, and spitting out a result (usually onto the monitor) -- class dismissed! ...jk.

Now to the interesting part: How this is done. Now that you have this input-output model in your mind, let's talk about instructions. You need to give the computer instructions for following a sequence of actions. This makes your program useful. You tell the computer that you want to take a number from the user, multiply it by two, and print out the results onscreen.There are two basic ways of giving instructions to someone or something.

The first way is to give them a recipe that they must follow: measure a cup of flour, mix it in a large bowl with baking soda, yeast and water etc. , bake and you have bread. These are called imperative instructions. Most people default to this kind of instruction-giving. It's easy to understand, fast to learn, and does not require you to understand why the recipe works. It just works, and that's all that matters. This is the way that the entire body of human knowledge was originally built. Homo-erectus had no idea why mandrake root caused immediate death, they just knew that if you ate it, you died.

Reason, logic and science gave us a second type of instruction: declarative instructions. These are tricky ideas to get your brain around -- it would be safe to say that they don't come all that naturally. Declarative information is based around some set of fundamental principles in nature. For example: if you drop an apple from a tree, it speeds to the ground, bounces a bit, and then stays there for awhile until something else disturbs it. The declarative principle -- or rule -- behind this is gravity. Once you understand gravity, you know how to make an apple drop violently to the ground; just let gravity do the work. Declarative information seeks to explain why something happens. By contrast, imperative information seeks to explain how to achieve an effect. In short: declarative: why, imperative: how.

Most popular programming languages (C, C++, Python, Java) are based around imperative instructions. As a result of using them, you get used to telling the computer how you want it to act. The problem with imperative instructions is that they are not very well defined. For instance, every one has their own ideas around how you should bake bread. Bread in France is very very different from bread in Ethiopia. That's because imperative data never tells you why one action leads to a certain result. Simply put: the why is missing!

It's not all bad though. One of the really nice things about imperative programming languages is that they feel natural to use. A good example is Python. Python is designed to feel like a spoken language. It takes and processes instructions in a way that is somewhat similar to how you might write out a good recipe. Besides, there are no purely imperative or purely declarative instructions. In reality, all instructions contain a little of both imperative and declarative knowledge. However, most lean heavily on one type or another. Physics papers lean heavily on declarative data. Mapquest leans heavily on imperative info. Likewise, Python leans on imperative data, but it also features nifty declarative devices like functions.

Imperative-styled programming languages have worked pretty dang well for humanity so far. The problem is, when you start to create really large and complex programs (like artificial intelligence routines or video games) imperative languages start to get incredibly messy. The whole program begins to look like one big sloppy cookbook with little discernible structure. When problems start cropping up, it's extremely difficult to troubleshoot them in a largely imperative programming environment. Every little result is based around the results of hundreds of other little combined programs and it gets to where finding the original source of the problem (the straw that broke the camel's back so to speak) is an epic task. In short, all this happens because there is too much how-to in the program and not enough why should I? OK that's not the only reason: side-effects are a big culprit in debugging disasters; but forget about that for now.

If you want a program to think for itself, you have to tell it why you want it to do something, in addition to what you want it to do. This has some amazing benefits. With a small group of declarative descriptions, you can create a whole wide range of behavior. You can even use declarative data to improve imperative instructions. Not only can you tell a computer what you want it to do, and how to do it, in a declarative language you can tell the computer what each item is supposed to be and do and the language can then infer all the different ways that the items can interact with each other, without you ever writing it down. The computer understands why things work the way they do, what they are composed of, and how they can then be combined to achieve a task. As a result: you can write a computer program with way less instructions, you can organize the code into logical chunks, and you can tell the program how to deal with strange circumstances which you didn't expect. The best part of all is that declarative programs (when written well) come together to form one large functioning organism; wherein each chunk of code knows how the neighboring chunk works and what can, can't, and shouldn't be done with it.

So why isn't everyone using this elegant approach to programming? The issue here is that humans just aren't used to declarative thinking. We already have brains that know why we should and shouldn't do stuff. When we give instructions to other humans, we rely on this fact and only tell them what we want them to do. Occasionally we'll tell them how to do it, but we rarely tell them why. After all, they have brains too, they usually know why we want them to do something. The problem is that computers don't have brains. They only know exactly what you (or someone else) tells them and no more. In short, declarative programming just feels unnatural. That's a big problem for most people. If you want to unleash the power of declarative programming, you have to change the way you think. You have to force yourself to adapt to a different way of viewing the world.

Finally, how Haskell fits into all this. As you probably already knew, Haskell is a functional programming language. Haskell uses the functional programming paradigm in a way which makes it possible to create a declarative language. It does this by combining a strict and well described set of internal rules along with a very robust static typing system. The static type system in Haskell allows you to describe how you expect a program to function according to the types of data you use it with; instead of by merely issuing a set of rote orders which you expect to be followed blindly. There are a set of declarative rules behind every data-type. There are also many layers of gradually more abstract rules which govern how data-types and primitive operations can interact with each other. Haskell already knows why 1 + 1 = 2 and also why it is stupid to try and find the square root of "bananas". So, if you tell Haskell what every function you create is made of, and what you want it to do, Haskell can then refer to it's list of why and why-not and make decisions about what should and shouldn't occur in your program. In Haskell, the language itself makes decisions. Although this is true in lesser degrees with previous languages, Haskell forces the programmer to describe her program modules in terms which Haskell can then evaluate in logical terms according to rules instead of instructions.

The core unit of Haskell is the mathematical function. So, instead of creating instructions, you just create functions. Haskell then infers what you are trying to do as well as what you are NOT trying to do. It takes a lot of getting used to; but that's what this book is for.

Because imperative instructions come so naturally to humans, there can be no better way to introduce you to Haskell than to begin with Input/Output. The reason for this is that Haskell uses an imperative structure for all of it's IO actions. Like so many other features of Haskell, this makes good logical sense. IO is like a conversation between two parties. One party asks a question, waits and (with a little luck and good manners) the other party answers. This is a very linear process. Imperative programs tend to also be pretty linear. So, you get to start Haskell in the imperative realm. But, as you progress, you will see Haskell quickly giving-way to a more functional/declarative architecture. This is good. It allows you to transition into the world of function-think in a slightly less-jarring manner.

Besides all that, IO is what every program does. The bulk of novice programs you will want to attempt involve some IO (unless you are only using Haskell for mathematics). There are so many cool and creative things you can do once you understand IO; and so many of them require only a novice-level understanding of the fundamental Haskell operations. Educators need to promote enthusiasm about the subject they teach; because enthusiasm brings with it creativity -- and Haskell was made for creative thinkers. Why would anyone start writing a book on Haskell any other way? Oh wait, I know the answer: because it's hard to do. But, you don't need to worry about that: that's my problem. Just sit back and enjoy Chapter 1. Leave the details to me.

My approach to teaching Haskell is to create a sort of recipe sandwich. I will try and tell you the broad concepts for each task in declarative terms. Then, I will show you exactly how to accomplish a specific task, then I will show you why the recipe I just gave you works. Stay tuned!

Haskell Prologue: Exercise Formatting

2012-08-10T20:43:00.000-07:00

Concerning the Format

The approach I will be using for exercises is slightly different from what you may be used to. My intent is to end-up with a text which utilizes Vygotsky's scaffolding technique as much as possible. The idea behind scaffolding is to build-up complimentary skill-sets one after the other -- in order of easiest to hardest -- culminating with review exercises which utilize all of the previously-learned skills in harmony towards a common goal. Throughout the text, the student must be helped over frustrating obstacles by giving her all of the tools needed to succeed without ever depriving her of exercise; which is the main engine of learning. In this way the student is only introduced to new ideas once she has mastered all of the prerequisite principles. The student should never be abruptly thrown into a new skill, subject or technique. This causes frustration which is the enemy of learning.

I will try to give the student a toolbox composed of primitive operations and the applicable rules which must be utilized in order to use them in a given exercise. There are usually countless ways to realize a program module. But I will only focus on the obvious techniques which can readily be compiled from the catalogue of skills the student has on hand. I will also attempt to rehash earlier exercises in later chapters; whenever new skills are introduced which would lead to a more efficient and mind-expanding rethink of the originals.

Finally, I will attempt to identify discreet complications which spring from novel combinations of previous tools and skills. Oftentimes, the complex interactions of multiple layers of rules and instructions can create learning-hurdles all their own; even though the student has mastered the founding principles at play. A good example of this can be found in algebraic order-of-operations problem-sets, wherein superimposition of already mastered rules creates new and befuddling interactions in their own right. It is not enough to help a student to understand the basic tools and rules, a good text should also help a student understand the different possible compound interactions which can occur in a program by ingraining pragmatic methods which cover all but the most abstruse eventualities; even at the expense of efficiency.

Efficiency and program optimization are necessarily advanced topics whose importance is grossly over-stated in elementary texts and didactic blogs. An English Grammar student should not be taught to fret over topics like narrative perspective or tense-rigor when they cannot even punctuate their sentences or utilize conjunctive phrases correctly. Doing so out of place only leaves the student with a foggy haze of disjointed knowledge where there should only be methodical rigor.

While this may initially sound much the same as any other educational approach, it is differentiated by a certain level of detail which is missing in current textbooks. For starters, the subjects to-be-taught must be sequenced in a painstakingly deliberate way. It is not enough to create a sequence which 'feels natural', scaffolding requires that all subsequent subjects be accomplished using base-skills which have already been aquired. Scaffolding also requires that all possible obstacles be addressed within the educational programme itself; leaving no salient phenomena to be discovered through independent study. Contrast this to a modern Math textbook which shows the student only basic rules and examples, and relies on either the teacher, tutor, or student to explain everything else. In the context of both large classrooms and independent study, this is a foolish approach for obvious reasons. Whether or not I can achieve this on paper remains to be seen. The intent is there and I will do nothing other than to keep building on that intent after the text is written.

Haskell Prologue: My Sources

2012-08-09T15:43:00.000-07:00

As I write Intro to Programming with Haskell I am also reading four other books at once:

Each one of these books has some strong points in their favor. For instance: LYAH is funny and disarming, which makes it easy to approach while HTCFP has a lot of practice exercises and a gradual approach to building proficiency (see the Western Way to Learn); which are both mandatory imho. I won't copy or reprint any of their work, but I will provide links to their sites when I don't have time to elaborate on a subject which I feel they've covered adequately. I'll stick to covering topics that I feel have been missed or flubbed in some way.

I'm a young technical writer, so I won't claim to be a sage on the subject ( you can find plenty of problems in my previous work for yourself ) but I know enough about writing to see that current Haskell textbooks are obviously geared to experienced coders who feel like picking up a tertiary hobby language in their downtime. This is a bogus approach for many reasons.

For starters, I am a firm believer in scaffolding. You must always attempt to undergo the teaching of a new subject with a clean slate (although this is never 100% possible but that's another article). Because, each new volume will be based upon an arbitrary set of previously-established working concepts. If you (as a writer) did not establish those working concepts, then that means nobody did. When you assume, you make a culo out of you and me. Besides, Haskell is just too important of an advance in Computer Science to be relegated to a hobby-horse. Functional Programming itself is nothing new, but the zen-like balance of elegance and expressive-possibility in Haskell allow it to solve modern programming problems with ease. It frees us from the current CS paradigms and allows us to create new ones.

So, for now my writing will be loosely guided by the above texts. However, as I see deficiencies, I will diverge. In this way, the more I write, the less of an influence the above texts will be. I've already decided to make a major divergence from every text on Haskell I know of: I have decided to present Haskell IO first. "Huh? This guy's crazy!" Check out Chapter 1 and you'll see why.

Re-Learning to Count with Haskell pt.2

2012-08-07T21:46:00.001-07:00

Easy as Pi, and that's not very easy at all!

The basic idea of recursion is to create a feedback loop. Exactly the sort that Jimi Hendrix used to create his immortal guitar sound. In a computer program, a function is like a guitar amp. It amplifies the input according to some mechanism of your design. If your guitar pickups receive the sound being output by your amp, the amp then amplifies that sound, then your guitar picks-up the sound at an amplified level, the amp amplifies THAT sound and it goes on and on until you transcend the mortal coil and achieve rock-nirvana (which for me is Nirvana). That's recursion. Example:

function x =

x + function x

Notice how it says x PLUS function x, the 'plus' part is the amplifier I was rambling on about.

The problem is that the program which does this will never terminate; it will go on forever (which is what laymen call 'hanging') until you pull the plug on the amp. So, what if you could program-in some condition wherein the function 'pulls the plug' on itself. This is called a base-case.

The program below counts how many elements there are in a list of Integers:

count :: [Integer] -> Integer

count [] = 0

count (x:xs) = 1 + count xs

The base-case here is the second line (count [] = 0). This says "when you come to an empty-list, output the Integer 0."

The third line features a magical symbol which I call "Head-Tail Notation": (x:xs). In this symbol, 'x' represents the first item in the list and 'xs' represents the rest of the list or the 'tail'. This allows us to split the list into sections, which is incredibly useful. For instance, '1 + count xs' says "add one to the output of the 'count' function as it is applied over the remainder of the list ('xs' is the remainder of the list)." With this tool, we can operate on each item in the list -- one at a time -- until there isn't anything left in the list. Again, the second line gives us an exit from the program which is triggered by an empty list.

Finally, we add 1 to the output of each successive pass of count xs. Remember, with each pass through 'count' ( if we make it past 'count [] = 0' ) the 'Head-Tail' operator will split the head off of whatever's left of the list so that we are only operating on the tail or (xs).

With the color red signifying the 'unseen' operations performed by the cpu, the flow of operations would go like this:

Assuming that [] means 'empty list'

listA = [1,4,7]

count listA =

~ count [] = 0 -- False, Continue

~ count (x:xs) = 1 + count [4,7]

~ count [] = 0 -- False, Continue

~ count (x:xs) = 1 + ( 1 + count [7])

~ count [] = 0 -- False, Continue

~ count (x:xs) = 1 + ( 1 + ( 1 + count []))

~ count [] = 0 -- True, Output 0

~ Output (1 + (1 + (1 + ( 0)))) = 3

To recap in plain English, we take a list which (in this case) has 3 elements. We test the list to see if it is empty. If not, we proceed to the next 'definition' in the 'count' function: line 3. This definition says that we want to split the input list into two parts, the first element (head) and everything else (tail). Then, the definition says, "add the number one to whatever the output of 'count the tail' is. This is the feedback we were talking about. Since we are not including the 'head' in our feedback loop, we know that the list will get smaller as the 'head' is removed with each pass; until the list is empty. Once that happens, we know that line two will trigger the feedback loop to 'pull the plug' on the whole function. However, Haskell knows we still have all those 'plus ones' to add together. It then uses that sum as an output value. Voila, counting achieved!

This is all fine and dandy except that Haskell already has a built-in function for this called 'length'. Besides, what we really need is a conditional function; something that will allow us to count a specific type of element amongst a field of others. I call this conditional counting, but it would probably be better to call it selective counting. That's what the next function does.

'countElems' takes an Integer and looks for it amongst a list of other Integers. It has almost-the-same base case as 'count': countElems x [] = 0. In function definitions, we must always include BOTH arguments; even when one of them is not being used for that line. Here we include x, which is the target Integer: the Integer we are trying to match. In definition 3, we plan on splitting the list into a head and tail section; so we employ 'head-tail' notation. Since we're using the name 'x' for the target Integer, we can't use the name 'x' for our 'head-tail' notation; for fear of confusing the compiler. Thankfully, Haskell understands the 'head-tail' symbol natively. As a result, it knows that (x:xs) is the same as (y:ys) when used in an argument. This allows us to avoid confusion in our definition.

countElems :: Integer -> [Integer] -> Integer

countElems x [] = 0

countElems x (y:ys)

| x == y = 1 + countElems x ys

| x /= y = 0 + countElems x ys

The key maneuver here is that we used 'guards'. Here we say, "if x is equal to y (the 'head' of the remaining list), then add 1 to the output of countElems on the tail end of the list ('ys'). If not, add 0." With each pass through 'countElems', we chop off one more item from the list and add either 1 or 0 depending on the outcome of the two tests:

| x == y = 1 + countElems x ys

| x /= y = 0 + countElems x ys

Just like 'count' above, we eventually chop all the elements off of the list until nothing is left. This triggers the base-case. The real magic here is that Haskell knows to then go backwards and sum-up all of the 'plus 1' operations and then spit out the sum upon exiting the function. Well, the magic is that it does all this without being told to. Actually, it remembers all of those 'plus ones'! So Haskell does have a memory after all!

Still, you see now that Haskell really does cause you to review all but the most basic of mathematical processes, like counting and memorizing, through the mind-bending lense of recursion For this reason, I believe that recursion should be taught as early as possible -- perhaps Chapter 2. Whenever I finish Chapter 1, I'll give it a go.

Re-Learning to Count with Haskell pt.1

2012-08-07T19:24:00.000-07:00

Functional Programming in a Nutshell

It is becoming clear to me that counting, particularly conditional counting, may be one of the core lessons of Functional Programming and thus Haskell. A pure FP language has no mutable-state variables. Likewise, there are no global-variables in Haskell. This makes counting a serious problem for those new to FP and thus to those new to Haskell.

This marks a crucial divergence in how programming languages are designed. Imperative languages make liberal usage of mutable-state global variables. This makes realizing a program into an intuitive process. Imperative languages represent the way that the human mind reasons verbally. For instance, in order to count we memorize a number and add to that number using a universally known-sequence: the number line. At all points during our calculations, the current state of that number (the tally) is known. In this way, all variables are global in the human mind. Not only are they global, they conform to patterns like the number-line.

For instance, if you give someone a collection of single digit numbers at random, and ask them to assemble them into an ordered list, we know by sight which place-setting each individual number belongs in. We do not need to use a merge-sort or insertion-sort method. We simply look at a number, say 7 for example, and intuitively know that it goes ahead of 1 through 6 but below 8 and 9. When we sort, we simply put each number into it's place, there is little to no method needed because we have such a firmly ingrained number line already in our heads.

Now, we pick up a Haskell book and find that Haskell can't even remember numbers. It has a memory like the compartments of a Nautilus shell, each one closed to all others and none aware of the other's existence. This is supremely frustrating to the uninitiated because counting is one of the first skills we learn and we spend our entire lives doing it exactly the same way. In order to use Haskell, you have to take that fundamental pre-school era tool and chuck it out the window.

There is only one fundamental tool in Haskell: recursion. Functions are merely a method devised to implement recursion. In order to count, you need to understand recursion. In order to store state-data, you need to utilize recursion. In order utilize recursion, you need to utilize recursion. Its enough to make your brain melt.

Once a function outputs a piece of data in Haskell, it is gone forever. You can try to capture that piece of data using a declaration like 'let tally = product [1,5,6,2]'. But once you declare a piece of data (like 'tally'), it is set-in-stone. You can never change 'tally', you can only destroy it and make a new one. This is the crux of FP. If you can accept and master these core precepts, you can master FP. If not, then you might-as-well sell your Haskell texts and forget that you ever even heard the phrase Functional Programming. In fact, this is exactly what the vast majority of people do. Not just students, professionals, academics and instructors do this in droves. More people reject FP than those who last long enough to learn to use it productively. This is unquestionably a massive weakness to the FP paradigm. However, I don't think it is inexorable.

The fundamental problem with FP is that there just aren't any good texts on the subject. The few that exists are unorganized and vague, most likely because there just aren't enough professional writers in the FP writing-pool. The few authors who will take-on the subject seem to know that FP will never really take off and so only write for the benefit of the most harcore programming enthusiasts, and as such, completely gloss over the most basic of subjects like: How to Count in a Functional Programming Language. I will therefore devote my next blog entry to this fundamental subject. Look for part 2 in the coming weeks; where I shall spell it out free of charge.

Haskell is poorly explained

2012-07-25T19:46:00.001-07:00

WARNING: The article below was written in a passionate wave of anger over Haskell's ponderous learning curve. I know it's logic is flawed. However, I am confident that plenty of other Haskell newbs have encountered the same issues and are also banging their head into the wall. Since this section of the blog is about Haskell from the learner's perspective, I have decided to publish it now, and edit the salient points at a later date when the smoke of my ignorance has cleared:

Most of the problems listed here (I suspect) are a result of poor documentation by all of the resources I have used so far. Having said that...

Yes, it's true Haskell is a functional language, and as a result should not be held too strictly to the tenets of competing non-fp languages like, say ohhh, Python for instance. Python is a superbly easy language to learn from scratch (with zero CS background), and can do just about anything a programmer would ever need to do in the current professional environment. Haskell, is one of many candidates for a new ubiquitous general programming schema (functional programming) which may one day supplant the older imperative programming paradigm. In order for FP to push programming into a new direction and solve the current set of programming limitations, it needs to also do the simple things at least as well, if not better than, the current selection of popular general-purpose languages. Indeed, for it even to be considered a general-purpose language, it needs to excel at the basic level. As such, it is assumed that Haskell (and any other good implementation of FP) can do things other languages can't do very easily or very well. It is also assumed that it will take some getting used to in order to master FP having come (as 99% of every coder on the planet has) from an imperative programming environment.

I've been trying to keep this in mind as I develop my attitude towards Haskell as a learner and petty blogger. The problem is that this is not a valid excuse for the many problems facing anyone attempting to learn Haskell without a full-time professor, teacher's aid, or tutor on hand. I personally have begun to use freenode #haskell in lieu of such a resource. But, that is not an ideal solution. The people on #haskell are wise and generous, but they have no obligation to patiently explain things to a frustrated learner. They do so anyways (because they rock), but the IRC format itself forces all but the most blunt and carefree of folks to limit their inquiries for fear of being flamed or banned as a niuscance.

So, that's no big deal, a good text can change all that. Haskell doesn't have a good text. But I am starting to realize, that is not the sole issue either. I am not a cultural relativist. I believe, scratch that, I know that there are some human behaviours that are right and some that are wrong. It doesn't matter if Functional Programming is based on a totally different way of thinking about problem-solving (which it isn't), there are some basic user-interface considerations that are universal and have nothing to do with the structure of the programming environment. Haskell defies some of these most basic considerations:

Inconsistent Syntax between interactive environments and compiler. Commands and declarations that work on Hugs don't always work on ghci and vice-versa. Commands that work in ghci and Hugs in interactive mode do not always compile. This is dumb. Plain and simple. There is no excuse. There is no point trying out program snippets in an interactive environment that gives totally different results from the compiler. That just defeats the point of even having an interactive environment. IDLE exemplifies how this can be done correctly.
Conflicting rules based on still more hidden laws. In Chapter 2 of Haskell: The Craft of Functional Programming we are asked to create a module which loads yet another module and uses it's code as a basis for new functions. We have previously been told that indentation is optional in Haskell. We have also been told that indentation is really just a way to make the contents of a function easier to read; and can be dispensed with at will. However, the only way to import a function inside of the definition of another function is to indent the import command, like this: >module name where > import oldmodule
IO what a mess... Yes, I know Haskell IO is based on Monads which are themselves an attempt to separate impure data from pure data. Fine, I get it. But, can we at least get a listing of the reasons behind the ponderous IO mentality at work here? For example: We are told that IO actions have to be performed within a function which is, itself, an IO action. We are also told that IO actions cannot be called outside of the 'main = do' function. Then we realize (I have yet to see this documented anywhere) that certain IO actions (like getLine) cannot be called inside of 'main'. In order to bring data in from the outside world, we need to create seperate functions, each with their own 'do' notations and then call them from main. However, main handles output operations like putStrLn just fine. Why? Likewise, we are told that main, and all other 'do' notation functions must end with a function or command that returns data. Yet, some functions or commands mysteriously don't work, despite meeting all of the qualifications needed. Other functions that do work return no data whatsoever except null (). Why the inconsistency? Then there's print. Print works sometimes and then fails spectacularly at others. And, it should'nt be about type; since print has the capability to display data of all built-in types from Ints to Bools. You eventually learn to use print sometimes and putStrLn at others; often without knowing why. Why is this so hard?!
'let' it be already... Declaring a variable is one of the most universal processes that occur in programming. It's the core function. In Haskell, you say 'let x = whatever'. The only problem is that let doesn't always work. For instance, try declaring a list in hugs. 'let x = [1,2,3]' doesn't work. 'x = [1,2,3]'? Nope. How the hell do you declare a stupid list? Yes, there is a way, but who cares? Why do we need to learn a 3rd way to declare a list in Hugs? We shouldn't even need to learn two ways to declare a simple variable. There should only be 1! In the time it takes to figure this out, you could be making list comprehensions in Python that already work!
Pointless compiler reports that even professors can't understand Why bother? If you can create a logically consistent compiler output then you can also link it to a simple pattern-matching algorithm (perhaps using Haskell's own pattern-matching toolset) that gives the user some information that is actually useful. Most of the compiler errors I have run across fall into one of four categories: 1) A function is missing an argument 2) You used the wrong type for some function or operation 3) You are missing an indent (even though indents are supposed to be voluntary). 4) You are missing parens somewhere. What's the point of even having error-messages when even the experts have a hard time understanding them?

My point is simple: Haskell is not ready for prime-time. I'm at the point where I must choose to continue studying Haskell even though my gut is telling me that the designers never intended the language to actually be used. Thanks to LYAH, I have seen some of the ways in which Haskell can be exceptionally powerful compared to what I'm used to (Python and C++). I also know that I am an undergrad and my opinion will change once I gain mastery of the language. As a result, I am resolved to continuing my study of Haskell.

Still, I can already see why the language is doomed to obscurity in it's current state. It will need either massive ergonomic reform, or an exceptionally bright text to overcome it's pointlessly steep learning curve.

Why programming has never really caught on...

2012-07-12T19:36:00.001-07:00

Wait, I know what you're thinking

"Is this guy retarded or something? Programming is a multi-billion dollar business! Of course it's caught-on!" That's not what I mean. Sure there are thousands of professional coders out there, and millions of end-users (OK probably closer to billions). But, why don't those end-users code? The closest we, as a society, came to utilizing the power of programming en masse was the HTML/CSS boom of the early 2000s. Now, thanks to wordpress and scores of other turnkey solutions, that boom is in the rear view. Why aren't average schmoes coding?

The reason has to do with symbolic leveraging. This is a cognitive phenomenon that occurs with any language; human or otherwise. The point behind symbolic leverage is that a symbol only has meaning if the reader has a built-in association for it. A good example is the Indus Valley Script. The civilization who read that script is extinct. So, the language is now useless. To make matters worse, the language was highly developed -- not like hieroglyphs whose meaning could often be gleaned by sight alone. The IVS symbols are highly abstracted (like the Arabic script used in English). The more highly abstracted a symbol (or programming module) is, the more useless it is to the uninitiated.

The IVS leverages it's symbols on information that already exists in the user's mind. This allows it to quickly cover massive amounts of highly complex concepts with an economy of words. This is great for the lazy writer, and horrible for the student. In the case of written 'natural languages' (there's no such thing -- but that's another story), this only works in generalized societies with institutionalized rules which attempt to enforce equality and freedom of property-rights. After all, why spend your hard-earned money to train slaves or indentured servants to read when they can't own property and will only ever do manual labor.

In our own world society, this has only been the case for about 150 years (in some places far far less) out of a recorded history of about 7000 years and a biological history of about 500,000. Amazingly enough, the bulk (some believe over 80%) of the last 500,000 years seem to have been spent without verbal language! In the historical past, only the rich had the time and resources to hire a teacher to decode their own written language for their education; and that was usually because their caste depended on property exchanges -- which are encoded in written language -- to maintain their status. Even then, it took up years upon years of the human student's most prodigious period of learning to achieve this: childhood. In short, language itself is a pretty recent invention!

Now enter computer languages: most are less than 20 years old, most are not taught to the public, and ALL rely on symbolic leveraging to a degree that has never been known in the history of humanity. Even the modern math that computer languages are based on is less than a century old. Add to that the fact that computer languages are typically written by mathematicians and engineers; those people on planet earth with the absolute WORST of communication skills and by far the greatest amount of abstract symbols with which to leverage their new -- impossibly terse -- computer language.

The reason why this is a problem can be best explained in computer programming terms. In computer science, the programmer who chooses to write a program which discretely solves all possible problems a user can throw at him (brute-force programming) is called a schmuck. A good programmer, instead, creates declarative rules for problem solving, then creates a form of artificial intelligence which can use those rules to solve each new problem as it occurs. Unfortunately, they never apply this principle to the structure of the programs they create. As a result, each stand-alone program is itself just a discrete collection of responses to all the foreseeable problems the user can throw at it. Ironically, we coders continue to find ever newer and more abstract techniques of using complex declarative rules to create a solution which, in and of itself, is merely a discrete collection of 'canned' responses to a shockingly limited amount of inputs.

As a result, the average user has no idea how to automate even the simplest of tasks on his computer. The language of automation is so obfuscated with entropic jargon and arbitrary syntax inspired by abstruse flights of mathematical fancy, that he would need to devote a minimum of four years to his life (at the expense of all his other activities) in order to gain the knowledge needed to make his computer do what it was supposed to be doing for us all along. The only way we know to solve this conundrum is by paying a coder way too much money to come along and give us a handful more 'canned responses' which themselves are impossible to automate for the end-user. And so the cycle continues.

The reason why the natural language programming paradigm won't die (no matter how much it is demeaned by pro coders) is that it offers a way to do just that; to increase the intelligence of the computers we end-users use and unleash the truest power of the computer -- the power to automate. Until coders change the way they think about coding, computers will never reach the next level. Each new OS will look more and more like the last one and the role of the CS pro will begin to diminish instead of increase. It's already starting to happen. Think about how little progress has occurred between Windows XP and 8, OSX Tiger and Lion, Ubuntu 10 and 13.

The future of commercial programming is natural language processing and it's bosom-buddy: AI. We need to start using the programming language as a way, not only to create powerful and economical abstractions, but as also as a way to begin absorbing the burden of symbolic leveraging instead of placing it entirely on the programmer. It's already happening; just witness the astronomical growth of Python and the cutting edge Go project from Google. We have reached the limits of our capability to deal with abstractions effectively, this is why Haskell will never really catch-on, and why Lisp never really did.

Imagine a world where we use the computer, not just to gossip with friends and send messages to one agency or another, but where the computer is an extension of your body; your will. The computer will be like an open-source personal secretary. Freed from repetitive monotonous tasks, the end-user will be allowed to a lot their development time towards specializing in that most noble professional niche; creativity. We will be free to apply our mind to tasks that really matter to our human survival in ways that only humans can do using our imaginations. In terms of creative vision, that beats the crap out of Facebook!

The Inherent Intelligence Principle

2012-07-12T14:02:00.002-07:00

Figure it out on your own!

There is a well-meaning tendency for technical and educational authors to over-explain certain details to the extreme that they actually obfuscate what would otherwise be a simplistic subject. This is an artifact of technical writing which comes from a sense of diligence and thoroughness. Any good technical writer knows that it is crucial to cover as many steps as possible in the explanation of complex instructions.

However, a good technical writer also knows that the average reader is able to piece certain things together on her own, which saves the writer time and allows the student a little breathing room in what would otherwise be a stiflingly slow read. The problem then becomes, how do I know what material to cover and what to 'gloss-over'? Most writers just make intuitive guesses, for better or worse, and chalk it up to a 'hazard of the trade'.

Thankfully, this is an unnecessary compromise. There is a shockingly simple and organic way to allow the reader to decide on her own. It requires a more modern way of thinking about technical text and the employment of an idea which is unique to the information age: the hyperlink. And no, you don't need a computer to implement this technique, although it certainly helps simplify the process.

In many ways, the qualities that make a good technical writer are much the same as those that make a good parent. That is, a good parent shows her children the behaviour that she expects from them, instead of constantly telling them. For instance, if a good parent wants their child to be quiet in public places, then she herself will endeavor to be consistently quiet in public places. Contrast this to the parent who stomps around Walmart yelling at her children over the slightest of offenses and then subsequently yells at her children when they talk too loudly and generally make an embarrassing scene. Kids don't care half as much about what you tell them to do as what you yourself are doing.

With this analogy in mind, take the subject if an introduction to Haskell. One of the first (if not the first) things you learn in any programming class is basic IO. There are a number of logical reasons for this which extend beyond tradition; basic IO is essentially what all programs do, at some level or another. A program is an abstract computational device which takes data in from the outside world, processes it, and spits it back out. In order to begin programming (which is the only way to really learn a programming language), you need to understand IO. Once you do, you can create a nearly infinite selection of programs using only a basic understanding of that program's primitives.

The problem is, Haskell was written by sadists who believe that basic IO is a second class function of computer programming. Don't get me wrong, I like Haskell quite a bit. But, how do you teach computer programming with a language which fervently resists the input and output of data at every turn?

What most writers have done so far with Haskell, is show you everything else you can do with Haskell first, and save basic IO for the intermediate stages of the course. This is a HUGE mistake. There simply aren't that many practical programs which can be built without some form of IO. As a result, most Intro to Haskell books have little to no assigned practice work. For instance, Learn You a Haskell, Real World Haskell, and the Intro to Haskell Wikibook: A Gentle Introduction to Programming with Haskell. This goes against all established educational theory concerning Computer Science. In order for a student to gain any thing more than anecdotal knowledge of a new programming language, they must spend more time coding it than reading it.* The reason why authors make this mistake is that explaining Haskell IO to the uninitiated is pretty difficult. However, you don't need to explain everything in order to give a Haskell newb a working knowledge; and therein lies the problem.

Humans have an innate understanding of language hard-wired into their gray matter. The main way in which we learn new human languages is through exposure and by differentiating context. That is, we learn multiple ways to say something and deduce the meanings of those slight differences in expression automatically. This natural process of deduction is the foundation of logic and lives in the same spot of gray matter as language itself. Nobody tells a baby "This is the word 'Mommy': it means the person who feeds you." The baby would never learn if that were the case (due to the Primum Movens paradox). By this same mental process, you can present Haskell IO to Intro students from the get go.

When they come to some irreducibly complex element of your explanation ( a 'roadblock' ) they can then either click a hyper-link featuring gradually more detailed explanations or flip to the correct page in your manual for elaboration on the sticky subject.

Here's an example. We want to introduce the student to Haskell IO and assume that the student has no prior CS experience. This should be the only approach when teaching a new language, regardless of the student's level of indoctrination -- see my article on scaffolding**. Here's the didactic text:

1) Let's display "Hello World" in your computer's terminal:

Prelude> putStrLn "Hello World"
Hello World

1b) Now display a warm-fuzzy phrase of your choice in the terminal

Prelude> putStrLn "I like Haskell!"
I like Haskell!

Here the student just learned that putStrLn is the command for displaying strings onscreen without being told a thing about it or how it works or what a string is.

2) Now let's get some information from the person sitting at the keyboard (you) and put it into ghci. Enter this phrase and type your name at the following prompt.

Prelude> getLine

ryan

"ryan"

2b) Now get your age and print it onscreen.

Prelude> getLine

20
"20"

Yes these are over-simplifications (for your sake), but the principle is evident and it holds at all higher-levels. A reader doesn't need to be told anything at all about putStrLn, they can look at it, mentally elminate Hello World from their reasoning (because it is the message and thus not the method for displaying said message) and see then that the only remaining commands are putStrLn and "".

The user knows that quotations marks are used to display exactly what a person said or is being instructed to say. They will also see that the quotation marks do not appear in the onscreen output. They will have no choice but to deduce that quotation marks are expected when entering a command into putStrLn. So, they usually know to use quotation marks again in the 1b problem. If not, they can just click on the hyperlinked-word putStrLn and be presented with a note explaining this explicitly.
They also already know that capital letters are only used at the beginning of a new proper or formal word. So, they know that putStrLn has to be a concatenation of put+str+ln. Even if they don't know what str and ln mean, they know what put means. They will immediately connect put with the fact that they are currently trying to put some data onto the display before them. Since you showed them that this is indeed what putStrLn does, they know to use if for this. 9 times out of 10, they will correctly perform exercise 1b. The same goes for getLine and many more basic commands.
By using the same command on two different types of data (letters and numbers) the student now knows that getLine can be used for multiple things; not just for names. All this without mentioning a thing about 'types'.

As I am slowly writing my own Intro to Haskell, you will see better examples of this principle later on. But for now, with a little imagination, you should see that it is also possible to leverage information that exists in every persons brain in order to explain difficult concepts. This is Vigotsky's principle of scaffolding and it's utility in CS should be apparent now. If not, check in from time to time. This is a theme I will be writing on often.

*For a good contrast to this recipe for didactic failure, check out MIT Open Course-Ware's Introduction to Computer Science using Python: Introduction to Computer Science and Programming

**That article is currently still pending.

Emerge the Hive Mind

2012-07-08T23:14:00.002-07:00

Most creative people know this feeling: you've been nursing an idea in the back of your mind for years or even decades. Maybe it's a widget or some academic discovery you haven't had time to properly write-up. Then one day, you take a break and turn on the boob-toob and whadaya see? Someone on the other side of the country (or world) is introducing your idea and reaping heaps of praise for it's ingeniousity! What a bummer! Then you have to go back to your stupid job waiting-tables and cursing progress for not waiting on your brilliance

This has happened to me too many times to count; one day I'll write them all down (he he). However, I know now not to be angry about it. History is actually full of these sorts of synchronous discoveries. The perfect example is Leibniz and Newton.

If you have ever taken a Calculus class, you know how ridiculously improbable it seems that anyone would invent Calculus in two separate places, unknown to each other, at exactly the same time*. I mean talk about the limits of human understanding, Calculus is right there -- straddling the borderline. How could two people think of the same sadistic way to torture undergraduates at exactly the same time?

Well, it happens all the time. There is a perfectly good reason for this. There are no truly individual discoveries. All discoveries are built on the pool of knowledge available to the people of a time. For example, if you went back in time 2000 years ago and gave the standard IQ test to everyone you met on your travels, your results would illustrate that everyone you met is a mongoloid, and should probably be put in an insane asylum. Of course, they aren't mongoloids. Knowledge is encrusted upon a civilization in a very delicate way that is not unlike how mineral deposits form stalactites. The pool of knowledge for that era just hasn't had the time or resources to encrust the necessary conceptual tools needed to return a passing score on our stupid 20th century IQ test. However, once the requisite information is in the public consciousness, discoveries are inevitable.

Our population and information-technology is so highly developed now, that people have created a live, real-time hive-mind. It doesn't really matter who ends up writing that paper on the idea you had. After all, if you had the resources ten years ago, you would have written it before her. The point is that the idea be expressed using the scientific methods and conceptual frameworks in existence in such a way as to resist logical attack long enough to enter the public consciousness and make a change for the good.

In order to advance past the current messy state of human progress, we need to focus, not on who had the idea first, but on whether we were able to prove or disprove it using the terminology and theoretical framework of Science.

Our need to create heroes to worship is a uniquely western fascination. We have tricked ourselves into believing that everyone can be a hero if they just meet the right people and work hard enough. This is hogwash. Improving the human condition is not unlike improving an unhappy relationship. The only thing that will help is if we each 'work on our shit'. That is to say, we each know what our faults are. If you want to make improvements in life, as in society, you need to start doing the things you know you should have been doing all along. Take the trash out, tell your loved-ones you love them, and stop worshiping heroes. They are just people who 'worked on their shit' enough to garner the fickle adoration of the masses.

If we forget about the need to find new heroes we may actually break down the academic wall that prevents ideas like the one you had ten years ago from being popularized. This is the idea behind Open Source. And contrary to the beliefs of the entire academic community (up until the last 15 years), it works! Open Source took the entire mainstream academic world by surprise. It only gets stronger every day. This is the emergence of the hive-mind in micro scale. Millions of people all around the world who have let go of their need to be heroes or billionaires and submitted their work for all to use, rip off and forget to cite.

Long live the hive mind!

*OK, it didn't happen quite like that but, my point still stands.

The Western Way to Learn

2012-07-08T22:35:00.002-07:00

As mush as possible, as fast as possible...

There is a very silly book out there by Paramahansa Yogananda that introduced me to a unique revelation about the western way of learning. I won't waste my time quoting it verbatim, but the idea was that westerners learn each subject as quickly as possible, almost as if this were all some big race. Of course, they never really learn the subject at all.

The Indian way of learning was presented by way of example: when an Indian is taught the Vedas, he is taught each verse over and over until it becomes an unforgettable unit of his mental processes. Only then does the instructor move on to the next verse (never mind the next chapter). The end result is that the student can recite the Ramayana by memory, unbroken, as easily as if he were asking you for a glass of water.

This is no doubt an example of Vedic hyperbole (or maybe not), but it hits at an important point. Westerners rush our education with disastrous consequences. We zoom through the subject matter in record time without ever really understanding it or, worse yet, knowing how to use it. I know this to be true in my gut as I'm sure any reader will. Yet, as a person who hates rote memorization with an ugly passion, how to address this shortcoming?

My solution is to reduce all of the underlying techniques of each discipline into some combination of fundamental scientific, linguistic, or mathematical principles -- using a common terminology. Then, as I learn new subjects and rehash the old ones, I submit myself to a more endurable form of rote memorization. Each time it feels new, yet each lesson is composed of ideas I know well already. This creates problems. First of all, how do I describe complex and subtle artistic ideas in universal (often mathematical) terms. Also, as I do this, I must discard the entropic terminology of the art-form in question and substitute my own. As a result, professionals in the field have no idea what I'm talking about should I choose to converse.

Besides, this is a slow process and bedeviling to the nth degree. I still haven't realized enough of this declarative language to publish a lexicon or method to teaching it. Nonetheless, progress occurs and I find myself retaining a little bit more and more with every effort. It makes logical sense and it seems to be working. It's a work in progress and I resign myself to being called a crackpot in the meantime. But hopefully not in the same league of crackpot as the aforementioned writer.

Knowledge-Retention

2012-07-08T21:40:00.001-07:00

or 'Aww, what was that thing called?'

I have a confession to make, I'm a drifter. Well, not the handkerchief-at-the-end-of-a-stick kind of drifter (although I've done that too), I mean I'm an intellectual drifter. I have a lifelong obsession with learning new skills which I will probably never use. Once I understand the underlying principles at work in a new skill or art form, I immediately lose interest and move on to something else.

This is not even half as cool as it sounds. I'm already approaching middle-age, nearly broke, and I don't have much to show for my obsession other than some cool stories. No really, this is pathological in my case. I have changed majors so many times that my relatives no longer wince when they ask me "so what are you doing these days?" They just know it's going to be some outlandish answer which will change in a year. I already have about four years in school and still no degree. I have over 80 credits and no freakin' degree* (as of this writing at least).

However, there is one crucial lesson I would never have learned otherwise; most experts never actually learn how to learn. They just internalize a set of behaviors until it becomes something akin to 'muscle-memory'. This always irritated the hell out of me. Once I fully understood music theory (back when I was a music major), I also then realized that great performers were just people who sat in their room all day and repeated the same mind-numbing exercises until their hands 'knew what to do'. I couldn't imagine a more boring existence, never mind the astronomical odds against a musician ever making a dime in her profession. Still, I can confidently say that I know how to learn better than most of my professors ever will.

So, when I inevitably move on to some new field of study, I can't help but notice how quickly the hard-won knowledge I gained disappears. I'm no genius, but I'd say I have an above-average intelligence. I have discipline-for-days, an organized mind, and undying tenacity. So, imagine my shock at seeing that information slip away from me in days -- not even months or years, DAYS. I used to be able rattle off every inversion of every chord, letter name by letter name at will. I could sit down with a circuit-diagram and find the Thevenin Equivalence by hand within minutes. Now, I barely remember what Thevenin Equivalence even means. And no, I don't drink, smoke, box, or do anything else which could be construed as self-destructive.

Thus, I have begun a crusade to retain all knowledge I currently gain, and reclaim all of the knowledge and skills I have lost over the years. This crusade has forced me to realize a central truth of education: most of the crap we teach ourselves and our students gets forgotten faster than it was learned. I'm talking record time. Ask any math-teacher about what happens immediately after summer-break every year of their career. Sadly, only the brightest and best retain enough knowledge to actually absorb new material throughout the semester. Most average students just play catch-up all year long and graduate with passing-grades and only a tentative understanding of the subject at hand.

Add to this the fragmented format in which math and most other subjects are taught, and you have a recipe for, well, America's public school system.

Currently, my method to defeat this innate human tendency is to find the underlying principles behind every course of study I have undergone so far and formalize it into one declarative language of ideas. Then, each new subject I learn is really just a refresher course with some unique discreet applications in theory. Flashcards, extensive notes and this blog itself are my primary weapons against Information Overload while I develop UP in the dark. I think it is working, but only time will tell.

This new method has opened me up to UL and ultimately spawned Universal Primitivism. It only works with practice though, and there is so much work to do with no guidebook on how to do it. Still, I foresee most people thinking this idea of UP is idealist or even silly, with good reason I suppose. But maybe if you understand why I'm doing it, you will find it is not silly or idealist at all, in fact it is purely pragmatic because it comes from a very real challenge I undergo every day: me versus my memory.

*All 80 credits with straight-As mind you! Well, unless you count those two Bs in Music Theory, man those were hard classes!

The Limits of Human Understanding

2012-07-08T20:34:00.002-07:00

Contrary to popular belief, there is a very real limit to what humans can understand in real time. Sure, we can build new theories out of old theories and publish them to great effect. But, in terms of real-time, moment to moment operation, humans are very limited in their capacity to carry out complex chains of instructions.

In other words, academia has long since outlived it's direct usage to that average human. In order for us to gain the fruits of state-of-the-art science, a for-profit corporation (like Microsoft) has to come along and develop Applications with a user-interface that falls squarely within the attention-span of the average human. Scientists are just as susceptible to this phenomenon as brick-layers (just look at the sales for Mathmatica and Matlab). Nobody is exempt.

Computer scientists simply create new abstractions and sell them as "Apps". This is the grand totality of all human knowledge made tangible. If we simply accept this limitation in momentary human awareness, we can begin to make progress in education. For instance, if we know the area limits of a subject wherein the concepts involved are starting to become so complex that people have ceased to use them publicly (Algebra: do you still know what an imaginary number is?), then we need only design the next group of abstractions to address those operations on the outer limits using some intuitive interface.

A good (if oversimplified) example of this is the nines tool. You should know this, but I'll repeat it for argument's sake: Nine times any single digit number is equal to the next lowest integer in front of the number needed to create nine: 9 * 8 = 72. The next lower number from 8 is 7 and the number needed to create 9 with 7 is 2. Therefore, 9 * 8 = 72. This intuitive leveraging tool allows us to internalize some of the more difficult operations and devote our momentary awareness to the next plateau of concepts; in this case memorization of multiplication tables. Instead of fighting our limitations, accept them and layer our approach to education and knowledge creation around them.

The pressure of routine life and death decisions can create some startling pragmatic observations. For instance, the military (specifically the Air Force) has known about the limits of human understanding for a long time now. They even have a phrase for it, "task saturation". They also invented the popular term "information overload". They now know that abstractions need to be employed in an intuitive way in order to keep their pilots alive. The academic world can take a lesson from them.

After all, there are only so many ways a person can interact with the world around them. Thankfully, all but the world's most mind-boggling processes can be represented in visual or tactile ways that require a minimal amount of effort from the student (or jet pilot). The problem is finding these analogues and employing them in a consistent way. A good starting point would be to incorporate the types of ideas found in books like Arthur Benjamin's Secrets of Mental Math into primary school education. Of course, most of the problems a computer scientist deals with are well beyond mental math. But, there are always easier ways to solve a problem that do not involve symbolic rigor. For example, when you first approach systems of linear equations in a college algebra class, it can be a little overwhelming. There are different approaches to solving the problem using algebraic manipulation of symbolic notation. However, the easiest way of all is to plot each line and see where they all intersect. There are tricks like this at all levels of mathematics. We need only to take advantage of them.

For my purposes, just accepting these limitations is useful in and of itself. It means that students are allowed to think about programming in terms of what they know, and not in terms of whatever Latin-inspired symbolism is being espoused by the popular culture of the times.

The Current State of Introductory Computer Science

2012-07-08T20:08:00.002-07:00

Outline

There are basic programming primitives which an introductory student faces; regardless of the language you want to learn. For instance, you need to create variables and assign them values like numbers or words (strings). Then, you need lists of numbers or words (etc) with which you can populate, depopulate and test for membership. You also need to perform operations on them like addition or subtraction.

These core primitives form a toolbox with which you can create programs that do important tasks with mechanically perfect execution. This is the same regardless of the language.

Once you learn to master the basic primitives, you can perform all sorts of useful and interesting (even artistic) functions on just about any language platform. Yes, of course there are dizzying heights of complexity which can be reached (in shockingly different ways) with each discrete language. But, those concepts are of no use to you, the beginner. In fact, teaching them at this stage will only make your life hell. Why should you try to understand what a Monad is if you don't even know what a conditional statement is?

This doesn't stop authors and professors from shoving these ideas down your throat. To their credit, they are beneficently trying to introduce you to difficult concepts early on; so that you have so much familiarity with them that, by the time you actually need to use these concepts, you intuitively apply them to solve tricky problems.

The problem is that the human mind just doesn't work that way. In truth, humans aren't too good at dealing with symbolic abstraction (like sigma or delta etc). Ironically, the greatest scientific minds of all times belong to rebels who chose instead to 'visualize' complex abstractions in ways that made sense to them but were still mathematically useful -- think Einstein's thought experiments.

All an abstraction is, is a way to encapsulate a series of complex operations into a 'black box' which we can use without worrying about the intricate details of it's operation.

However, when mathematical symbolism is employed, the exact opposite happens. The student is confronted with what looks like an alien language which works in mysterious ways and is only ever explained using yet more self-aggrandizing academic symbolic terminology designed to prove the author's intellectual command of language and NOT to educate.

Here's an exaggerated example of poorly used symbolic terminology. Say you're a rock guitarist. A mathematician (were she writing a peer-reviewed paper on Electronic Dynamics Control Systems in the neighboring room) would tell you that you need to conscientiously modulate your low-voltage transducer output using a logarithmic potentiometer in series with your high-z output rectification stage. However, a fellow musician would simply say, "Hey man, turn your axe down!" Both sentences say the same thing. However, the first one is precise to the point of facetiousness. The other gets the same abstract point across in universal terminology that also provides some nice visualizations; a guitar does actually look a bit like a battle axe, when you adjust the volume knob it does get turned and the sound does seem to go down; from any observer's vantage.

This is not merely a trivial argument designed to inflame anti-academic sentiment, it really does point out a salient commandment in academic writing: teachers should always seek to explain things in the most intuitive way possible. There is no logical place for abstruse verbiage in the education system unless it increases the student's intuitive understanding of the subject at hand.

The pointlessly confusing word-choices in academic instruction today are designed to ensure that the author is published on merit of their own 'literary expertise' and have no didactic use whatsoever. It is the stated goal of UP to end this shameful practice formally.

With this in mind, I will introduce the primitives to the student first. Show them how to use these primitives in a (initially limited) set of popular languages. When the primitives themselves begin to diverge widely in their language's handling, only then will I introduce new theoretical structures and then only to explain the difference in their application. The depth of the student's understanding of the language will grow organically in as much as the student is required to understand in order to accomplish universal programming tasks, and no more.

There is a glut of literature on the market explaining all of the most mind-bendingly complex subjects in Computer Science and disturbingly little covering all of the myriad useful tasks that can be accomplished using only the basics. Basic programming tasks like file I/O and merge-sorting have become so hopeless ensconced in techno-babble that many students drop-out altogether before they even learn to use them.

This creates a disconnect between author, student and teacher. Only students who are already indoctrinated in the academic material have any hope at progress in CS (and most other sciences). This is, to put it in academic terms, ass-backwards. Yet, it ensures that tenured professors continue to procure publishing contracts and speaking engagements; which is why it dominates educational literature.

In summary, you will learn about the byzantine abstract mechanization underlying your chosen programming language only when you need to; and then only in the most intuitive and useful way possible. If every level of CS education were instructed in this way*, there would be more CS graduates and more advancements in the field. Professors would no longer have sole authority on the subjects they teach! I wonder why this approach hasn't caught on yet?

*Of course there are a handful (just a handful) of fine books out there that manage to do this very elegantly. CSS: The Missing Manual by David Sawyer McFarland is a shining example and an inspiration to aspiring technical writers like me.

2012-07-08T20:00:00.001-07:00

What do you mean by primitive?

The term primitive is, I hate to admit, one of those self-aggrandizing academic terms. However, it's use is justified. There aren't many other words in computer science that have the intuitive connotations and verbal flexibility of the word primitive. After all, a primitive can be both a noun and an adjective. It summons imagery of a rag-bedecked cave man throwing a rock at a passing antelope. This is useful imagery!

A primitive is just a basic building block. It's a completely relative term. It also helps you understand that computer programs are layered like an onion. If you are looking at the outer most layer of an onion which sits in a pile of other onions about to be sweated into a French Onion Soup, that particular onion looks like one irreducible building block of the soup. But, of course, an onion has a bewildering amount of layers beneath the one you are looking at.

Computer languages are written in other computer languages, which themselves are written in other computer languages, which themselves are eventually written in binary code, which itself is an arbitrary (processor-specific) language that is composed of things like op-amps, memory and counter ICs which are themselves arbitrary arrangements of transistors. Transistors are strange little devices that take advantage of the strange behavior of elements like silicon, germanium, and phosphor to produce a simply massive amount of effects which are so confusing that most programmers have simple no idea how they work. Hell, even if you understand how one type of transistor works pretty well, there are literally thousands more that work in completely different ways! Is this starting to sound familiar in any way?

This is actually a lot like one of Mandelbrot's fractals. That is, you see this layered construction, wherein each layer does the same sort of thing as the one above it, but in increasingly complex modalities which themselves get harder and harder to understand. This is the genesis behind my idea of a Fractal Programming Language: If these layer's are unavoidable, why not give them one coherent topology and syntax which covers all the necessary primitives needed to build programs of any level of complexity. Then, each layer of programming consists of the same set of core primitives, with new functions created (out of the layers below) to deal with ever-increasing levels of abstraction?

OK, now that your brain is spinning, back to primitives. Just think of primitives as basic ingredients with which you can 'cook' up new recipes.