For some time, I have written blog posts on dev.to about text generation, and even went so far as to collect them into an online ebook. In one of the chapters of said e-book, written in 2016, I made predictions about the future of text generation. One of those predictions was “Statistical Approaches Will Be Part Of A ‘Toolkit’ In Text Generation”.

Statistical approaches are good for presenting text that looks human-ish. It is very effective at producing evocative words, phrases, and sentences. However, the generated text quickly turns into gibberish with even short-term exposure. The generated text could not “scale” upwards to novel-length works.

That didn’t mean statistical approaches (e.g., machine learning) were worthless. Indeed, the fact that it can produce evocative text is, well, pretty cool. But you would need to combine it with another approach (‘structural modeling’, e.g. hardcoded text generation logic) - essentially using machine learning as part of a ‘toolkit’ rather than as a sole thing.

That’s was true back in 2016. It’s still true now. My problem was assuming that it would always be true…and only now do I realize my error.

It’s like predicting in the 1850s that people will never be able to develop airplanes. He would be correct in the 1860s. And even in the 1870s. But one day, airplanes did get invented, and your prediction would be proven wrong.

When OpenAI announced in February 14th 2019 that it has created a neural network that can generate text (the infamous GPT-2), I was flabbergasted at how coherent it was - even if the examples were indeed hand-selected. Sure, there were still flaws with said generated text. But it was still better than what I originally expected. In a GitHub issue for my own text generation project, I wrote at the time:

Even though there are still subtle flaws in the neural network they have right now, those subtle flaws can be fixed given enough time and resources. OpenAI have demonstrated what is possible, and what is possible will wind up being inevitable.

Of course, I didn’t post a “Mea Culpa” back then. Just because something is inevitable doesn’t mean that it will happen immediately enough for it to be practical.

One month after OpenAI’s announcement of GPT-2, Rich Sutton would write a blog post entitled The Bitter Lesson.

The bitter lesson is based on the historical observations that 1) AI researchers have often tried to build knowledge into their agents, 2) this always helps in the short term, and is personally satisfying to the researcher, but 3) in the long run it plateaus and even inhibits further progress, and 4) breakthrough progress eventually arrives by an opposing approach based on scaling computation by search and learning. The eventual success is tinged with bitterness, and often incompletely digested, because it is success over a favored, human-centric approach.

Of course, Rich intended for this paragraph to advocate in favor of “scaling computation by search and learning” (the “statistical approach”)…but I could also read it in the opposite direction - that if you want to have results now, not in some unspecified time in the future, you want to build knowledge into your agent (“structural modeling” or a hybrid approach). Yes, your technology will be declared obsolete when the “statistical approach” prevails, but you don’t know when that happens, and your code is going to be obsolete anyway due to advances in technologies. So embrace the Bitter Lesson. If you want to write a computer program to write text now…well, then do it now! Don’t wait for innovation to happen.

Then, on May 28th 2020, OpenAI announced that it built GPT-3, which was a massive improvement over GPT-2, fixing several of its faults. The generated text does turn into gibberish, eventually…but now it takes medium-term exposure to expose its gibberish nature, which is remarkable to me. Interestingly, it’s also very good at “few-shot learning”…by providing the generator with a few examples, it can quickly figure out what type of text you want it to generate and then generate it. Here’s a cherry-picked example:

Human: To do a “farduddle” means to jump up and down really fast. An example of a sentence that uses the word farduddle is:

GPT-3: One day when I was playing tag with my little sister, she got really excited and she started doing these crazy farduddles.

Human: A “yalubalu” is a type of vegetable that looks like a big pumpkin. An example of a sentence that uses the word yalubalu is:

GPT-3: I was on a trip to Africa and I tried this yalubalu vegetable that was grown in a garden there. It was delicious.

Huh. So I guess people should have waited. Technology is indeed progressing faster than I expected, and in future text generation projects, I can definitely see myself tinkering with GPT-3 and its future successors rather than resorting to structural modeling. It’s way more convenient to take advantage of a text generator’s “few-shot learning” capabilities, configuring it to generate the text the way I want it to - rather than writing code.

OpenAI thinks the same way, and have recently announced plans to commercialize API access to its text generation models, including GPT-3. The ‘profit motive’ tends to fund future innovation in that line, which means more breakthroughs may occur at a steady clip.

I do not believe that GPT-3, in its present state, can indeed “scale” upwards to novel-length works on its own. But I am confident that in the next 10-20 years[1], a future successor to GPT-3 will scale, all by itself. I believe that statistical learning has a promising future ahead of it.

[1] I’m a pessimist, so I tend to lean towards predicting 20 years - after all, AI Winters and tech bubbles are still a thing. But, I am also a pessimist about my pessimism, and can easily see “10 years” as a doable target.

Note: This blog post was originally posted on dev.to.

repl.it is a very useful tool for distributing code snippets for other people to use.

But sometimes, you may want to use repl.it to distribute entire GitHub repositories (not just a single script). You could just drag-and-drop your GitHub repo, but that’s not a sustainable solution - it would only be a snapshot of the code, not the latest version of your repo. What you actually need is a solution that automatically fetches the latest version of your code and run it in repl.it’s Virtual Machine.

It’s actually fairly easy to do that (deploying a GitHub repo onto repl.it). You need to write a script that does the following:

1. Remove the existing folder, in case you already cloned it down before. You want to ensure you have downloaded the latest version of the code.
2. git clone the repo (ensuring that you have got the latest code).
3. Run the code (or come up with a terminal prompt to allow users to decide what code to run).

I wound up needing to write this sort of script when deploying a Ruby side-project of mine (Paranoia Super Mission Generator) onto repl.it.

I suppose it makes sense for this to be a bash script, but I couldn’t really get that to work due to (a) not being able to run ruby, and (b) lacking permissions to run files directly (which kinda ruins the point of using bash). So I wrote this as a Ruby script, though it does call some bash commands as approriate. Here’s how Step 1 and Step 2 worked:

%x{ rm -rf Paranoia_Super_Mission_Generator }
%x{ git clone https://github.com/tra38/Paranoia_Super_Mission_Generator }

Step 3 can be a bit challenging though, and may be somewhat dependent on the type of language you’re using. I’ll just tell you how I did it in Ruby.

First, repl.it doesn’t support requiring Ruby gems all that well, and require us to use bundler/inline instead of a Gemfile to install dependencies. Here’s repl.it’s blog post on the issue, and a tutorial on using bundler/inline. I could easily add the bundler/inline boilerplate within the deployment script though, so it’s not that big of a challenge (and doesn’t require me to change my GitHub repo code at all).

require 'bundler/inline'

gemfile true do
 source 'http://rubygems.org'
 gem "calyx", '>=0.18.0'

 gem "ruby-lzma"

 gem "redcarpet"

 gem 'progressbar'
end

Once these dependencies are installed, then my Github repo can require Ruby gems without any issues.

Second, due to permission issues, I could not use a command like ./Paranoia_Super_Mission_Generator/main.rb to run main.rb. However, Ruby does have a command called load, which allows us to load any arbitrary Ruby file. This circumvents the permissions file.

As a bonus, you can call load multiple times, meaning you can rerun the same Ruby file over and over. This means I could build a menu that allow users to pick whatever Ruby file they want to run (and be able to re-run that same Ruby file without any penalty).

Here’s how I wrote the code to implement this menu:

def menu
  puts "Welcome to PARANOIA Super Mission Generator. For instructions and guidance, please visit https://github.com/tra38/Paranoia_Super_Mission_Generator"
  puts "1 - ``main.rb`` (generate a mission based on a title)"
  puts "2 - ``railroad.rb`` (generate a mission based on a search term you want)"
  gets
end

def main
  load 'Paranoia_Super_Mission_Generator/main.rb'
  puts ""
  puts "Press enter to continue"
  gets
end

def railroad
  load  'Paranoia_Super_Mission_Generator/railroad.rb'
  puts ""
  puts "Press enter to continue"
  gets
end

while (true)
  input = menu.to_i

  if input == 1
    main
  elsif input == 2
    railroad
  else
    puts "Input invalid. Please...try again."
  end

end

Appendix Note:

Last time when I blogged about repl.it, repl.it did not support git, requiring me to download a “zip” version of my code instead. Today, though, repl.it does support git, so this is very handy and convinent. If repl.it didn’t support git though, I could still attempt to download a zipped file of my code, unzip it, and then run the unzipped codebase.

There are always multiple ways to solve the same problem.

EDITOR’S NOTE: As a fair warning, half-way through writing this blog post, I realized this whole endevour of comparing the pseudocodes of two different metaheuristics might not have been such a great idea (and may have indeed been a clever act of procrastination). I still posted it online because it may still be useful for other people though, and because I’m somewhat interested in metaheuristics. I also kept my “conclusion” footnote where I came to my realization about exactly how much time I wasted.

I’ve really enjoyed reading the book Essentials of Metaheuristics, by Sean Luke. It is a very good introduction to metaheuristics, the field for solving “problems where you don’t know how to find a good solution, but if shown a candidate solution, you can give it a grade”. Metaheuristics could be very useful for hard problems, such as generating regexes or producing human-readable text.

While reading htis book, I remembered a specific idea that I had in the past that I had previously forgot about. I decided maybe to revisit that idea.

I’ve been somewhat interested in the idea of building a poem generator, using the book One Hundred Billion Poems. According to Wikipedia:

Raymond Queneau’s A Hundred Thousand Billion Poems or One hundred million million poems (original French title: Cent mille milliards de poèmes), published in 1961 (see 1961 in poetry), is a set of ten sonnets. They are printed on card with each line on a separated strip, like a heads-bodies-and-legs book, a type of children’s book with which Queneau was familiar. As all ten sonnets have not just the same rhyme scheme but the same rhyme sounds, any lines from a sonnet can be combined with any from the nine others, so that there are 10^14 (= 100,000,000,000,000) different poems.

Obviously, you cannot read all 100,000,000,000,000 poems to find the best ‘poems’ to show to the interested reader. But what you could do is to come up with an algorithmic approach (sometimes also known as a “fitness function”) to measure how good a randomly-generated poem could be (the “grade” that Sean Luke talked about). Then, just randomly generate a bunch of poems, compare their grades to each other, and then pick the poems with the best grade. Sean Luke referred to this approach as “random search”.

Of course, random search, while effective on its own, is probably very slow. We can certainly do better than random search - and this is why the field of metaheuristics was created…coming up with approaches that may be more likely to find the best solutions to the problem.

However, at the time when I had this idea of using metaheuristics to generate poetry, I was only familiar with the most popular form of metaheuristics - genetic algorithms…and genetic algorithms required “mutation” (randomly changing one minor aspect of a candidate solution) and “crossover” (combining two different candidate solutions to create a brand new candidate solution). I’m comfortable with the idea of mutation but wasn’t too familiar with how to program “crossover” within a poem (and whether “crossovers” even make sense as a poem), so I did my own search to figure out other ways of solving this problem.

Through my research, I discovered Cuckoo Search, a fairly recent metaheuristic algorithm discovered in 2009, motivated by a metaphor of parasitic cuckoos. This approach didn’t require any sort of crossover (instead relying solely on mutation), meaning that it would probably be more suited to my approach of generating a poem than genetic algorithms.

However, I was concerned whether cuckoo search actually was “novel” (or if it is only well-known due to its reliance on metaphors to explain itself, and the algorithm could very well be simply another, already-discovered metaheuristic in disguise).

I was so concerned about this minor point that I asked a question on CS.StackExchange - the response from the CS.StackExchange community was essentially: “Does it really matter?”, which I have to admit is a pretty good answer.

When typing out my question, I wrote out the following pseudocode of Cuckoo Search:

1. User set the following parameters: the population of candidate solutions to generate (n), a percentage (p_a), and the number of iterations.
2. The initial population of candidate solutions (n) are generated.

3. Several candidate solutions are randomly selected for evaluation (this selection would be done using Lévy flight.

4. For each candidate solution selected for evaluation:
   • Generate a new candidate solution (called NewSolution)
   • Compare the fitness of NewSolution with the current candidate solution
   • If the NewSolution’s fitness is greater than the fitness of the current candidate solution, replace the current candidate solution with NewSolution
   • Else, throw away NewSolution
5. All candidate solutions are ranked, according to their fitness.
6. The worst (p_a)% of candidate solutions are discarded. The best candidate solution is saved in the variable “current_best”.
7. New candidate solutions are generated to replace the candidate solutions that were discarded in step 6.
8. Repeat steps 3 to 7 until the number of iterations is reached.
9. Return “current_best”.

(Sidenote: In the literature of cuckoo search, p_a is sometimes referred to as the “switching parameter”. It is also possible to vary “p_a” dynamically as well, instead of keeping it as a static value.

I’m also not sure whether my pseudcode for step #3 is correct. It’s possible that only one candidate solution is selected for evaluation in Step 3, and the generation of the canddiate solutions (both in Step 4 and in Step 6) is done using Lévy flight.

Also, I’m pretty sure you could replace Lévy flight with Gaussian Distribution, and indeed, a peer-reviewed article claimed to have made this substitution successfully.

The fact that I’m not quite so clear about the details of “cuckoo search” is probably a good argument for me not to use it. I’ve read “pseudocode” (and actual code) of several different implementations of cuckoo search and am still fairly confused as to what it is. Then again…does it really matter whether I’m following the ‘proper’ pseudocode? If it works…it works.)

Of course, having discovered this potentially useful approach to generating poems, I promptly forgot about this idea. I did eventually come back to it though after discovering and reading through Sean Luke’s Essentials of Metaheuristics.

Sean Luke did not mention “cuckoo search”, but he mentioned many other metaheuristics that are older and more popular than “cukoo search”, many of whom also doesn’t require crossover. One of those algorithms is Evolution Strategies, an approach developed in the 1960s that was recently used by OpenAI to improve the performance of reinforcement learning networks.

The pseudocode for the simplest form of Evolution Strategies (the “(μ, λ) algorithm” as Sean Luke called it) is as follows:

1. User sets the following parameter: the initial population of candidate solutions to generate (λ), the number of candidate solutions to keep after each iteration (μ), and the number of iterations. λ must be a multiple of μ.
2. The initial population of candidate solutions (λ) are generated.
3. All candidate solutions are selected for evalution.
4. The best candidate solution is saved in the variable “current_best”. The best μ candidate solutions are kept, while all other solutions are deleted.
5. Each of the μ candidate solutions gets to generate λ/μ candidate solutions through an ordinary mutation (a copy of the fit individual is made and then mutated). This means that a total of λ new candidate solutions get generated.
6. Repeat steps 3 and 5 until the number of iterations are reached.
7. Return “current_best”.

It seems that the (μ, λ) algorithm is very similar to that of Cuckoo Search, with Cuckoo Search’s “p_a” being the inverse of “μ” (“p_a” specifies how many candidate solutions die, while “μ” specifies how many candidate solutions lives).

The only main difference between Cuckoo Search and the (μ, λ) algorithm seems to be the existence of Cuckoo Search’s Step 3 and Step 4. A random candidate solutions is generated and could potentially replace a existing solution - right before a general purge of all “weak” candidate solutions commence. This means that slightly more candidate solutions could wind up getting generated and terminated under Cuckoo Search than under Evolution Strategies.

I think that this difference may very well be minor. While I still like the ideas behind cuckoo search, I would probably prefer using the (μ, λ) algorithm instead (due to the fact that it has been used for much longer than cuckoo search and there’s probably more of a literature behind it). Alternatively, I could also use another metaheuristic approach that doesn’t requires crossover (such as Hill-Climbing With Random Restarts or Simulated Annealing).

And…after spending 2 hour writing and researching for this blog post (which I thought would “only” take me 30 minutes), I realized that I probably wasted my time. While I like learning multiple different ways of solving the same problem, in the grand scheme of things, it probably doesn’t really matter what approach I take to generate poetry. Just pick one and go with it. Different approaches may come up with different solutions, but we probably won’t really care about finding the most “optimal” poem out there - finding one human-readable poem is good enough.

Besides, most of the literature about metaheuristics assume that you already have a good way of testing how good your candidate solutions are. But…er…I haven’t actually came up with said test yet (instead procrastinating by studying metaheuristics). Even if I do come up with that test, other people may not agree with that test (as they may have their own unique tastes about poetry). We can’t really reduced poetry (or indeed, any form of text generation) down to a simple fitness function…and it may take many fitness functions to fully describe all of humans’ tastes.

I suspect using metaheuristics to generate text will likely involve 90% “construction of good fitness functions to appease human’s tastes”, and 10% “picking a metaheuristic, fine-tuning it, and then running it to find a poem that passes your fitness functions”. So the real lesson of this blog post is to be a bit careful about ‘diving deep’ into a topic. You might very well be distracting yourself from what really matters.

P.S.: While I was doing research for this blog post, I found out about “When One Hundred Million Million Poems Just Isn’t Enough”, which contains a generator consisting of 18.5 million billion poems (ignoring the color of those poems). Another interesting corpus for me to look at and potentially use.

BUILD AND DEPLOY IN SECONDS. Instant programming environment for your favorite language.–repl.it’s homepage

I used repl.it primarly for hosting LittleNiftySubweb, a command-line script that enables me to use howdoi without ever needing to install Python. This is very useful to me since it allows me to easily use howdoi on Windows machines (since Python doesn’t come on Windows pre-installed).

Previously, I would need to “package” howdoi as an executable (which usually means bundling howdoi and its dependencies with a Python interperter) on another machine before porting the executable to Windows. This is a very time-consuming process. It also meant that upgrading to the latest version of howdoi would be a pain in the neck, since I have to create a brand new executable.

But on repl.it, all I need to do is to add this line:

from howdoi import howdoi # learn more: https://python.org/pypi/howdoi

And that’s it. repl.it would see if it has a local copy of howdoi, and if it doesn’t, download it (and its dependencies) from PyPi. Setup is a breeze…and not only that, but I’m always guaranteed to get the latest version of howdoi from PyPi.

I only need to install howdoi every time repl.it spins up a new instance of the Linux machine for me., and the installation process is pretty quick as well, so I can go straight into using the package.

Repl.it: Installing fresh packages
Repl.it: howdoi

Collecting howdoi
   Downloading https://files.pythonhosted.org/packages/bc/21/87dd3caacaa7c
   372a9838de8e2a2a9640043e72f382cf1300574e78e9a86/howdoi-1.1.13.tar.gz
Collecting pyquery (from howdoi)
  Downloading https://files.pythonhosted.org/packages/09/c7/ce8c9c37ab8ff8
  337faad3335c088d60bed4a35a4bed33a64f0e64fbcf29/pyquery-1.4.0-py2.py3-none-any.whl

...

Successfully installed certifi-2018.4.16 chardet-3.0.4 cssselect-1.0.3
howdoi-1.1.13 idna-2.6 lxml-4.2.1 pygments-2.2.0 pyquery-1.4.0
requests-2.18.4 requests-cache-0.4.13 urllib3-1.22
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

However, this system only works if the package you want to install exists on PyPi. What if you wanted to install a package from another source, like GitHub?

I realized this issue when I forked howdoi, created a branch (links), and made some changes before submitting a pull request. I wanted to test out my changes in a production environment while waiting for the PR to approved, but I didn’t want to deploy my minor fork onto PyPi – the fork would be renderered useless once the PR is approved and merged.

I created an experimental fork of “LiftyNiftySubweb”…called LittleNiftySubweb-Experimental (really creative name, I know), and then started tinkering with that fork, trying to see if I can get my version of howdoi loaded onto their system.

I remembered that pip does have an option to install a Python package from git. For example…

pip install git+https://github.com/example_user/example_repo.git

By default, pip selects the master branch to install from, but you can also specify what branch you want to install from.

pip install git+https://github.com/example_user/example_repo.git@example_branch

So all I have to do is to call pip with the proper command-line arguments (providing the link to my repo along with the the name of my branch) and it’ll all be set.

However, you do not have access to repl.it’s Linux instance directly. Instead, the only way you can access the instance and run commands like pip is through the programming environment. Which didn’t take too long to figure out.

def install(package):
  import pip
  pip.main(['install', package])

install("git+https://github.com/tra38/howdoi.git@links")

However, running this command revealed a very interesting error:

Collecting git+https://github.com/tra38/howdoi.git@links
  Cloning https://github.com/tra38/howdoi.git (to links) to /tmp/pip-vtyex9f7-build
  Error [Errno 2] No such file or directory: 'git' while executing command git clone -q https://github.com/tra38/howdoi.git

It is surprising to me that repl.it’s Linux instance doesn’t come pre-installed with git. I don’t know if it was meant to save space or if it was just an oversight on their part. Trying to programatically install git on their machine using a simple Python shell didn’t seem doable, so instead I explored other options.

A simple StackOverflow search later and I learned that GitHub also packages up its repos as zipball or tarball files (with each zip file referring to a valid “reference”, usually the name of a branch of the git repo).

pip install https://github.com/example_user/example_repo/zipball/example_branch

All I have to do is to directly provide a link to the archive that I want to download. pip can then read that archive.

def install(package):
  import pip
  pip.main(['install', package])

install("https://github.com/tra38/howdoi/zipball/links")

This works…sorta. I was able to download howdoi package and its dependencies, but installing these packages and dependencies lead to a permissions issue.

Collecting https://github.com/tra38/howdoi/zipball/links
  Downloading https://github.com/tra38/howdoi/zipball/links
Collecting pyquery (from howdoi==1.1.13)
  Downloading https://files.pythonhosted.org/packages/09/c7/ce8c9c37ab8ff8
  337faad3335c088d60bed4a35a4bed33a64f0e64fbcf29/pyquery-1.4.0-py2.py3-
  none-any.whl

...

PermissionError: [Errno 13] Permission denied: '/usr/local/lib/python3.6/site-packages/cssselect-1.0.3.dist-info'

One way to get around that permissions issue is to use sudo, but when you use sudo, you need to type in a password, and I don’t know what is the password for the Linux machine. Besides, using sudo is considered bad practice when using pip. Instead, I decided to specify that I want to install this packages into my own user directory, by using the --user command-line option.

def install(package):
  import pip
  pip.main(['install', package, "--user"])

install("https://github.com/tra38/howdoi/zipball/links")

Installation was now successful.

Collecting https://github.com/tra38/howdoi/zipball/links
  Downloading https://github.com/tra38/howdoi/zipball/links
Collecting pyquery (from howdoi==1.1.13)
  Downloading https://files.pythonhosted.org/packages/09/c7/ce8c9c37ab8ff8
  337faad3335c088d60bed4a35a4bed33a64f0e64fbcf29/pyquery-1.4.0-py2.py3-
  none-any.whl

...

Installing collected packages: cssselect, lxml, pyquery, pygments, requests-cache, howdoi
  Running setup.py install for howdoi ... done
  Successfully installed cssselect-1.0.3 howdoi-1.1.13 lxml-4.2.1 pygments
  -2.2.0 pyquery-1.4.0 requests-cache-0.4.13
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

But then when I try to use the howdoi module from that same script…

Traceback (most recent call last):
  File "main.py", line 33, in <module>
    from howdoi import howdoi
ModuleNotFoundError: No module named 'howdoi'
exit status 1

When I “run” my script again, I get something even more surprising.

First, I was able to import the howdoi module (and could successfully use my version of howdoi). This answer from StackOverflow explains kinda what happened.

If a path that does not yet exist is added to sys.path, it doesn’t seem like it will ever be checked again when importing modules, even if it exists at a later point (or at least in python 2.7).

This means that even though I installed the package, Python doesn’t know about it until after I run the script a second time.

repl.it’s Linux instance is using Python 3.6.1, so I believe that this behavior must not have changed.

Second, howdoi attempts to install a bunch of packages that I never even asked to be installed!

Repl.it: Installing fresh packages
Repl.it: BeautifulSoup, Pillow, Sphinx, beautifulsoup4, colorama, ctags, docutils, html5lib, pkg_resources, pymongo

Collecting BeautifulSoup
  Downloading https://files.pythonhosted.org/packages/1e/ee/295988deca1a5a
  7accd783d0dfe14524867e31abb05b6c0eeceee49c759d/BeautifulSoup-3.2.1.tar.
  gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-b4z379k2/BeautifulSoup/setup.py", line 22
        print "Unit tests have failed!"
                                      ^
    SyntaxError: Missing parentheses in call to 'print'

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-b4z379k2/BeautifulSoup/
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

But, let’s ignore BeautifulSoup and focus on howdoi here. I rewrote the code, following the advice from this SO answer.

# https://stackoverflow.com/questions/32478724/cannot-import-dynamically-installed-python-module
def set_up_user_directory():
  import os
  import sys
  import site
  # this makes it work
  if not os.path.exists(site.USER_SITE):
    os.makedirs(site.USER_SITE)
    # since I'm installing with --user, packages
    # should be installed here,
    #so make sure it's on the path
    sys.path.insert(0, site.USER_SITE)

def install(package):
  # set_up_user_directory()
  import pip
  pip.main(['install', package, "--user"])

But this wound up not working properly at all, since repl.it decided to automatically ignore my configuration, preferring instead to install the latest version of howdoi from PyPi (rather than my version of howdoi)!

Repl.it: Installing fresh packages
Repl.it: howdoi

Collecting howdoi
  Downloading https://files.pythonhosted.org/packages/bc/21/87dd3caacaa7c3
  72a9838de8e2a2a9640043e72f382cf1300574e78e9a86/howdoi-1.1.13.tar.gz

But you know what, I’m already fine with waiting for repl.it to download packages anyway (as you can see with my total disregard for the random package download of BeautifulSoup). With that in mind, I finally deduced a elegant hacky approach to the problem I’m facing.

Here it is.

# https://stackoverflow.com/questions/32478724/cannot-import-dynamically-installed-python-module
def set_up_user_directory():
  import os
  import sys
  import site
  # this makes it work
  if not os.path.exists(site.USER_SITE):
    os.makedirs(site.USER_SITE)
    # since I'm installing with --user, packages
    # should be installed here,
    #so make sure it's on the path
    sys.path.insert(0, site.USER_SITE)

def install(package):
  set_up_user_directory()
  import pip
  pip.main(['install', package, "--user", "--upgrade"])

install("https://github.com/tra38/howdoi/zipball/links")

When I run the script, repl.it first installs the latest version of howdoi from PyPi…

Repl.it: Installing fresh packages
Repl.it: howdoi

Collecting howdoi
  Downloading https://files.pythonhosted.org/packages/bc/21/87dd3caacaa7c3
  72a9838de8e2a2a9640043e72f382cf1300574e78e9a86/howdoi-1.1.13.tar.gz

...

Successfully installed certifi-2018.4.16 chardet-3.0.4 cssselect-1.0.3
howdoi-1.1.13 idna-2.6 lxml-4.2.1 pygments-2.2.0 pyquery-1.4.0
requests-2.18.4 requests-cache-0.4.13 urllib3-1.22
You are using pip version 9.0.1, however version 10.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.


Repl.it: package installation success

Then, it runs the set_up_user_directory() function to create a user directory and to add it to sys.path.

…and then it runs my commands to “upgrade” howdoi - thereby replacing the PyPi version of howdoi with my version of howdoi (located within a user directory that I have permissions for).

Collecting https://github.com/tra38/howdoi/zipball/links
  Downloading https://github.com/tra38/howdoi/zipball/links

...

Installing collected packages: howdoi, certifi
  Running setup.py install for howdoi ... done
  Successfully installed certifi-2018.4.16 howdoi-1.1.13

And only then I can use my version of howdoi.

The only catch is that every time I run the script, I will still re-install my version of howdoi, even if I already have it installed on the Linux instance.

Collecting https://github.com/tra38/howdoi/zipball/links
  Downloading https://github.com/tra38/howdoi/zipball/links

...

Installing collected packages: howdoi
  Found existing installation: howdoi 1.1.13
    Uninstalling howdoi-1.1.13:
      Successfully uninstalled howdoi-1.1.13
  Running setup.py install for howdoi ... done
Successfully installed howdoi-1.1.13

So I will have to wait longer to use my script. I think it’s a fair trade-off though. Eventually, once my changes get merged into master, I can give up my experimental version.

If you like to try out the experimental version of howdoi for yourself, you can click on this link.

I think this entire experience is another good illustration of the Generalized Peter Principle: “Anything that works will be used in progressively more challenging applications until it fails.” repl.it was very useful for me, so useful that I eventually encountered a serious problem with it.

I previously faced the Generalized Peter Principle before in A Real-World Example Of “Duck Typing” In Ruby, and vowed to be “more cautious and careful when programming” next time.

But maybe being “more cautious and careful” is not possible in the real world. When you encounter a useful tool, you get lulled into a false sense of security (because the tool worked so well before)…which eventually lead to you encountering a serious challenge. I’ll have to think of a better approach to dealing with the Generalized Peter Principle.

In July 2013, Shawn Warren released “A New Tender for the Higher Education Social Contract”, which discussed Shawn Warren’s philosophy concerning the current “status quo” of higher education and his alternative proposal of a “Professional Society”.

While I have heard of his ideas before while I was teaching at community college, I’m now seriously engaging with them. A company that I’ve been doing consulting work for, Gitcoin, wanted to start a “mentorship” program to allow programmers to teach other programmers. I thought that the PSA system might be able to provide some guidance to the program. So I decided to read Shawn Warren’s paper deeply and write some commentary.

The Argument

According to Shawn Warren, higher education is composed of a “triad” of actors:

• Finance (in charge of providing the funds to pay for the ‘service’ and keep higher education going)
• Service (in charge of providing the higher education ‘service’)
• Representation (in charge of representing the interests of ‘service’ providers)

This ‘triad’ worked…for a time…

• The role of “Finance” had traditionally been fulfilled by state and national governments. As long as governments keeps spending more and more money to keep the system functioning, all is well. But when governments implement austerity or reallocate resources to other sectors, higher education collapses. Higher education lives and dies on the whims of politicians.
• The role of “Service” had traditionally been fulfilled by institutions (colleges and universities), who are in charge of managing academia (the college instructors and researchers). But institutions, serving as middlepeople, have their own interests and desires that may be separate from that of the academia that they manage. As a result of this disconnect of interests, institutions fund services that are unrelated or semi-related to “higher education” (examples: sport franchises, administration, health and food services, recreation, alumni foundations). This drives up the costs of service, which needs to be paid for: either by governments or through tuition increases.
• The role of “Representation” is traditionally been fulfilled by unions, who represents the interests of academia in their arguments against institutions and governments. However, globalization, outsourcing, virtual classrooms, and MOOCs (Massively Open Online Classes) has generally weakened the roles of unions.

Students, perhaps considered one of the primary consumers of the ‘service’ of higher education, actually plays a limited role in this triad, and exists solely as a person who contracts the services of the middlepeople. The relationship between students and teachers are as follows:

• A teacher signs up with the institution.
• Students contacts the institution and requests for instruction.
• The institution connects the students with the teacher.
• Students pay tuition to the institution.
• The institution pays the teacher a salary.

Note that the institutions are not really necessary to establish the connection between the teacher and the student. We can eliminate the middlepeople altogether and change the relationship:

• A student wants to establish a direct relationship with a qualified teacher (“mentorship”, “tutoring”, “consulting”, etc.).
• Student finds a qualified teacher who is willing to provide a direct relationship.
• The student pays tuition to the teacher.

There is just one catch to this modified relationship, as Shawn Warren discussed:

Unlike professional proscriptions, under the triad social contract it is not illegal for a PhD in philosophy to refer to himself as an academic, hang a shingle outside the walls of an accredited institution and contribute to the higher education of society by offering expertise to the public for a fee.

It is just illegal to do so for credit, the one thing of market value and a pure social construct like professional licensure or institutional accreditation.

Even if the student has personally verified the teacher’s CV/resume, and even if the teacher is doing a good job, even if the student have learned something important…it all means nothing if there’s no certificate at the end to verify that you have done it to a prospective employer.

Higher education does not promise mere “knowledge” to students. It provides something more valuable - a piece of paper that easily demonstrates to employers that you have gained knowledge, making you more employable in the marketplace.

But who is best qualified to give out that piece of paper (credential)? According to the current triad model, it is the institution who gets the power of accreditation, and it uses that power to certify certain academics…giving them the power to teach courses that enable students to receive credentials.

But who are best qualified to decide who is an academic? Only other academics! As Shawn wrote:

1) all aspects of pedagogy, curriculum and evaluation can only be formulated by those experts that possess the relevant contributory knowledge

2) academics not only possess and ply this knowledge but generate it through research

This positions them to be at least among the best qualified to develop, approve and apply the accreditation and credential functions of higher education. …

This is as it should be given the subject is education, for which standards and regulation are necessarily a matter of consensus authority. That is to say any group of academics, including members of a new professional society, can form a regulatory service in accreditation and credential standards and approval. After all, legitimate opposition to such a group can only come from other expert academic opinion.

In other words, we can bypass the institution entirely, and instead place accreditation in the hands of a “professional society” that represents the consensus of academia. The professional society can decide who is best qualified to hand out credentials, by evaluating academics’ competence and teaching ability. The institution does not need to regulate academia - academia can self-regulate itself.

And thus, we have a new proposed triad of higher education - the PSA Model.

• Finance - the “students” of higher education will pay for the services of “higher education” directly to service providers.
• Service - academia will sell their ‘services’ directly to students, and compete against each other in a free market
• Representation - the Professional Society of Academics, in charge of representing service providers in their conflict between themselves and between students

The Professional Society of Academics (or PSA) can take charge of all the roles that the institution has previously been in charge of, while shedding the unnecessary services that do not directly relate to higher education. The removal of these “unnecessary services” could lead to immense cost savings…making higher education more affordable.

In addition, by removing the institution (the middlepeople) from the picture, the academics would be able to capture more of the “value” of the higher education services they provide. This can directly translate to higher pay (making academia a more rewarding career path).

So that’s the idea anyway.

(As an aside: Institutions would still play a valuable role in the PSA model though, but it would not be via accredition. Instead, institutions would sell valuable services to the students and academics, serving as a “vendor” to the system. For example, an institution could sell access to support staff and facilities to academics, enabling them to teach effectively.)

Criticism

There’s the implementation details that has to be taken into account:

• How do you create and organize the PSA?
• How do you get students to trust the PSA would provide proper oversight over instructors?
• How do you prevent the PSA from engaging in “mission drift”, slowly grabbing more power for themselves, and turning into yet another institution?

These questions are important and will take some time to answer.

But my main concern is whether the main role of the PSA (to provide accreditation) may even be necessary. As Shawn pointed out, learning can take place outside of any framework (the current triad or the PSA model). A certificate merely prove that you have learned it.

But people may not care about that proof. If there is no need for proof, then there is no need for a PSA…and academics can simply deal with students directly.

For example, when I signed up for Gitcoin’s mentorship program, Gitcoin never asked me for any certificate proving that I could actually “mentor” any of the programming subjects that I signed up for. It is assumed that I actually knew the stuff that I claimed to knew. It is expected that I wouldn’t lie, because prospective students can do background checks and interviews to make sure I’m not lying. If I say that I know C++, but I can’t answer basic questions about C++, students have the right to be suspicious.

In most of the professional world, it is also assumed that I know the stuff I claimed to know - I am expected to create my own resume to demonstrate my expertise, and most employers trust this resume as being a somewhat accurate indicator of my knowledge - only doing background checks and interviews to make sure I’m not lying on it.

Mere “knowledge”, of course, is not enough to secure a mentorship gig or get hired by a company - students and employers rely on additional information (samples of prior work, references, etc.) before making a decision. This additional information, of course, can also be provided by an academic setting. But this is separate from the credential.

Of course, there are places where you can expect people to demand proof of knowledge - such as the medical industry. In places where regulatory constraints or informal expectations require people to be certified by an external agency, I could see the PSA role serving as a viable alternative to traditional academia. However, for many other industries, where certification is not required, the PSA may not be necessary.

This appears to be the case in the industry I’m in - programming. There are many programmers who have received a Bachelor’s degree in Computer Science (and thus, has a formal credential in programming). But there are also other types of programmers:

• programmers who have “self-taught” themselves programming
• programmers who have received Bachelor’s degrees in other fields before transitioning to programming
• programmers who have attended bootcamps specifically designed to teach programming (but lacks formal accreditation)

The fact that these programmers are able to be gainfully employed, with or without a credential in programming, is telling.

Therefore, it is unlikely that the PSA model could work for Gitcoin’s mentorship program. I do think it’s a worthy model to explore though, and may be more applicable to other industries. I thank Shawn Warren for writing up an alternative approach to academia and for demonstrating a possible approach to reforming higher education.

There are a myraid of different sorting algorithms: quicksort, merge sort, radix sort, bubble sort, etc. There’s even a whole list of sorting algorithms on Wikipedia. But there’s one sort I like the most…bogosort.

Here’s the pseudocode of Bogosort:

1. Randomly shuffle the array
2. Check if the array is sorted
3. If the array is sorted, return the sorted array. Else, return to step 1.

Here’s an algorithm of Bogosort, written in Ruby and posted in Wikibooks.

class Array
  def bogosort!
    shuffle! until sorted?
  end

  def sorted?
    each_cons(2).all? { |a,b| a <= b }
  end
end

Now, in the worst-case scenario, Bogosort will take an infinite number of random shuffles before successfully sorting the algorithm. But in the best-case scenario, it can take a single shuffle. Even in a normal-case scenario, you can expect it to take a few shuffles before returning the right answer.

Bogosort is interesting to me because it is a nondeterministic algorithm, an algorithm that behaves differently based on the same input. According to Wikipedia:

In computer science, a nondeterministic algorithm is an algorithm that, even for the same input, can exhibit different behaviors on different runs, as opposed to a deterministic algorithm.

A nondeterministic algorithm can be very powerful, enabling us to approximate good solutions to problems that can’t be solved efficiently by purely deterministic algorithms (i.e, stochastic optimization). For example, nondeterministic algorithms can help deal with NP-complete problems such as the infamous “traveling salesman problem”. Rather than trying out all possible routes and selecting the best one, why not randomly pick a few routes and then check to see which one is the best?

In fact, the very term NP is an abbrevation of the term “nondeterministic polynominal”. Suppose we have a nondeterministic algorithm that is always “lucky” – for example, a bogosort that gets the array sorted after the first shuffle. Obviously, this algorithm would have a polynominal runtime. Hence the name – nondeterministic polynominal.

Of course, in the real world, we can’t just force an algorithm to always be “lucky”. Computer scientists have imagined the idea of a nondeterministic Turing machine that will always get “lucky”, but such machines are impossible to build and are only useful as a thought experiment…as a comparison to our less-lucky deterministic machines.

Using bogosort for an actual sorting problem is a bit silly, as there are already lots of deterministic sorting algorithms that are much more effective. But there are many, many problems where we cannot come up with efficent deterministic algorithms, such as the NP-Complete problems I mentioned. And so we break out the non-deterministic algorithms…and thank bogosort for the inspiration.

For additional information, I would highly recommend reading these two questions on CS.StackExchange: What is meant by “solvable by non deterministic algorithm in polynomial time”? and Bogo sort on NDTM. You may also want to look at this forum topic post on cplusplus.com - P vs NP for alternate ways of explaining the term ‘nondeterministic polynominal’.

And if you want to know of several nondeterministic algorithms that are used to solve real-world problems, please look at the Metaheuristic page on Wikipedia.

Capybara is a very useful tool for writing integration tests, but it can be very hard to get used to its DSL for interacting with forms. It is even worse when you don’t read the documentation for using the DSL, and instead only trust the source code of existing integration tests.

First, here’s a small cheat sheet for form interaction (for my personal use).

# Text Field or Text Area
fill_in 'Text Field', with: 'Lorem Ipsum'

# Select Field
select 'Lorem Ipsum', from: 'Select Field'
unselect 'Lorem Ipsum', from: 'Select Field'

# Checkbox
check 'Lorem Ipsum'
uncheck 'Lorem Ipsum'

# Radio Button
choose('Lorem Ipsum')

# File Upload
attach_file('File Upload', '/path/to/image.jpg')

Of course, while writing out this cheatsheet, I realized that it already existed in the main Capybara README documentation. I missed it though because I…er…didn’t read the README documentation before I started using Capybara.

The reason I didn’t read the documentation was that I thought it wasn’t really necessary. After all, I saw how other people used Capybara in the real world. And after seeing how other people wrote Capybara integration tests, I thought that all ways of filling data into forms required using fill_in…

#My imaginary understanding of the DSL

fill_in 'Text Field', with: 'Lorem Ipsum'
fill_in 'Select Field', with: 'Lorem Ipsum'
fill_in 'Checkbox', with: 'Lorem Ipsum'
fill_in 'Radio Button', with 'Lorem Ipsum'

# okay, I didn't quite know how I would imagine file upload to work...
# I assumed at least some variant of fill_in

I guess I imagined that there was a lot of magic involved with fill_in, and all I have to do is to specify the proper text label and Capybara will handle the rest. That was of course wrong…and I realized I was wrong ~4 hours after trying to coerce “fill_in” to handle a Select Field. (To make matters worse, I slowly began to realize my assumptions were wrong after reading the API documentation for two hours.)

The reason that I thought that “fill_in” was this magic, all-purpose method was that all the integration tests that I read that used Capybara interacted with forms that only had text fields. Their code worked perfectly, so I just made a simple assumption that the logic would transfer over elsewhere to other form fields. That assumption was wrong.

So I learned two lessons: (A) Even when you’re learning how an API works from working code, it may still be useful to look at the documentation anyway. Working code may be dependent on certain quirks that has very little to do with the language itself…and you may not be aware what those quirks are, except in retrospect. (B) When you’re reading the documentation, make sure to look at the README first and then, if the README doesn’t help, only then look at the API Documentation. While both forms of documentation would eventually teach me the correct DSL syntax, the README documentation is much more accessible (probably because more people are going to see it) while the API Documentation can be very technical and can miss sight of the bigger picture. To truly understand the lower-level API Documentation, you need to first understand the higher-level README documentation.

In December 2016, Ben Halpren and I got in a discussion over the future of publishing.

Ben Halpren - I feel the publishing industry has created a model where they try to extract maximum value out of their human bloggers and treat them like assembly-line workers. There’s not a lot of value in “aggregating” stories. It’s just publishers trying to eek out a slice of the pie. A lot of this work will certainly be automated in the future.

I feel like the quantity over quality model that Internet publishers have fallen into is flawed for the business and the consumer because there is so much replicated work and it does not take advantage of economies of scale very well. In the future, there may be fewer overall writing jobs, but they will leverage human creativity much more than the current landscape.

Before the content-farming blog jobs totally go away, they will trend in the direction of editorial oversight into a more automated process. This part will probably vanish eventually as well.

Tariq Ali - I agree completely that the current ecosystem is perverse and unsustainable. To add a bit more content to this comment though, you would probably be very interested in the Content Shock hypothesis, which argues that the users’ demand for more content will ultimately halt (meaning that incumbents who are ‘first to market’ with content ends up dominating, while new contenders who are trying to push out content gets ignored). In November 2015, the author claimed that content shock has arrived. Surprisingly, the author believe that one way for marketers to handle “Content Shock” is to mass-produce content, thereby drowning out the competitors, and believe that this mass-production will likely be done by computers.

If this content ecosystem does collapse, then the amount of text generation (human or automated) will probably decrease. It’s an open question whether the humans that remain in that line decide to embrace automation (and use the content wreckage as corpus) or to shun it.

The current “quantity over quality model” that exists within content generation exist primarly due to Google’s algorithms favoring more content:

While one high-quality article might drive a thousand shares, 10 articles that drive 120 shares each is more. Replace shares with traffic or conversions. It’s the same concept. In this way, Google is actually encouraging us to commoditize our content in lieu of creating great content, whether it’s purposeful or not.

Or, to put it more plainly:

Winning in digital media now boils down to a simple equation: figure out a way to produce the most content at as low a cost as possible.

This does not sound sustainable, to me or to Ben. The only reason consumers haven’t yet given up on the Internet though is our reliance on various curators (human aggregation, search engine bots, machine learning recommendation systems, etc.) to tell us what content to consume. But what about content producers? What happen to them if they are unable to produce enough content that appeals to the curators? It seems that they have to shut down. And when they do, the content ecosystem would implode.

There is, of course, an alternative viewpoint that contrasts with both Ben’s and mine’s, one that argues that the content ecosystem is sustainable, that Content Shock is no problem at all, and that far from the ecosystem collapsing, is bound to explode and proliferate.

This viewpoint argues that major content publishers will learn how to take advantage of “economies of scale” by reusing existing works. Content publishers will also learn how to ‘personalize’ content to match the whims and desires of the people who are reading it, thereby keeping them engaged. The content ecosystem will adapt, and the process of adaptation would lead to a new ‘golden age’ of human creativity.

That viewpoint is best expressed by the short story “The Discovery Engine”.

“The Discovery Engine, (or, Algorithms Everywhere and Nowhere)” is one of two short stories written by Professor Christopher Ketly in the peer-reviewed article Two Fables. This short story imagines a world where the “myth of the Romantic Author” died. As a result, the US government reformed intellectual property laws, allowing for major corporations to remix and reuse content in brand new ways.

[A]fter all the big media companies had figured out how to Spotify everything, there was not much reason to hemorrhage money into controlling media, when the game was to extract value in other ways: discovering, sorting, searching, repackaging, and repurposing. Copyright enforcement fell away; with everything open, or so multiply licensed it was impossible to track, it became clear that real, new growth was in repackaging and reselling information rather than investing in the creation of new information. New information had margins way too low to invest in anymore, even if novelty still drove the market more than ever. Something about the old argument that supporters of copyright terms used to make—that copyright was an incentive for people to create—no longer seemed to even make sense. Innovation certainly had not died, nor had the music.

Innovations included, but were not limited to:

• Repackaging public domain and ‘orphan works’ for modern-day audiences, through clever marketing techniques (Example: “Who in their right mind would sit through an entire Cassavetes movie when it was possible to watch it unfold as the crazy mashed-up backstory of an X-Men film?”)
• Using English-to-English machine-translation algorithms to change the readability of texts to match a user’s desires
• Personalizing manuscripts to tailor to an individual’s personal biases and beliefs (for example, renaming characters and locations)…but not too much, because you still want people to discuss with each other about the same reading experience(s)
• Programatically adding ‘dark patterns’ to books as people read them (such as cliffhangers, targeted marketing emails, and “literary versions of clickbait”)….with the expressed purpose of encouraging people to keeping reading
• Reusing exisiting assets to generate new versions of the same story to be resold at different times (similar to the concept of reusable compontents in programming)
• Increasing discoverability of existing literature so that people can wind up finding assets that can be reused
• …or skipping the discovery process and using RNNs to just generate the stories outright

Human creativity has been leveraged, and probably even expanded, in this dystopian future. Instead of tediously trying to come up with new words to express what has already been expressed better before, you can simply reuse what already exist and then tweak it to match your specifications. Creativity simply moves to a higher level of abstraction, similar to how programmers move from low-level languages (like Assembly) to higher-level languages (like COBOL). ‘DRYness’ has been applied to literature.

And there’s no sign of technological unemployment. Instead, the content economy is itching to hire more people…

• “Cool hunters” find the works to be repackaged and repurposed
• “Lit geeks” identify current fads and trends in literature, enabling corporations to tailor their generated books to a mass audience
• Privacy violators spy on people and gather data about their reading habits
• Data scientists analyze the data and design the algorithms necessary to generate the stories
• And, of course, marketers develop the initial ad campaigns to acquire potential readers

However, writers are nowhere to be found in this golden age of human creativity except in an aside describing the creation of a new TV series (“The Game of Thrones reboot”):

Writers were employed by the system to check these texts, but not to write them, just to tweak and improve them, insert clever jokes and Easter eggs, to look for the giveaways that the algorithms could not spot.

I find “The Discovery Engine” to be (a) a pleasant read and (b) a plausible prediction for the fate of all content generation (both human-made and machine-made). I do quibble with two of the author’s points though.

First, while RNNs certainly have their place as part of a “toolkit” in text generation, I highly doubt that they have the potential to generate coherent stories by themselves. I could imagine a world where RNNs generate hundreds of different stories and then a secondary algorithm filters through the resulting junk to find one or two stories that may be worthwhile. Even in this imaginary state though, I’d still see a fleet of data scientists behind the scenes, trying their best to massage the data and the algorithms to produce the best possible outcome.

The second point I quibble with is more philosophical. One subplot in this sci-fi story involved society’s reaction to multiple versions of the same public domain work being published by major corporations, leading to a reactionary (and doomed) impulse by a few scholars to recover and preserve the “original” works.

But in the real world, I don’t think anybody would care. After all, the story of Cinderella has been rewritten countless times, with different versions personalized to different regions of the world. And we can sensibly discuss about the different versions of Cinderella (for example: arguing whether The Brothers Grimm’s version is superior to Walt Disney’s version) without getting ourselves confused. Ideas has always been cheap; it’s the execution of those ideas that matters.

The New Work departments in the publishers and movie studios were eventually dwarfed by the Repurposing departments; it became increasingly impossible to sell a book or script just because no one had ever written something like it before. It turned out, actually, that this was always false, and it was far easier and cheaper to update Trollope than to pay Franzen for his novel on the same topic.

“Middleman is a static site generator using all the shortcuts and tools in modern web development.”—Middleman Home Page

One of those shortcuts is having a directory structure to help organize your project. Here’s a short version of that directory structure (a more complete version is located in the docs).

mymiddlemansite/
-- .gitignore
-- Gemfile
-- Gemfile.lock
-- config.rb
-- source (all the files necessary for building the static site)
-- build (the generated static site files)

The idea is that you would write all your code in the source directory, type in bundle exec middleman build to generate your build directory, and then ship this build directory elsewhere to be served by a web server. Most likely, you would use a tool such as middleman-deploy or middleman-gh-pages to automate the deployment process. Both of these tools are able to natively support deploying to GitHub Pages, usually by pushing up the build directory to the gh-pages branch of a GitHub repository.

But what if you don’t want to use those tools to deploy to a separate branch of your repository? What if you wanted your website files to be in the same branch as your Middleman source code, for maintainability and aesthetic reasons? GitHub Pages luckily gives you that option…though in a rather indirect and hacky fashion.

In the settings of your GitHub repository, you tell GitHub Pages to read from either the gh-pages branch, the master branch, or the /docs folder.

The last option is incredibly useful for open-source projects who wants a specific /docs folder to store all their documentation files for their projects. For example, the Classifier-Reborn open source project has a GitHub Page, and its source code is stored within the /docs folder.

So we’re going to abuse this feature to deploy our own Middleman site. First, we need to select the master branch /docs folder option in the settings of our repo. Second, we need to rename /build to /docs. This can be done by editing config.rb to change the build directory’s name.

configure :build do
  set :build_dir, 'docs'

Finally, we just type out…

bundle exec middleman build

…commit the resulting build folder to our repository, and then push the result up to our GitHub repository.

There is still one tiny flaw though. Any time you need to make a change, you must rebuild the /docs directory and commit the generated files. I leave it to the reader to decide how to best automate this process (probably by writing out a Raketask).

Note - This article was originally published on dev.to on April 29th 2017, and has since ported over here.

“Duck-typing” is a very useful tool in Ruby. But sometimes, tools break. Every tool is useful, until the day the tool stops being useful, and it’s time to do some debugging…

def get_first_element(object)
    object[0]
end

Here, I defined a Ruby method that will take any arbitrary object and call the [] method on it.

Now, normally you call the [] method on an array, so this method tends to work as expected with arrays.

array = [1,2,3]
get_first_element(array)
#=>1

But it doesn’t just handle arrays. In fact, it handles any arbitrary object that responds to the [] method.

string = "Alphabet"
get_first_element(string)
#=>"A"

As long as the object responds to the [] method, that’s good enough for me. And that is the basis of duck typing. It is based on the principle that if an element ‘quacks like a duck’, it is therefore a duck. If it quacks like an array, it is an array. And if I pass in an object that doesn’t support the [] method, we’d simply see an error raised, like so…

awesome_object = Object.new
get_first_element(awesome_object)
#=>NoMethodError: undefined method `[]' for #<Object:0x007f9a93135b70>

The error message is probably most helpful for the programmer who has access to the source code of get_first_element, but at least the program halted at execution.

And that’s all I have for now. I’ll leave you with these cool code snippets of me getting the first element of integers. Happy coding.

integer = 1
get_first_element(integer)
#=>1

Uh…

get_first_element(2)
#=>0

get_first_element(30)
#=>0

Cancel the happy coding.

Integers in Ruby also respond the [] method. According to the docs, integers appear to have a binary representation “under the hood”, and the [] method gets me the nth digit of that binary representation. The docs give a pretty good example of what’s going on…

#Define a as the integer 13098, by using its binary representation
a = 0b11001100101010

#Retrieve that same binary representation by using []
30.downto(0) { |n| print a[n] }
#=> 0000000000000000011001100101010

After all, all numbers must have a binary representation, and that binary representation has to be stored somewhere, and you might as well treat that stored binary representation as an array. It sounds like completely expected behavior so long as you know to expect it in advance.

The duck has quacked, and so we assume it to be a duck. And it is a duck…don’t get me wrong. Just a duck that I was unfamiliar with.

Coincidentally, I actually used get_first_element in a personal side-project. I stayed up all night trying to track down weird bugs that occurred when I was passing integers into get_first_element. Once I realized what was causing this, I added a quick hotfix to solve the issue…

def get_first_element(object)
    string = object.to_s
    string[0]
end

Call the object’s to_s method, thereby creating a string representation of the object. Then, simply access the first element of that string. This meant that get_first_element handled integers as I wanted them to…

get_first_element(1)
#=>"1"

get_first_element(2)
#=>"2"

get_first_element(30)
#=>"3"

…but now users will be surprised at how the method handles arrays.

[1,2,3].to_s
#=>"[1,2,3]"

get_first_element([1,2,3])
#=>"["

And objects that would previously raise an error under the old get_first_element would now produce a “valid” result under the new get_first_element, if the objects are able to “quack” (respond to the to_s method)…

awesome_object = Object.new

awesome_object.to_s
#=> "#<Object:0x007f9a9314f3e0>"

get_first_element(awesome_object)
#=>"#"

Luckily for me, the personal side-project only dealt with strings and integers. If my side-project ever had to support arrays or other arbitrary objects though (which is always a possibility, considering how often software changes), I would probably consider:

• Writing a lot of ugly and overly-complex code to get get_first_element to behave as I intended it to (formalizing my beliefs about how the method is “supposed” to work through automated tests).
• Writing documentation explaining and justifying all the quirks. Saying, “This is how it works, deal with it” just won’t fly.
• Eliminating get_first_element entirely and rewriting the side-project.

I dread having to take any of these approaches. If forced to choose though, I would pick “rewriting the side-project”. My side-project was using get_first_element to do some rather “hacky” stuff, and there’s probably a much better (and less painful) way to do that same stuff. All I have to do is find it…and then implement it.

This post is not an attack against duck-typing, although my reliance on duck-typing did lead to this error. Duck-typing is part of idiomatic Ruby, and taking advantage of it tends to lead to “cleaner” code. But there are always trade-offs to consider, such as the ducks doing behaviors that you didn’t intend them to simply because the ducks knew how to quack. But I never even experienced these trade-offs – until now.

This blog post was really an illustration of the Generalized Peter Principle: “Anything that works will be used in progressively more challenging applications until it fails.” Generally, this principle is usually applied to human beings – “Workers rise to their level of incompetence.” Duck-typing is useful, and it is precisely that it was so useful that it led me to spend the whole night debugging an issue caused by my use of duck-typing.

I’m still going to use duck-typing. It’s just too useful and convenient, and the odds of me encountering this issue in another Ruby side-project seems fairly low.

But I’m going to be more cautious and careful when programming. More importantly, I plan to be more comfortable with my ignorance…never assuming that I know more than I actually do about the program I am writing, the patterns that I am using when writing the program, the language I am writing the program in, and the requirements that I am writing the program for.

Being comfortable with ignorance means that I might be able to anticipate and prepare for situations where the Generalized Peter Principle comes true and my tools break hard.

Note - This article was originally published on dev.to on Feb. 21st 2017, and has since ported over here.

According to a 2015 report by Incapsula, 48.5% of all web traffic are by bots. If you are running a small website (10 to 1000 visits per day), 85.4% of your web traffic are by bots. Even if you happen to run a very large website (100,000 to 1 million visits per day), 39.7% of your web traffic are by bots.

Put it frankly, most of your audience are composed of robots. (I’ve learned this the hard way when I was maintaining a website for a Texan religious organization and found out from Google Analytics that 90% of people visiting the site were from Russia.)

A minority of bots are “good bots” - crawlers and web scanner tools. Their goal is to visit websites and provide valuable information to another user. Search engines aggregating results based on keywords, chatbots looking to answer users’ natural language queries, etc. Googlebot is a prime example of a “good bot” (and is actually pictured in the header of this blog post holding flowers).

The majority of bots are “bad bots” - scrapers that are harvesting emails and looking for content to steal, DDoS bots, hacking tools that are scanning websites for security vulnerabilities, spammers trying to sell the latest diet pill, ad bots that are clicking on your advertisements, etc. (Okay, the ad bots are probably “good” from the perspective of the blogger with ads, but they’re still pretty bad for the companies paying for the ads.)

I have delivered a speech about bots in June 2016 - here’s the slides for it. But I am writing this blog post as a response to Untold Benefits of a Software Blog. The arguments in that blog post are correct. But any discussion of blogging must take into account the audience of that blog. And that audience for most websites will be machines. Here’s the problems that bots can cause:

Your Metrics Are Unreliable - You can hire a botnet to visit your website, scroll up and down the page, execute JavaScript to trigger your analytics software, click on ads and other links, write comments about your blog post, like your blog posts, retweet your blog posts, etc., etc. Even if you don’t want to fake your metrics to boost your vanity, bots may still behave as normal users to avoid detection by other algorithms. This may mean that they will visit multiple “innocent” sites (including yours) before heading over to their final destination. Bad analytics make it difficult to target your content properly, since how else would you know if your content is actually working on human beings?

You Are Writing For the Machine - There is just so much content on the Internet that humans are unable to consume it all. So they rely on aggregators and filters. But content producers then realize that they shouldn’t write high-quality content. That is useless because nobody will discover high-quality content without the help of aggregators and filters. Instead, content producers should write content that appeals to aggregators and filters. This is the ultimate premise behind SEO (search engine optimization), and the end conclusion is people writing articles with long-tail keywords to secure visits from search engines. SEO is the natural consequence of Goodhart’s Law (“When a measure becomes a target, it ceases to be a good measure”). Search engines’ dependence on links to determine whether websites are popular or not led to the rise of “link farms”. Google was also responsible for the rise and fall of content farms such as eHow - Google’s algorithms once prized such “fresh content”, only to later changed their minds with the “Panda” updates. Even today, Google encourages “quantity over quality” in content generation:

While one high-quality article might drive a thousand shares, 10 articles that drive 120 shares each is more. Replace shares with traffic or conversions. It’s the same concept. In this way, Google is actually encouraging us to commoditize our content in lieu of creating great content, whether it’s purposeful or not.

This perverse trend is ultimately unsustainable, but it may still continue for a while longer. Marketers are already discussing how the Washington Post is able to quickly generate more content by using algorithms, and how incumbents could drown out competition from upstarts by mass-producing low-quality content.

Your Content Will Be Divorced From You - Content on websites such as dev.to are reposted elsewhere, word-for-word, by scrapers programmed by Black Hat SEO specialists. These specialists hope to populate their websites with cheap content…and what could be more cheap than copying and pasting? If you’re lucky, they’re willing to give you a backlink as a meaningless “thank-you note” for providing the content that they so desperately need. Most of the time, they won’t bother. Even “legitimate” actors such as Google are getting into the business of taking your content and reusing it, through the use of featured snippets.

However, a new breed of scrapers exist - intelligent scrapers. They can search websites for sentences containing certain keywords, and then rewrite those sentences using “article spinning” techniques. As much as I find it distasteful to link to Black SEO sites, here is a YouTube demonstration for Kontent Machine 3, one of these intelligent scrapers (so you can observe how it works). The output is decent enough to please a search engine algorithm, but still need work before humans could also enjoy the output. (Disclaimer: I am working on ‘content aggregation’ software that can take paragraphs from an external CSV file and then rearrange them into unique articles. I am still thinking of a good way to open-source it without helping intelligent scrapers.)

I think it is likely that as text generation techniques get better and as AI becomes more advanced, people will begin recycling content…downplaying or even eliminating the content creator from the picture. The machine curator is praised while the human content creator is devalued or ignored.

I gave a more positive spin of this trend in the article Who are the Audiences of Computer-Generated Novels?, in the section entitled “People Who Want To Consume A Existing Corpus”. After all, there’s just so much data out there that we do need algorithms to make sense of it all, and the curator does deserve some “credit” for its role in bringing order from chaos. And these algorithms are exciting. But exciting algorithms also carry negative consequences as well – consequence that we have to be aware of and prepare for.

Imagine a chatbot that resides in your terminal. You can ask this chatbot a coding question, without ever going to StackOverflow and seeing a person’s name or (shudder) avatar:

#> howdoi python for loop
#=>
#for idx, val in enumerate(ints):
#    print(idx, val)

That world already exist. It’s called howdoi, a open-source command-line tool. Of course, it’s not perfect (neither is StackOverflow), but what surprised me the most about howdoi is that it can do qualitative answers as well:

#>howdoi evolutionary algorithm
#>The pro: Evolutionary algorithms (EAs), as genetic algorithms (GAs), are general
# purpose optimization algorithms that can be applied to any problem for which you
# can define a fitness function. They have been applied to nearly all conceivable
# optimization problems, see e.g. the conference series on „Parallel Problem
# Solving from Nature“. The con: EAs are generally much slower than any specific
# optimization algorithm adapted to the problem. I would apply them only if all
# standard optimization algorithms fail.

#>howdoi solve the halting problem
#>The normal approach is to constrain program behavior to an effectively calculable
#> algorithm.  For example, the simply typed lambda calculus can be used to
#> determine that an algorithm always halts.  This means that the simply typed
#> lambda calculus is not Turing complete, but it is still powerful enough to
#> represent many interesting algorithms.

Humans wrote this content. But humans are being denied credit for their effort, as it is the algorithm (“howdoi”) that is curating this content and showing it to the end user. Note the lack of backlinks in the outputs of “howdoi” as well, meaning “howdoi” is technically engaging in plagiarism. “howdoi” is the future, and the future doesn’t look good for human content generators.

Conclusion: I am not necessarily saying “Don’t bother writing blog posts because the only people who are going to read them are bots”. There are good reasons to write a blog post. Just know that humans are not your primary audience for these posts. If you treat blogs mostly as vehicles of self-expression and communication with other people within a niche, then you’ll go far. If you treat blogs as a ticket to gaining fame with other human beings though, you’re probably going to fail hard.

Correction:

• While it is true that howdoi is currently engaging in plagiarism, the developers are aware of this and a PR have been opened up to fix this issue.

Note - This article was originally published on dev.to on Jan. 7th 2016, and has since ported over here.

Today, many developers feel the need to express their non-technical political opinions online…in a wide variety of different, public forums (Twitter, Facebook, blog posts, comments on blog posts, etc). I can understand why people may feel the need to express their own views to random strangers on the Internet. After all, politics is an important aspect of a civil society, and it is essential to understand how a country is run. I, myself, have posted Tweets about non-technical issues (mostly condemning the growing national debt, the polarization of American society and the rise of extremist politics), and may have posted comments on popular blogs using dubious pseudonyms.

However, this tendency to “speak your mind to random strangers on the Internet” as being very…problematic. While some of these strangers are automated bots just crawling for text, many of these strangers are real, live human beings. These human beings may:

• Disagree with me entirely because it does not fit within their own preconceived biases
• Agree with me entirely because it fits within their own preconceived biases
• Reinterpret my opinion so that it acts to reinforce their own preconceived biases
• Agree with me on most of my opinion, but disagrees with a minor aspect of the opinion that actually undermines my whole argument
• Agree with my opinion until they actually read my terrible arguments in favor of it, believe that the opinion itself must be stupid, and then change their opinion
• Not actually care because they’re just wasting time on the Internet
• Etc.

And these human beings may have different motives for even finding my article. They may:

• Have an opinion and want to hear someone else say it in a different manner
• Have an opinion and want to hear flawed arguments against it to make their own opinion look smarter
• Have an opinion and only want to “know the enemy” by reading an argument against it
• Want to read something funny to pass the time
• Actually want to learn about an issue (very unlikely, I admit)
• Etc.

There’s a lot that can go wrong when conveying information online to random strangers, and it is very hard to get feedback from these users on why they are reading my opinion and whether I successfully expressed the opinion correctly. As a result, it is very easy for you to make a mistake when expressing your political opinion, and to do lasting damage as a result of your carelessness.

And while having a political opinion is good, expressing it does seems to require a little more deftness that I don’t really know I have. If you argue a cause incorrectly, then you might end up damaging your cause (instead of helping it). If you are preaching to an echo chamber, you’re really just wasting your time. If your opinion is uninformed (or worse, just utterly wrong), then you’re causing real damage to society.

So if you have no feedback on the success of your writing, and no confidence that what you’re saying is even right…why bother speaking in public? Self-censorship seems more justified to me in this case (and sharing political opinions should be done in the semi-privacy of one’s own home or job).

In addition, as a developer, I build tools that can ideally be used by any random stranger…including by those who disagree with me. And I find that pretty odd. The tools that I build are probably much more impactful than the opinions I utter on the Internet…and in fact, can be used to undermine my opinions entirely. Consider this hypothetical example:

1. I hate spam. I write excellent blog posts against spam, how to identify spam, what can be done to filter out spam, etc., etc., and they receive rave reviews from other people who read it.
2. Concidentially, I am a contributor to Calyx - “[a] Ruby library for generating text with declarative recursive grammars”.
3. Spammers download Calyx and uses it to generate unique spam emails.

Since I built the program that allowed people to send spam, does it really matter how many blog posts I written against spam? Yes, I didn’t intend for the program to be used in that fashion, but intent doesn’t really matter, does it? I share some responsibility for building the tool. I was indirectly responsible for the spam. And it means that my arguments against spam were unintentionally stupid.

This is not much of a problem if I decide to only work on proprietary projects that I have previously vetted as fitting my political opinions, but that would seem fairly limiting. Most proprietary projects today are dependent on “open source” programs, and it is generally accepted convention to ‘contribute back’ to the open source community.

“Open source”, that great buzzword of tech enthusiasts everwhere, spurn any limitations on how you use technology. Freedom 0 of FSF’s Four Freedoms is:

The freedom to run the program as you wish, for any purpose.

And the Open Source Definition has Clause 6, “No Discrimination Against Fields of Endeavor”:

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

The JSON License is considered a non-“open source” license simply because it demands “The Software shall be used for Good, not Evil.” It is a rather toothless and unenforcable limitation, because anyone can define what they are doing is as “Good, not Evil”, yet the fact that it even bothers to sugget that software should be used ethically has led to many arguments. Many programs must be rewritten so that they could then be relicensed to a ‘proper’ open source license.

I’m not saying that “open source” is bad. I’m just saying that it’s very absurd to publicly advocate for a policy position, and that the same time, gleefully create software for people who will use it against your policy position. I should either stop contributing to open source, or stop speaking. I chose the latter.

Therefore, I impose upon myself an indefinite moratorium on posting political opinions on non-technical issues in public settings (especially on Twitter and my personal blog). If I am to speak about non-technical issues within a public setting, I must first lift this moratorium – and explain why I feel the pressing need to do so, knowing that “speaking out” has a high chance of backfiring and that I am unable to control the users of the open-source projects that I contribute to.

Now, I am only limiting myself to commenting on non-technical issues. I can still write technical opinions on major issues such as “tabs versus spaces”, how to define clean code, the proper role of automation in society, etc. These technical opinions are probably just as heated an passionate as political opinions, but seem qualitatively different because they focus less on what you should do and more on how you should do it.

There’s less of a need to worry about convenying information wrongly to strangers. Most of the time, technical arguments tend to have objective answers, and it’s very easy to check if they are correct or not. Even on issues where subjectivity exists, there’s usually wide areas of agreement between content creators…and you can usually synthesize together your own truth about technology. Technical arguments have (so far) avoided the polarization that had infected most of American society, and so it is much easier to divorce feeling and emotion from the technical arguments being made (although it is still very difficult).

Worries about people using my works for goals I dislike has also been reduced: I may hate spammers, but I would also want them to perform their job effectively and ensure that their codebase is maintainable. It is reasonable to want people to succeed at their task while at the same time disliking the fact that they are doing the task in the first place.

The Internet is a revolutionary technology that enables communication with a wide variety of people…even people that I will never know or meet. These random strangers, the “silent majority”, that consumes the work that I produce (software and words), matters to a rather unhealthy degree. Perhaps, in the good old days, when it was hard to communicate your ideas to others, could you afford to take a strong moral stand without fear of your words backfiring or your actions hypocritically underming your moral stand. Today, we don’t have that luxury.

Technology is ruthlessly amoral. It is the humans that decide how to deal with it.

Recently, the term “Human-Machine Collabaration” has came in the vogue, to describe a sort of alliance between mankind and their tools to accomplish a specific purpose. There has been much talk about the potentials of such collabaration. There has been less talk about its dangers.

Creativity has always been a collaborative act. We can now increasingly count machines as members of our team as well.—The Coming Human-Machine Partnership in Creativity

The debate between advocates of artificial intelligence (AI) and defenders of human-centric approaches presents a false dichotomy. Machines can certainly help solve the problems facing humans, but they can rarely do so alone. To be most effective, machines must learn from people and about people. Creating and implementing accurate AI systems requires the input of human knowledge. —How human-machine collaboration has automated the data catalog

We will train machines that continue learning through interacting with other humans in different environments. In turn, the machines will train us on how to train them to get the best value out of human-machine collaboration.—Human-Machine Collaboration

At Tamr, “Machine Driven, Human Guided” goes well beyond a pithy tagline [not that we have anything against pith]. It’s our founding philosophy, the idea that humans and machines should not just collaborate, but iterate on problems that can’t be solved manually or through automation alone. In other words, algorithms v. humans is not an either-or decision. “Together” is possible, with the proper technology and process.—Tamr’s Take … On Human-Machine Collaboration

In a sense, a math model is the equivalent of a metaphor, a descriptive simplification. It usefully distills, but it also somewhat distorts. So at times, a human helper can provide that dose of nuanced data that escapes the algorithmic automaton. “Often, the two can be way better than the algorithm alone,” Mr. King said.—If Algorithms Know All, How Much Should Humans Help?

Player Piano is Kurt Vonguett Jr.’s first novel, about a dystopian United States government. It wasn’t a good novel to read, especially when compared to his later novels. The book’s text has not aged well, with its racism and sexism rather distracting. But the book’s ideas are still relevant to the modern day. I once had a plan to write a hard science-fiction novel about the dangers of uncontrolled technological progress without societial regulation, but such a novel would have just been a poorly-written, politically-correct version of Player Piano.

But Player Piano’s dystopian society also involved a darker, more pessimistic view of “human-machine collaboration” as well. This view is presented in the form of the supercomputer EPICAC XIV.

“This is EPICAC XIV,” said Halyard. “It’s an electronic computing machine - a brain, if you like. This chamber alone, the smallest of the thirty-one used, contains enough wire to reach from here to the moon four times. There are more vacuum tubes in the entire instrument than there were vacuum tubes in the State of New York before World War II.”

EPICAC XIV is a Narrow AI. It is narrowly designed to handle a specific task - resource allocation in the United States. You would not ask EPICAC XIV to write a poem, to bake a cake, or to drive a car. And yet…

EPICAC XIV, though undedicated, was already at work, deciding how many refrigerators, how many lamps, how many turbine-generators, how many hub caps, how many dinner plates, how many door knobs, how many rubber heels, how many television sets, how many pinochle decks - how many everything America and her customers could have and how much they would cost. And it was EPICAC XIV who would decide for the coming years how many engineers and managers and research men and civil servants, and of what skills, would be needed in order to deliver the goods; and what I.Q. and aptitude levels would separate the useful men from the useless ones, and how many Reconstruction and Reclamation Corps men and how many soldiers could be supported at what pay level and where, and . . .

EPICAC XIV is not Skynet. It still requires human lackies. Humans has to gather the Big Data that EPICAC XIV uses for its calcuations, and humans has to carry out EPICAC XIV’s recommendations. So…why exactly do you need to use EPICAC XIV as a middleman? Why not just use humans to perform the calculations? Because humans are just plain inferior to EPICAC’s genius.

Given the facts by human beings, the war-born EPICAC series had offered the highly informed guidance that the reasonable, truth-loving, brilliant, and highly trained core of American genius could have delivered had they had inspired leadership, boundless resources, and two thousand years.

… EPICAC XIV could consider simultaneously hundreds or even thousands of sides of a question utterly fairly, that EPICAC XIV was wholly free of reason - muddying emotions, that EPICAC XIV never forgot anything - that, in short, EPICAC XIV was dead right about everything.

There is an argument to be made that EPICAC XIV is engaging in “human-machine collaboration”. After all, it is the humans that built EPICAC XIV, curate the data that is then given to EPICAC XIV, and carried out EPICAC XIV’s recommendations. But this is not an equal collaboration, as this dialog between Paul and Katharine demonstrates.

As Paul passed Katharine Finch’s desk on his way into his office, she held out his typewritten speech. “That’s very good, what you said about the Second Industrial Revolution,” she said.

“Old, old stuff.”

“It seemed very fresh to me - I mean that part where you say how the First Industrial Revolution devalued muscle work, then the second one devalued routine mental work. I was fascinated.”

…

“Do you suppose there’ll be a Third Industrial Revolution?”

Paul paused in his office doorway. “A third one? What would that be like?”

“I don’t know exactly. The first and second ones must have been sort of inconceivable at one time.”

“To the people who were going to be replaced by machines, maybe. A third one, eh? In a way, I guess the third one’s been going on for some time, if you mean thinking machines. That would be the third revolution, I guess - machines that devaluate human thinking. Some of the big computers like EPICAC do that all right, in specialized fields.”

“Uh-huh,” said Katharine thoughtfully. She rattled a pencil between her teeth. “First the muscle work, then the routine work, then, maybe, the real brainwork.”

“I hope I’m not around long enough to see that final step. …”

EPICAC XIV is handling all of the “brainwork” in thinking about the problem of resource allocation, leaving the humans to worry about the menial tasks necessary to keep EPICAC XIV running. Collaboration matters, but the human involvement in this collaboration is token and marginal at best.

And, as a result, humanity suffers from an inferiority complex, even going so far as to trust implicitly the machine’s choices…

President Lynn was explaining what EPICAC XIV would do for the millions of plain folks, and Khashdrahr was translating for the Shah. Lynn declared that EPICAC XIV was, in effect, the greatest individual in history, that the wisest man that had ever lived was to EPICAC XIV as a worm was to that wisest man.

For the first time the Shah of Bratpuhr seemed really impressed, even startled. He hadn’t thought much of EPICAC XIV’s physical size, but the comparison of the worm and the wise man struck home. He looked about himself apprehensively, as though the tubes and meters on all sides were watching every move.

And so, the Shah of Bratphur decides to test the machine’s capabilities, by asking a question…

The Shah turned to a glowing bank of EPICAC’s tubes and cried in a piping singsong voice:

Allakahi baku billa,

Moumi a fella nam;

Serani assu tilla,

Touri serin a sam.”

“The crazy bastard’s talking to the machine,” whispered Lynn.

“Ssssh!” said Halyard, strangely moved by the scene.

“Siki?” cried the Shah. He cocked his head, listening. “Siki?” The word echoed and died - lonely, lost.

“Mmmmmm,” said EPICAC softly. “Dit, dit. Mmmmm. Dit.”

The Shah sighed and stood, and shook his head sadly, terribly let down. “Nibo,” he murmured. “Nibo.”

“What’s he say?” said the President.

“‘Nibo’ - ‘nothing.’ He asked the machine a question, and the machine didn’t answer,” said Halyard. “Nibo.”

“Nuttiest thing I ever heard of,” said the President. “You have to punch out the questions on that thingamajig, and the answers come out on tape from the whatchamacallits. You can’t just talk to it.” A doubt crossed his fine face. “I mean, you can’t, can you?”

“No sir,” said the chief engineer of the project. “As you say, not without the thingamajigs and whatchamacallits.”

It is almost irrelevant what question the Shah actually asked[1]. The problem here is that EPICAC XIV couldn’t handle artibrary input. That’s perfectly fine, because it wasn’t designed to handle that input. It was, after all, built by fallible human beings (who didn’t even anticipate that such input could be given).

But the fact that flawed humans built EPICAC meant that EPICAC itself is not perfect, and therefore flawed. Which again, is perfectly fine. It was built to handle the problem of resource allocation…answering riddles from Shah is just not suited for its talents. You don’t judge a fish by how fast it can climb trees.

The problem is with the humans. They praised EPICAC as the “greatest individual in history”, of being “dead right about everything”, etc., etc. They glorified vaccum tubes for deciding how many refrigerators should be built for the next fiscal year. Resource allocation is a very important job, true, but the hype that humans have built around EPICAC is rather excessive. In fact, the hype so disgusted the Shah that he called EPICAC a “baku” (false god).

This hype is bad for a very simple reason: it blinds humanity to any mistakes that EPICAC can make. If you believe that EPICAC is very wise, then you will not seek to question EPICAC’s choices. In fact, the humans don’t even bother asking EPICAC why it made the choices it did, making it hard to understand if the reasons for those choices were even valid to begin with. While EPICAC can be much better at resource allocation than humans, that does not mean that it will always make the right choice, every single time.

And even if EPICAC make the right choices, it doesn’t mean that the outcomes would be what we want. EPICAC’s economic planning is unbiased, but it does have end-goals in mind, and those end-goals are reflected by EPICAC’s programmers. The engineers believe in maxiziming the standard of living of the average citizen through economic growth and mass production of material goods. EPICAC has succeeded at this task admirably. However, EPICAC wasn’t focused on making people happy. It wasn’t programmed to do that.

Due to the proliferation of machine labor, the vast majority of humanity are unemployed in the United States…and unemployable. EPICAC can bear some blame for this, due to EPICAC’s strict enforcement of “I.Q. and aptitude levels” to seperate the wheat from the chaff, but most of the blame lies with its human collaborators who strongly supported technological progress, regardless of the social costs. Society has remained somewhat stable, due to the rise of make-work jobs created by the Army and the Reconstruction and Reclamation Corps (funded by taxes on private enterprises), but the average citizen has nursed a grudge against the machinery that has taken away their dignity and sense of purpose. The Ghost Shirt Society, a radical terrorist group, sought to capitalize on the average citizen’s greviances in their manifesto:

“Man has survived Armageddon in order to enter the Eden of eternal peace, only to discover that everything he had looked forward to enjoying there, pride, dignity, self-respect, work worth doing, has been condemned as unfit for human consumption.”

Later on in the novel, the Ghost Shirt Society launched a nationwide uprising against machinery. The uprising successfully destroyed three American cities, and got very close to eliminating EPICAC itself. It’s safe to say that mistakes were made.

Could EPICAC and its human collaborators have prevented this disaster? Yes…but only if they had a different end-goal in mind: maximizing “human dignity” instead of mere “standard of living”. But while it might have stopped this specific uprising, EPICAC and its collaborators could have caused other problems as well. How would you measure human dignity, anyway? What sorts of trade-offs must be made in maximizing human dignity? Are these trade-offs that we are really prepared to make? Do we even want to maximize human dignity, or do we instead want a balance between a variety of different, even contradictory goals? You could imagine a different terrorist group, the Adam Smith Society, writing a new manifesto and planning a new nationwide uprising:

“Man have survived Armageddon in order to enter the Eden of eternal dignity, only to discover that everything he had looked forward to enjoying there, wealth, freedom, economic growth, material goods worth owning, has been condemned as unfit for human consumption.”

At the end of the day, humans…fallible humans…have to make choices when building their machines and delivering the data. EPICAC did nothing more than to carry out those choices to their logical, chilling conclusions. And EPICAC will not be able to please everyone. Sacrifices must be made.

If we can’t agree on how to fix the machine collaborator in this creative partnership, could we fix the humans collaborators instead? The human collaborators could acknowledge the possibility of machine error, and try their best to minimize the error. Rather than blindly trust the machine, the humans can evaluate the machine’s advice, and decide whether to accept the advice, modify it to fit human whims, or decline it outright. Of course, this approach has its own faults. Humans are fallible, and it is possible that humans may unwisely reject the advice of a machine.

In the real world, an algorithm designed to hire employees did a much better job than managers who treated the algorithm as an advisory tool and used “discretion” to hire people, yet machine-human teams are able to win chess games more effectively than a standard human or a standard machine (though this advantage is shrinking). Is the problem of “resource allocation” like hiring (in which case, it may still be better to blindly trust the machine, because the human is unable to add any value) or like chess (in which case, we do need humans at the helm ready to engage in collaboration)? Or are we willing to agree to a little bit of inefficiency because the consequences of too much efficiency may be too great?

Obviously, EPICAC is just an idea in a science-fiction novel. But the broader questions EPICAC raises about human-machine collaboration are still relevant today. These are hard questions, but nobody ever said collaboration is ever easy. Human-machine collaboration is not a sure-fire way to victory or prosperity, nor should it be used as a mere buzzword to justify AI investment. There are many questions that a human collaborator has to wrest with greatly, and the odds of the human collaborator getting those questions wrong are high. The last thing today’s human collaborators should do though is to behave like EPICAC’s human collaborators – to blindly trust the machine and to obey its every whim. To do so would be to abdicate their responsibilites and to claim that humanity itself is obsolete.

“At no expense whatsoever to you,” said Halyard, “America will send engineers and managers, skilled in all fields, to study your resources, blueprint your modernization, get it started, test and classify your people, arrange credit, set up the machinery.”

The Shah shook his head wonderingly. “Prakka-fut takki sihn,” he said at last, “souli, sakki EPICAC, siki Kanu pu?”

“Shah says,” said Khashdrahr, “ ‘Before we take this first step, please, would you ask EPICAC what people are for?’ “

[1] If you are curious, the Shah asked a riddle to EPICAC. This is the translation of the riddle, as given by Khashdrahr.

“Silver bells shall light my way, And nine times nine maidens fill my day, And mountain lakes will sink from sight, And tigers’ teeth will fill the night.”

The answer to this riddle is posted in this Reddit thread.

This month, I finished a blog post series about “text generation” – or less jargony, programming computers how to write. This blog post series is available on the Practical Developer website (for mass consumption by a technical audience).

Here are the links to those blog posts, in order of publication:

• “Structure” in Computer-Generated Novels
• Using Templates in Computer-Generated Works
• The “Commonsense” Problem in Computer-Generated Works
• Who are the Audiences of Computer-Generated Novels?

I started this series due to my recent experiments in text-generation. I wanted to collect all the knowledge about that field so that other people wouldn’t have to focus on reinventing the wheel.

For example, Prolefeed is a Ruby gem that was based on an algorithm that I invented in 2015. You give the algorithm pre-made content, and then the algorithm randomly shuffles its order. This algorithm was so simple that I wondered whether it was already invented.

Well, it was. In 1986, Judy Malloy worked on Uncle Rogers, an art project that also doubled as a computer program. One file in this project is called “Terminals” - the program would randomly select paragraphs from a “corpus” and then display them to the user[1]. Paragraph shuffling was also independently discovered and used in 2011 to create spam articles that would trick Google into indexing their site and ranking them high in search rankings (an example of “Black Hate SEO”).

There are probably other examples where random shuffling was independently discovered. The point is to stop this sort of “multiple discovery” from ever happening again. Text generation itself had a long history of academic research starting in the 1970s, and yet there has been a cycle where this technology is discovered, forgotten, rediscovered, reforgotten, etc., etc.

It seemed more reasonable to document this technology so that users don’t have to worry about writing brand new code that somebody already written 10 years ago. They could instead read these articles and learn from them, and then build off that knowledge to produce something brand new and innovative.

However, by I started work on Article #4 in my series, I realized a flaw in my thinking. In my attempts to write about text generation, I realized that I was attempting to catalog the field…with all its nuances and quirks. Every attempt to add a new category only serves to reveal the flaws of my previous categorizations.

For example, in Article #3, I wrote about the possibility of people treating computer-generated works as its own genre…with its own unique fanbase. While planning Article #4 though, I realized that there are two unique fanbases for computer-generated works. The first fanbase loves computer-generated works for being a form of “conceptual art”, and the second fanbase likes the idea of consuming repetitive content. If there are two fanbases, are there two different genres then? The clear idea I had in Article #3 was undermined by details in Article #4.

The Argentine writer Jorge Luis Borges wrote about my dilemma in the short story The Analytical Language of John Wilkins. John Wilkins wanted to create a language that would seek to explain the universe. But the problem with such a language is that the language’s very construction would be arbitrary and based on cultural biases. There will always be “ambiguities, redundancies and deficiencies” in any attempt to categorize the universe, and such attempts at categorizations reveal more about the author than about the universe itself.

Text generation is a field that is smaller than this universe. But it is still an extremely broad field, with its own hidden depth. Any attempt to fully cover the field would fail, and deciding what topics to cover and what topics to ignore is a very difficult (and rather arbitrary) choice. Rather than following in John Wilkins’ attempts to build the universal language, it would be better to simply end the blog series on a high-note.

This is why writing about “cutting-edge technologies” such as text generation is so difficult. There is no way for a single human to fully explain the field coherently and objectively, no matter how many words he or she writes. What is left is a rather incomplete and biased picture of the world, not truly comprehensive or representative of the broader field. To truly understand the field and to avoid reinventing the wheel, you will likely have to do your own research into the field, learning from the biased viewpoints of others and trying to synthesize them together to create your own biased viewpoint.

We are all blind men feebly trying to understand the elephant.

[1]The “Terminals” web app simulates randomly picking paragraphs from a corpus by having a blank keyboard that a user can click on, but if you are interested in a demonstration with no user interaction…please look at Another Party In Woodside (a more recent program written by Judy Malloy).

Most people think spies are afraid of guns, or KGB guards, or barbed wire, but in point of fact the most dangerous thing they face is paper. Papers carry secrets. Papers can carry death warrants. Papers like this one, this folio with its blurry eighteen year old faked missile photographs and estimates of time/survivor curves and pervasive psychosis ratios, can give you nightmares, dragging you awake screaming in the middle of the night.—A Colder War

Humans have written papers all their lives. Writing was once considered a praiseworthy activity that required intelligence. But technology has now advanced to the point that computers are able to imitate the very process of writing successfully, and we are forced to decide between two unappeasing statements:

• Computers must be intelligent.
• Writing doesn’t require intelligence.

This is, to me, pretty scary for a variety of reasons: loss of purpose and ego issues, possible rise in unemployment, human dependency on technology to do all the work for them, etc. And I wanted to do something to counter the rising power of AI.

[EDIT, Feb. 23rd 2017 - This statement may seem rather “Luddite” if divorced from context, so I am adding this edit note as clarification of my intent. I am not specifically opposed to AI as a technology in and of itself, because AI is useful and have its benefits. But AI also have risks as well, and what I noticed is the lack of societial regulations meant to deal with those risks.

I don’t think this is controverisal, per se, to suggest that society needs to take steps to contain the very real dangers of AI, maximizing its benefits while minimizing its damages. Progress is not always positive, and the dangers of AI can outweigh its benefits…if progress is not carefully controlled. Otherwise, we are simply “shoot[ing] ourselves in the foot”.]

It has been 15 months since I first entered DBC, almost one year since I graduated from Dev Bootcamp. During that time, I attempted to research the emerging field of computer-generated literature…in the hopes of using this technology against them, as a form of advocacy against uncontrolled research into AI.

During the on-site portion of the DBC curriculum in Chicago, many people learned about this plan, especially after I produced Friend Computer, a blog written by a computer, as a standalone DBC project. However, since then, I have not been in much contact with the people on DBC ever since my graduation…and so I decide to write a blog post to explain what happened.

I’ll start by quoting an email that I sent to a random stranger:

Let me introduce myself fairly carefully. I like to write. When I was a teenager, I served as a volunteer journalist. In college, I published a research paper. Even today, I write nonfictional blog posts and some (unpublished) fictional stories. So I still write, although I do not identify myself as a “writer”. My day-job is a computer programmer…where I write computer code (although it may not be beautiful or elegant to read).

I had very some uncomfortable feelings about artificial intelligence and technology…especially our overt dependence on it and its potential impact on humanity. After reading an article about Narrative Science and its robojournalist articles, I wanted to take a stand against technological progress causing us to “shoot ourselves in the foot” [by writing a dystopian novel about an AI supercomputer that ruled over human society with an iron fist].

And I immediately realized that this novel had to be computer-generated. It had to be that way. If I “handwrote” a sci-fi novel about the dangers of technology, then it would just be my opinions, my thoughts. Not reality. Nobody would listen to the thoughts of a random person, and would simply dismiss my fear as “Luddism”. If I am able to build proof of the dangers of technology (computer-generated literature), then that would make my arguments against technology more persuasive. “If technology can do X now, what about the future?” Etc., etc.

The “Ozymandias Gambit” is the term that Duke Greene (a DBC teacher) named my scheme. It is named after the character from the “Watchmen” comic book series. Ozymandias, the main villian of the comic book series, wanted to end the Cold War by creating a Lovecraftian monster to attack both the United States and the Soviet Union. His hope is that this monster would scare the superpowers long enough to unify together, thereby forestalling the possibility of nuclear armageddon.

I built “Skynet”, a command-line program that can be used to generate stories based on a “Mad-Lib”-style template. Someone even built a Python script that can turn existing novels into templates that can then be used to generate stories…and used it and a configuration file to generate a Sky template of The Odyssey.

Now, certainly, I could have actually produced the anti-technological novel with this tool I had. But I would have to write out all the templates in question, which almost defeats the whole purpose of building the program. The templates would have done most of the work, while the computer in question really only randomly select words to plug into the templates. So I gave up on that line…and tried other approaches to procedural generation.

As for expressing my ire about technology, I did find other outlets. I wrote algorithms to generate two short stories against technology and a blog post condemning artificial intelligence. There was still some human involvement involved. I wrote all the words in the short stories and the blog posts. But the algorithm also played a role in deciding the order of my paragraphs within the story. And the order matters just as much as the text. I even released my algorithm as an open-source Ruby gem called Prolefeed.

So, yeah, I carried out a lesser version of the “Ozymandias Gambit”.

Most people didn’t care. Those that did can be placed into two camps, the Futurists and the Traditionalists:

##The Futurists There are those who really liked the technology that I was working on. They saw it as cool and exciting, and thought about improving on my methods. Which, of course, misses the point.

Which is why I started my blog post by quoting from “A Colder War” instead of from the “Watchmen”. “A Colder War” is a novella that had a premise: What if the superpowers discovered Lovecraftian technologies? The answer was simple…they started using it to fight their Cold War! The ‘paper’ that the quote was referring to is a CIA report about Soviet Union’s “Project Koschei” (a plan to use Cthulhu as a superweapon against the United States).

So Ozymandias may have been too optimistic. Instead of seeing Ozymandias’ monster as a wakeup call, the superpowers could have simply started building their own monsters instead. I mean, Ozy already did it. How hard could it be?

Ozymandias could, of course, take a perverse pride in contributing to the very fear that he opposed. In fact, he’d probably make a killing selling his monster-building techniques to the superpowers. But the irony is there. It cannot be concealed or denied.

##The Traditionalists These people did view technology as a threat, and thus would sympathize with my anti-tech rants. They were mostly creeped out by the possibility of text generation. The computer-generated text may not be ‘on par’ with human-generated work, but it could improve with time..and besides, computer-generated work doesn’t have to be “good”. It just have to be “good enough”. This audience was receptive to my message.

But that’s it. Having felt chills down their spine, they haven’t moved a single inch to stop this trend. It’s almost as if they couldn’t do anything to stop it. There is almost a sense of resignation…that you can’t fight progress. I guess the best you can do is write against the future…but then again, I already wrote an algorithm to write against the future.

In this scenario, people saw Ozymandias’ evil monster, but resigned themselves to the fact that it existed and moved on with their lives. “Yeah, a monster destroyed New York. What a shame. So whose going to win the Super Bowl this year?” It’s not like they hate the future…they certainly do. But they realize that they can’t change it. All they can do is to accept it and prepare for it.

##The Failure of the Ozymandias Gambit Today, I sometimes “write” computer-generated blog posts about computer-generated literature and post them on dev.to, with plans to eventually port them over to this site. I like to inform people about this field and its technical merits, while also conveying my distaste and disgust at the field as well.

[EDIT, Feb. 23rd 2017 - This distaste and disgust is not based on the technology itself, as the technology is very cool and exciting. However, there are uncontrolled risks with AI. That’s what I express my distate and disgust at – that there’s problems with AI as well and we humans don’t have a good solution to deal with these problems.]

This blog post, however, was not computer-generated. I could have wrote an algorithm to write this blog post. I have to break this blog post up into smaller chunks, and then use Prolefeed to shuffle the chunks. It is fairly easy (although time-consuming) to pull off. But today, I just wanted to express my own feelings about my experience. Not what the computer wanted to write about. Maybe the computer might be a better writer than me. But I still want to vent my thoughts anyway. (Duke Greene, my DBC teacher, have also said the same thing about his own creative works…he likes doing them manually because he wants to express his own thoughts, without any such mechanical filters.)

I’ll probably keep writing against the future, warning people about the possible disaster of artificial intelligence and how we need societal regulation against it to limit its damages. But now I am under no illusion that my posts will actually change anything. At least I tried.

According to Victor Powell, “Markov chains, named after Andrey Markov, are mathematical systems that hop from one “state” (a situation or set of values) to another.” Many people have used Markov chains to generate literature based on a pre-existing corpus. This blog post explains some experiments I recently did with Markov chains, with the goal of generating readable text.

Marky_Markov is a Ruby gem that can be used to generate Markov chains. I used it to quickly set up a Markov chain and start fooling around with it.

require 'marky_markov'

markov = MarkyMarkov::TemporaryDictionary.new
markov.parse_string "The cat is very friendly."
markov.parse_string "The dog is slightly friendly."
markov.parse_string "The sky is very unfriendly."
markov.parse_string "The window is slightly unfriendly."

markov.generate_10_sentences

=>”The window is slightly unfriendly. The window is slightly friendly. The sky is very unfriendly. The sky is very unfriendly. The window is slightly friendly. The sky is very friendly. The cat is very unfriendly. The cat is very unfriendly. The window is slightly unfriendly. The cat is very friendly.”

Some of the sentences are copies of the original corpus, but other sentences are original! The algorithm had learned how to write original sentences!

These sentences are fairly dull though. The generator also repeats itself sometimes.

At this point, the budding Markov Chainer will start searching for a pre-made corpus that can then be fed into the Markov Chain. But I’m not a budding Markov Chainer…if anything, I’m slightly jaded. The benefit of feeding a pre-made corpus into a Markov Chain is that the text start sounding more interesting. The problem is that the text also becomes less coherent. Here’s some sample text from a Markov chain trained on “The Raven”:

Once upon a bust of Pallas just above my chamber door; – This it is, and this mystery explore; – ‘Tis the wind and nothing more.

I can understand why some people may be happy with text that seems meaningful so long as you don’t read it too deeply. In fact, this text could plausibly be used as poetry. Any oddities in the text itself can be explained away as stylistic choices and metaphors.

But if we decide to use Markov chains outside of poetry, well…um….

Here’s some sample text from a Markov chain trained on the ‘tinyshakespeare’ corpus:

DUKE VINCENTIO:

Well, your wit is in the care of side and that.

FRIAR LAURENCE:

Or walk liest;

And the ears.

And hell!

In self.

PETRUCHIO:

Persuading to our the enemy, even woman, I’ll afford show’d and speaking of

England all out what least. Be satisfied! Now, sir.

Second Lord:

They would be ruled after this chamber, and

my fair nues begun out of the fact, to be conveyed,

Whose noble souls I’ll have the heart of the wars.

…yeah, no. The blogger is surprised about how his Markov chain learned Old English, but I absolutely hate this output. This is why I had been reluctant to use Markov chains ever…because what they actually produce is utter nonsense.

When I conduct experimentation in text generation, my goal is to produce text that reaches human quality. This bias may have been caused by my previous experience as a journalist, where I was expected to write words that people are able to read…not necessarily text that appears to be readable. This causes me to prefer more ‘conservative’ techniques in text generation (shuffling paragraphs, using pre-written templates, etc.)

Recently, I started a Medium blog where I showed off some fictional work that was computer-generated. This blog was somewhat controversial on Reddit, as can be seen in the comment thread. Many people raised the valid point that the algorithms used were just too simplistic for their tastes (as I was too reliant on my ‘conservative’ techniques). While I was happy with my output (it was readable), I also realized that I needed to do slightly more experimentation. One reddit poster (kleer001) made a rather interesting comment:

let’s see some markov chains maybe?

here, have som fun with this: http://projects.haykranen.nl/markov/demo/

sorry I noped you, you sound like a cool dude, but still, you can do hella better. i believe in you.

Hence, why I was fooling around with marky_markov.

Looking at the output of my toy Markov chain (“The window is slightly friendly”) makes me realize that the main problem I had with Markov chains isn’t necessarily the chain itself, but the corpus that people use to train on it. If you provide complicated prose to a Markov chain (such as Shakespeare’s plays), you are not going to get good results out of it. What I’m going to have to do is to simplify the prose to a level that a Markov chain will be able to grasp and imitate properly.

I need to generate a corpus that follow these two rules:

1. Each sentence should have very simplistic and repetitive grammar.
2. Each sentence should be context-less; there should be no connection to previous and future sentences (the Markov chain will not have the ability to understand the context of words).

Now, writing out all these sentences for a corpus is rather dull…which can explain why some people reach for a pre-made corpus instead. But I remembered that I still had prior experience in text-generation. Why don’t I write a program that can generate text…and then use its output as a corpus? I used the Ruby gem ‘Calyx’ to quickly set up a template-based text generator.

require 'marky_markov'
require 'calyx'

markov = MarkyMarkov::TemporaryDictionary.new

class CorpusGenerator < Calyx::Grammar
  start '{dialogue}, {gender} {speak} {mood}.'
  rule :dialogue, 'Do you think she is out there', 'Do you think she cares', 'Will she ever care',
  'We have a job to do', 'She has a job to do', 'I did the right thing',
  'She did what was right', 'Do not kill me', 'I must kill you',
  'You have a job to do', 'I am sorry', 'She is sorry',
  'I hate you', 'I am sorry I met you'
  rule :gender, 'he', 'she', 'the computer', 'the monster'
  rule :speak, "says", "giggles", "laughs", "cries", "sings"
  rule :mood, "sadly", "madly"
end

generator = CorpusGenerator.new

corpus = []

10.times do
  sentence = generator.generate
  corpus << sentence
  markov.parse_string sentence
end

Now, the problem is that the sentences are so basic that it’s likely a Markov chain could just re-generate those same, basic sentences. That’s no fun. But, the Markov chain does have the possibility of generating unique sentences too. I may need to measure how many ‘duplicated’ sentences it generates, to determine how much “uniqueness” the Markov chain can produce.

I decide to run my program with 10 corpus sentences, and then generate 10 sentences using my Markov chain, and then compare the uniqueness (the number of unique sentences divided by the number of total sentences generated).

SAMPLE = 10

SAMPLE.times do |sentence|
  generated_sentences << markov.generate_1_sentence
end

duplicated_sentences = generated_sentences.select {|sentence| corpus.include?(sentence) }

def calculate_odds(duplicated_sentences)
  duplicates = (duplicated_sentences.length.to_f)
  percent_of_duplicate = (duplicates/(SAMPLE.to_f))
  1 - percent_of_duplicate
end

puts "The number of duplicated sentences is #{duplicated_sentences.length}."
puts "The uniqueness of the text is #{calculate_odds(duplicated_sentences)}."

I also added some print statements to this code to view the original corpus and the generated sentences. I highlighted any unique sentences by using dashes.

#Input Corpus (Generated By Templates):
Do you think she cares, the monster says madly.
Do you think she cares, the monster sings madly.
She has a job to do, she giggles madly.
I am sorry, she sings sadly.
I am sorry I met you, the computer cries sadly.
I hate you, he says sadly.
I did the right thing, she laughs madly.
I am sorry I met you, she sings madly.
She has a job to do, the monster says sadly.
Will she ever care, the monster says madly.

#Ouput Sentences (Generated by Markov Chains):
I hate you, he says sadly.
I did the right thing, she laughs madly.
Will she ever care, the monster says madly.
She has a job to do, she giggles madly.
I hate you, he says sadly.
- I am sorry I met you, she sings sadly. -
She has a job to do, she giggles madly.
- Will she ever care, the monster says sadly. -
- Will she ever care, the monster sings madly. -
Will she ever care, the monster says madly.

The number of duplicated sentences is 7.
The uniqueness of the text is 0.19999999999999996.

So, about 20% of the generated text is unique. That’s…actually kinda justifiable. Surely, the corpus generator is doing most of the work, but the Markov chain is able to add some additional “variation” to the output.

Usually, Markov chains work well when you give it a large corpus. But luckily, since we already have a corpus text generator, we can just tell it to produce as many sentences as we want. So, I generate a corpus of 1000 sentences, use that corpus to train a Markov chain, and then use the Markov chain to generate 1000 new sentences.

The number of duplicated sentences is 712.
The uniqueness of the text is 0.28800000000000003.

Excellent. 288 unique sentences! I wonder what they read like…

I met you, the monster giggles madly.
a job to do, she sings madly.
I met you, she cries madly.
must kill you, she sings madly.
do, the monster laughs sadly.
You have a job to do, the computer laughs sadly.
he cries madly.
job to do, the computer cries madly.
a job to do, she sings madly.
me, he giggles madly.
I met you, the monster cries madly.
you think she is out there, she says madly.
he says madly.
She is sorry, the monster cries sadly.
she cries madly.
I met you, the monster laughs sadly.
right, she laughs sadly.

Oh.

Clearly, there’s still work to be done, especially with the initial text generator. The sentence fragments are annoying (though I presume I can write some more code to scan the generated text and delete any sentence that aren’t complete). The bigger problem is that this wall of text is…fairly dull and boring. I don’t really care why all these characters are speaking.

I need to try to create a somewhat sensible theme, at least one well enough that to justify having all these random people talking to each other. Or maybe I need to have different types of sentences that could be generated (possible descriptions and actions) that makes the generated text slightly more engaging.

The Markov chain interestingly was able to generate a phrase that was not specifically hardocded into the generator…“I met you” (obviously an extract from “I am sorry I met you”). And yes, it can repeat that phrase a lot.

I met you, the monster says sadly.
I met you, the computer giggles madly.
I met you, the monster says sadly.
I met you, the computer laughs madly.
I met you, the monster sings madly.

I am unsure whether this experiment was a success. On the one hand, the Markov chain did add ‘value’ to the process, by generating fairly unique sentences. On the other hand, much of this additional variation could have been easily accomplished by simply running the text generator again. The variations that the Markov chain does produce are fairly trivial and may not be interesting on its own.

I am also dubious on whether more uniqueness would actually be a worthwhile goal. Infinite text generation itself may not be very interesting. You’re usually only going to read a small fraction of whatever the program generates, before you get bored and ready to move onto the next content to consume. If that’s the case, then why try to increase the number of possible variations? The reader is still going to get bored anyway. It may be smarter to instead focus on making each individual variation interesting.

The one bright spot in this research is its possible application to machine learning. The blogger who trained Markov chains on the ‘tinyshakespeare’ corpus asked “Is Deep Learning a Markov Chain In Disguise?” The output of a machine learning algorithm (when trained on text) is only slightly better than that of a Markov chain, after all. If you can write a program that can generate a corpus that then can train a Markov chain to produce meaningful text, then you could reuse that same program on a machine learning algorithm. Maybe their output may be more interesting to read.

Disclaimer: I wrote the book “Essential Copying and Pasting From Stack Overflow”, which was inspired by a cover designed by ThePracticalDev. This blog post is also inspired by a cover designed by ThePracticalDev. Just like “Essential Copying and Pasting From Stack Overflow”, “Expert Resumé Driven Development” is also written in a deadpan manner.

What is "Resumé Driven Development"?

Resumé Driven Development refers to the practice of choosing hot new technologies for your projects to make your resumé more impressive. For example, you want to write a program in that hot new Javascript micro-generator framework “Plop.js”…because it’s a hot new JavaScript framework. Sure, you can use the technologies that you already know and are probably better suited for the job, but that wouldn’t be as impressive as riding the hot bandwagon. You don’t even know what “Plop.js” is, but you’ll find out soon enough.

There is some controversy on whether Resumé Driven Development is actually good. Paul E. Davis defended the practice as it is an indictator that the developer is willing to learn new technologes instead of sticking with potentially obsolete solutions. Sure, “Plop.js” may not actually be suited for your use case, but at least you showed that you can learn it and use it quickly, and that you could later on find the bleeding-edge technology that might actually be useful.

“In the end, if developers are not concerned with their own careers, it’s not likely they’ll be concered with your business.”—Paul E. Davis

Most developers seem to detest RDD though (as can be seen by this parody website). There is a general belief that developers are not using using the hot new technologies in their spare time, but instead using them on company projects. This is a colossal waste of company funds, as the technology may be ill-suited for the task at hand and can lead to long-term maintanance headaches.

Developers are not the only people that engage in Resumé Driven Development. Management may also engage in RDD during the hiring process as well. If a job vacancy exists, there is a desire to hire a new programmer with the same skillset of the old programmer. So the old programmer was an expert in Plop.js, then the job posting will read “6 months experience with Plop.js”. This may be a very bad thing because you are optimizing for knowledge of certain technologies, instead of choosing the “right tool” for the job. If you only hire Plop.js developers, you will only get Plop.js websites.

RDD is probably a subset of a larger Principal-Agent Problem. The Principal (management) hires an Agent (a developer) to build a program and allow the Agent to choose the tech stack. But the Agent’s interest (making his resumé more impressive) can be orthogonal to the Principal’s interest (producing a great product by using the “right tool” for the job). If the Principal allows the Agent to do as he wish, then the Agent will do as he wishes, thereby leading to the Agent to prosper and the Principal to suffer.

RDD is composed of two sections: the Resumé and the Technology. Let’s look at them both briefly.

The Role of the "Resumé"

A resumé serves to let people know what you have done, in the hopes of getting people impressed. According to a study by TheLadders, a resume re-writing company, recruiters can spend 6 seconds per resumé, scanning for keywords and cursory background information about your education and job history before deciding whether you are “fit” or “no-fit”. You can see why some developers want to maximize those 6 seconds by practicing RDD.

Now, there is not that much in-depth examination of what’s on the resumé. If someone says that they used Plop.js when building a Uber-For-Dogs application, then you assume that they did use Plop.js and that there actually is a Uber-For-Dogs application…that he really spent 6 months on it…and that he got to pet a unicorn while on the job. It says so on the resumé. Just keep scanning for more keywords then.

You can see where I’m going here. Resumés can lie. You can claim to have worked on sixty Plop.js projects in closed-source companies, and provide fake phone numbers and references as ‘proof’ that these closed-source projects exist. Lying is horribly unethical, and I would not recommend it for anyone to do. But it can be done, and is probably more efficent than a pure RDD approach…at least in getting the foot in the door. However, at the interview stage, interviewers will attempt to weed out those that did lie on their resumés - such as asking basic questions like “What is Plop.js?”.

So the better option is to actually use the technologies on real projects then, so that when you get to the interview stage, you can actually prove your expertise in it and not be exposed as a fraud. That (sadly) means you do have to build a Uber-For-Dogs application just so you can use the Plop.js keyword. You may even need to provide a link to the application and show the source code, in case someone looks at your resumé for longer than six seconds. However, once you do this, you do not have to worry about proving anything else. If you can demonstrate that you can use Plop.js, then most people will assume that you know how to use it.

Choosing the Hot Technology

The biggest problem with choosing hot new technologies isn’t actually learning them. It’s difficult, and you’ll have to deal with bad documentation and difficult solutions, but given enough time and persistence, you will eventually succeed.

No, the biggest problem with choosing hot new technologies is that you don’t know what is actually hot.

You can guess. You can listen to a community, and if the community talks a lot about Plop.js, then that suggest that Plop.js is hot. If the community stops talking about Plop.js, then Plop.js must not be hot. You can bookmark Google Trends and pay attention to what words people are searching. You can look at job postings and see what keywords the recruiters are using. And so on and so forth.

But they’re all trailing indictators. It doesn’t help you predict whether that tech will stay hot in the future.

It is here that Gartner Hype Cycle can be most useful for an RDDer. Gartner argues that all new technologies go through a cycle. I described the Hype Cycle in my blog post against Artifical Intelligence…and I reprint my comments on this cycle here:

At first, people become very interested in a brand new technology (a “Technology Trigger”). Companies start to over-invest in researching this technology, leading to a “Peak of Inflated Expectations” (i.e, a bubble). But the technology turns out to have major limitations. As a result, investment in the technology dries up (“Trough of Disillusionment”). Most companies either begin laying people off or closing down outright.

Eventually, the survivors soon realize how to use the technology properly (“Slope of Enlightenment”), and we can finally use the technology in our day-to-day life (“Plateau of Productivity”). But as this picture from Wikipedia shows, the visibility of the technology in the Plateau of Productivity is much less than the visibility of that same technology in the Peak of Inflated Expectations. The brand new technology has done great things for us. It’s just not as great as we hoped it to be. And does it justify the extreme waste seen in the “Peak of Inflated Expectations”?

Since the technology reaches the maximum visibility/hype in the Peak of Inflated Expectations, this implies that, by the time you hear of a tech, it’s already too late. The only people who would be able to take advantage of the hype are the ‘early adopters’, and they are the ones who will likely reap most of the benefits (though they also accept most of the costs as well, since not all new technologies are interesting or useful enough to go through this Hype Cycle).

Another message this charts tells us is that the best time to learn a new technology is either during the Technology Trigger or the Trough of Disillusionment.

During the Technology Trigger stage, there are no experts. There are only a few people who know your keyword. Specializing now as an ‘early adopter’ (while the field is still young) would be much more impressive than being an expert during the Peak of Expectation, when you have thousands of ‘experts’ in your field. Building a bot that can draw paintings now seems neat. Building a paint-bot five years from now, when every programmer have already built their own personal paint-bot? Boring.

During the Trough of Disillusionment, you are able to take advantage of previous research done during the Technology Trigger and the Peak of Inflated Expectations, learning from past successes and failures with the tech. You also will have less competition during the Trough, as most programmers have already left to move onto the next “hot” technology. Eventually, interest in the tech will revive, and your lovely keyword will regain some allure.

Any other time to study a technology would carry either too much competition (the Peak of Inflated Expectations) or too little reward (the Plateau of Productivity) to justify the expense. The only reason you would want to study the technology in that case is because you think it might actually help you grow as a developer.

Can humans build a story-telling machine that can trick other human beings (a la the ‘Turing Test’)? Dartmouth College’s Neukom Institute for Computational Science is hosting a competition (“DigiLit”) to see if that can be done. I submitted a program (Architect) to this program. I think it has a good shot of winning (~40%).

The idea behind DigiLit is simple. You build a machine that can accept an arbitrary noun prompt (“wedding”, “sorrow”, “car keys”, etc.). The machine then uses this noun prompt to generate a short story that is 7000 words or less. Then this short story is then presented to two panels (each with 3 judges). If you can convince a majority of one panel that your story is human-generated, then you win.

This does seem like a difficult task. You must:

1. Have the computer accept arbitrary input
2. Generate a story using the input
3. Make sure the story is coherent enough to be readable

Yet, I think I completed this task. After I finished writing my program (Architect, named after the program in the Matrix trilogy), I decided to test it out. I chose a random noun prompt, and wrote a story based on it. I also had my program generate a story as well (using that same noun prompt). I then gave those two stories to 7 people. Story A was written by me, and Story B was written by the program.

• 3 people correctly identified Story A as being written by a human.
• 3 people wrongly identified Story B as being written by a human.
• 1 person admitted he didn’t know.

This means that 43% of the humans were fooled. That’s pretty good. And it’s good enough for me to submit it over to DigiLit.

That doesn’t mean that victory is assured, after all. 43% isn’t exactly a majority. But consider that I really need to convince 2 out of 6 judges to have a good chance of ‘convincing’ a whole panel of 3 judges (assuming that both judges sit on the same panel). That means I only need to convince 33% of all judges.

To be 100% certain of convincing a panel though, I would need to convince 3 out of 6 judges (so that no matter how the judges are distributed, at least a majority of those I convinced would sit on a single panel). That does require me to be able to convince 50% of all judges. That doesn’t seem too likely.

One main problem with my study is that the format of my test and the DigiLit test is slightly different. In my test, each person is reading both stories individually and then making a choice. In DigiLit, the judges sit on a panel, have access to multiple stories (some human-generated and some machine-generated) so they can detect patterns and ‘tells’, and can talk to one another and share their insights. The mob will likely find more faults in a story than a single human can. So my study may likely overestimate how good my program actually is.

But enough boring stats. Here’s the source code of Architect and a brief description of how it works:

1. Have the computer accept input:
   • Plug the input into a madlib template: {INPUT} {LOCATION_TYPE}. For example:
     • Sorrow Academy.
     • Wedding Plaza.
     • Car Keys Muesum
     The story will therefore be about a generated LOCATION, and not directly about the noun prompt. Here, I'm assuming that reader will assume that when the program is writing about "Sorrow Academy", they assume it to be symbolic of the actual noun in question ('sorrow').


2. Generate a story using that input:
   
   • Randomly pick an introductory sentence from a corpus of introductory sentences.
   • Load the program with several pre-written passages.
   • Randomly pick a few of those passages. Insert in the LOCATION into the passages (so that the passages would therefore be about the input in question).
   • Between each passage, insert a "transition passage" to link the two passages together (providing an illusion of continuity between the passages). The "transition passage" was also pre-written.
   • Randomly pick an conclusion sentence from a corpus of conclusion sentences.
   This isn't a story with any planned plot or coherence. The program has no idea what it's writing. But since there is an illusion of continuity between passages, humans are able to read a 'narrative'.


3. Have the story be thematically coherent enough to be readable.
   
   • Each sentence of the story must have certain repeated symbols, themes, and characters within them, so that readers are more likely to assume that there is some purpose behind the words. (This approach was originally used in the Fairy Tale Generator to create interesting stories based on random paragraphs.)
   • Since I'm too lazy to hand-craft most of these sentences myself, I decided to use a preexisting generator (Abulafia's Film Noir Monologue generator) to generate most of the paragraphs, introductory sentences, and conclusion sentences. Since this generator already had a prebuilt theme in mind (a cynical detective trying to solve a mysterious case), the resulting output does have some sort of thematic coherence. I then edited most of the paragraphs and sentences to provide even more thematic coherence.
   • The 'transition passages', however, were handwritten by me. Again, their goal is to provide thematic coherence and to "fit" with the rest of the passages.

This was the computer-generated story that I presented to my readers during the test:

It was a dark day—maybe normal for this time of year, but today the big city felt even darker and more sinister.

Miss Kitty Rider prowled through my door like a tigress slinks into a Burmese orphanage—a pinup blonde with legs as far as you could want ’em. No dame her age could afford a coat like that, my money was right where my mind was: the gutter. She was to bad news what apple pie is to America. The dame was all business—before I could even close the office door, she told me she wants Investigator Blake dead. Turns out Blake is masterminding the gang violence, and wants to seize the Envy Foundation for himself by killing off all his rivals. I laughed at her; Blake may be a devil, but he’s a devil I can work with. I wasn’t going to sell him out.

I asked Miss Kitty Rider if there was another way to end the gang violence, without having to take out Investigator Blake. Miss Kitty Rider responded me that if I wanted to bring an end to the violence, then I needed someone who is outside of the system. She recommended a fresh recruit from the police academy who was ‘on the ball’. Mr. Simpson. I foolishly took her advice.

“An inside job…?” Simpson gasped timidly. “Well … No… not an inside job,” I growled. I could barely contain myself with this new guy. “Here’s the deal,” I muttered, “Why don’t I handle this case, while you make like a magnet … and flux off?”

Before I left, Mr. Simpson offered me the phone number to the office. He claimed that the office had helped him greatly and that it can help me too. Desperate for any clues, I took Mr. Simpson’s advice. I spoke to the receptionist for an hour, and jotted down everything she said.

I had little to go on this time … but the office did manage to dig something up. G-Men, fighting crime and resisting corruption, deciding that the best way to fight crime and resist corruption is to kill everyone who might be a criminal and might be corrupt. Their current goal is to ‘purify’ the Envy Foundation before moving onto other tourist attractions. I always knew that G-Men were a little ‘special’.

I shoulda got out when I had the chance.

Now, this story does have its faults. According to one of my readers, there isn’t really any coherent plot, and no actual attempt to explain what’s going on. And I agree with that reader. The stories that my program spits out are really more like ‘prose poetry’: the plot is really just an excuse to show off different evocative scenes. But I know that some people may like reading these stories anyway. Evocative scenes are enjoyable in their own right.

In addition, another reader praised the computer-generated story as having “linear progression”, and a “[natural] level of detail and organization and flow”. This suggest that the existence of some underlining structure may also help to make this story more appealing to read.

What is undeniable is that my computer has written a story.

My entry is based on a simple trick: Humans has a tendency to see patterns in everyday life, even when no patterns exist. The very act of me placing words right next to each other imply that the words must have some relationship with each other. So the humans create this relationship within their own mind. This tendency for humans to see patterns where none exist has a name: “apophenia”.

All I have to do is to provide some context and themes to help trick the humans into assuming that there must be meaning in the words that the program generates. Once that happens, the humans will then fill in the details by interpreting the program’s words. The computer can write total nonsense…and that’s okay, because the humans will just happily figure out the meaning of that nonsense. While the humans figure out that meaning, they thereby construct the story out of that nonsense. A story, therefore, appears from a mere collection of words.

Appendix A: Is This Story Of High-Quality?

I don’t know. It appears that if the judges think that a story is human-written, they will generally assume it to be better…

This sounds silly, but according to my data, the rating of the quality of the story is dependent on whether the judge assume the story is written by a human.

• Out of the 3 people who correctly identified Story A as being written by a human, 2 of them gave that story higher marks than Story B, while 1 person gave Story B higher marks.
• Out of the 3 people who wrongly identified Story B as being written by a human, all of them gave Story B higher marks.
• The one person who didn’t know which story was human-written? He gave both stories equal marks.

This is a pretty odd result and suggests to me that the ‘origin’ of a story impacts how judges view its quality. This makes some sense: humans like reading what other humans have written, and if they assume that something is human-written, they are willing to think of it as good (even if it’s not). But at the same time, I do have a small sample size, and it’s possible that a different group of judges would determine the quality of a story more “objectively”.

By the way, there have been several peer-reviewed studies about how humans’ perceptions of news articles can change based on whether they were told the news article was written by a ‘human’ or by a ‘robot’, and I do plan on blogging on these articles later. I trust the results of those peer-reviewed studies over that of my unscientific study.

Appendix B: Can This Program ‘Scale’?

Using a single noun prompt, my story can generate 120 different short stories. Most people are not going to read all 120 stories. Instead, they’ll only read a few computer-generated stories before moving onto the next content to consume. So I’m fine with how the algorithm works currently. There’s no reason to spend time writing more code than is necessary.

That being said, the algorithm could “scale” upwards. If the program is given more passages, you could easily generate more short stories (or even longer stories, possibly even novels). Finding those passages (and making sure they are all thematic coherent) may be somewhat difficult to do, and would most likely require using passages from Creative Commons or public domain works.

Note that the “transition phrases” will have to be made more ‘generic’ and reusable for different passages. Currently, I had to handwrite each transition phrase to handle specific situations (for example, I handwrote a the transition phrase to justify our unnamed detective leaving Mr. Simpson’s place and calling the Office). Handwriting each transition phrase is a very laborious and tedious process. Having “generic” transition phrases, on the other hand, would have enabled me to focus on copying and pasting as many evocative scenes as possible into the generator.

[EDIT, Feb. 23rd 2017 - The goal of this computer-generated blog post is not to argue against artifical intelligence. AI has many benefits. However, AI also has problems too, and I wanted a blog post to focus on these problems. It is ultimately a call for greater societial regulation of technology, to ensure that AI benefits humanity, not harms it.]

I was ‘inspired’ to write this article because I read the botifesto “How To Think About Bots”. As I thought the ‘botifesto’ was too pro-bot, I wanted to write an article that takes the anti-bot approach. However, halfway through writing this blog post, I realized that the botifesto…wasn’t written by a bot. In fact, most pro-bot articles have been hand-written by human beings. This is not at all a demonstration of the power of AI; after all, humans have written optimistic proclamations about the future since the dawn of time.

If I am to demonstrate that AI is a threat, I have to also demonstrate that AI can be a threat, and to do that, I have to show what machines are currently capable of doing (in the hopes of provoking a hostile reaction).

So this blog post has been generated by a robot. I have provided all the content, but an algorithm (“Prolefeed”) is responsible for arranging the content in a manner that will please the reader. Here is the source code. And as you browse through it, think of what else can be automated away with a little human creativity. And think whether said automation would be a good thing.

Unemployment

In 2013, Oxford Professors Frey and Obsurne argued that robots will replace 70 million jobs in the next 20 years (or 47% of all jobs in the USA). J.P Gownder, an analyst at the Boston-based tech research firm “Forrester”, makes a more optimistic case for technology in 2015, by claiming that by the year 2025, robots will only cause a net job loss of 9.1 million. (Both studies came from Wired.)

J.P. Gownder argued his lower estimate for job loss is because technology will create new jobs. In a Forbes article, J.P. Gowdner justified his viewpoint:

We forecast that 16% of jobs will disspear[sic] due to automation technologies between now and 2025, but that jobs equivalent to 9% of today’s jobs will be created. Physical robots require repair and maintenance professionals — one of several job categories that will grow up around a more automated world. That’s a net loss of 7%: far fewer than most forecasts, though still a significant job loss number.

The same ‘adjustment’ for job gains was also done in a 2016 report by World Economic Forum at Davos. “[D]isruptive labour market changes” (which includes not only AI, but other emerging tech such as 3D printing) could destroy 7.1 million jobs by 2020, while also creating 2 million jobs in smaller industry sectors. This means a net total of 5.1 million jobs lost.

There are some people who claim that we should not worry about robots because we’ll just create brand new jobs out of thin air. To me, they are behaving like a complusive gambler boasting about how he can earn $2.82 by simply gambling away $10.

In the long-term, perhaps, technology may finally erase the deficit in jobs and be seen as a net job producer. But that is exactly why we need to worry about this “transition period” to this ‘long-term’, whenever that may arrive.

How will this new joblessness come into being? Personally, I do not foresee a bunch of people getting laid off immediately. Instead, companies will gradually reduce their hiring. Why hire a new [PROFESSION_NAME_HERE] when you can just get a robot to do the job for you? Existing employees may be deemed ‘obsolete’, but will be retrained with new skills that cannot be automated (yet).

However, an academic paper entitled “The Labor Market Consequences of Electricity Adoption: Concrete Evidence From The Great Depression”, by Miguel Morin, does suggest that technological unemployment will indeed take the form of layoffs. During the Great Depression, the cost of electricity decreased for concrete plants. This increased the productivity of workers. Instead of increasing the production of concrete though, the concrete plants simply fired workers instead, thereby cutting their costs. The Atlantic also wrote several examples where technological unemployment occurred during times of recessions…when companies need to save money, humans get laid off and the cheaper bots come in instead.

I hope I do not need to write out why unemployment is not good.

The “AI Winter”

Artificial Intelligence is, ultimately, just a technology. And technologies can often times go through a ‘Hype Cycle’, as coined by the research firm Gartner.

At first, people become very interested in a brand new technology (a “Technology Trigger”). Companies start to over-invest in researching this technology, leading to a “Peak of Inflated Expectations” (i.e, a bubble). But the technology turns out to have major limitations. As a result, investment in the technology dries up (“Trough of Disillusionment”). Most companies either begin laying people off or closing down outright.

Eventually, the survivors soon realize how to use the technology properly (“Slope of Enlightenment”), and we can finally use the technology in our day-to-day life (“Plateau of Productivity”). But as this picture from Wikipedia shows, the visibility of the technology in the Plateau of Productivity is much less than the visibility of that same technology in the Peak of Inflated Expectations. The brand new technology has done great things for us. It’s just not as great as we hoped it to be. And does it justify the extreme waste seen in the “Peak of Inflated Expectations”?

If this is some hypothetical graph, then it’s not much to be worried about. But I have already lived through two tech bubbles: the dot-com bubble of 1997-2000 and the current unicorn bubble (ending this year, at 2016). A cycle of “irrational exuberance” (“Uber for [Plural Nouns]”) followed by layoffs can be never a good thing. Especially if you have to live with the consequences. Any actual benefit caused by this overinvestment is only incidental.

I’m afraid that this hype cycle can only get worse. The major reason the American Real Estate Bubble of 2005-2007 and the current unicorn bubble has grown as big as it did was due to a policy of ‘low interest rates’ pursued by central banks. Investors are ‘encouraged’ not to save money but instead to invest in risky ventures. The current interest in AI suggest that investors may view this new technology as yet another chance to make money. These investors will probably pour way too much money into AI research (if they haven’t started doing so already). And almost all of it will be exposed as wasteful in the “Trough of Disillusionment” stage.

So why do I call the “Trough of Disillusionment” an “AI Winter”? Because I didn’t come up with this name. It was invented in 1984. According to Wikipedia, the AI field had went through two major AI winters (1974-1980, 1987-1993) and several “smaller episodes” as well. Obviously our technology has improved. But human nature has not changed. If an AI bubble inflates, run.

Technological Dependence

Some people believe that AI could serve as a tool that can perform routine, autonomous tasks. This frees up human to handle more creative tasks. Darrel West, the director for technology innovation at the Brookings Institution, embodies this sentiment of techno-optimism by saying:

“It’s good that we’re figuring out how to use robots to make our lives easier. There are tasks they can do very well and that free humans for more creative enterprises.”

For example, robots are very good at writing 9-page textbooks.

Now, I understand that some textbooks can be dry and boring. But it is hard to say that they are not “creative enterprises”. Yet, if you click on my above link, you will actually see Darrel West’s quote, down to his very last words: “more creative enterprises”. Some human journalist told Darrel that a university is building a program that can write textbooks, and Darrel’s only response boils down to: “Oh, that’s cool. More time for creativity then.” (He also points to Associated Press’ own use of bots to write stories about sports to justify his viewpoint as well.)

Does Darrel consider the act of writing not creative then?

Here’s a dystopian idea. The term “creative enterprise” is a euphemism to refer to “any activity that cannot be routinely automated away yet”. Any task that we declare ‘a creative expression of the human experience’ will be seen as ‘dull busywork’ as soon as we invent a bot. We delude themselves into thinking we are still the superior race, while slowly replacing all our usual activities with a bunch of silicon-based tools.

This might be tolerable if your tools work 100% of the time. But abstractions are leaky. If you rely on your tools too much, you open yourself up to terrible consequences if you ever lose access to the tools or your tools wind up malfunctioning. And the worst part is that your tools may fail at the very moment your (human) skills has decayed. After all, you didn’t need to learn “busywork”. You focused all your efforts on mastering “more creative enterprises”.

This skill decay has already happened to pilots. Thanks to the glory of automation on airplanes, the US Department of Transporation believe that many pilots are unable to fly airplanes in times of crises. When autopilot works, then all is well. When autopilot fails, then there’s a real chance that the less capable human pilots make mistakes that winds up crashing the airplane.

Far from AI freeing us to pursue worthier endeavours, it can only make us more dependent on technology and more vulnerable to disasters when that technology breaks. The only good news is that we can reduce our dependency. For example, the US Department of Transportation recommends that pilots should periodically fly their airplanes manually to keep their own skills fresh.

Angst

It is not enough to build robots to handle the tedious tasks of interviewing human beings and hiring them to do routine tasks, but instead, “Algorithms Make Better Hiring Decisions Than Humans”. It is not enough to have a robot be able to cheerfully play board games and find creative strategies, but instead “Google’s AlphaGo AI beats Lee Se-dol again to win Go series, 4-1”. It is not enough to give video game AI the ability to simulate emotional decision-making by keeping track of a bunch of variables and behaving differently based on those variables, but instead “Researchers Make Super Mario Self-Aware”.

Now, some people may argue that these algorithms are not examples of “intelligence”. The obvious conclusion must be that hiring people, beating people at Go, and playing Super Mario must also not be tasks that require intelligence.

One of the problems with dealing with AI is the inherent vagueness of terms used to distinguish “us” (the humans) from “them” (the robots), leading to long and tedious arguments over whether this specific algorithm is an example of “true AI” without ever actually providing a decent definition of what is “true AI”. What hurts matters even more is the AI Effect, where the goal posts are constantly shifting in response to new advances in technology. If you design a test to determine what is “true AI”, and then a machine passes the test, a new test will just get created instead.

Apparently, you see, when they said “a machine will never be able to spot-weld a car together”, they meant to say “a machine will never be aware that it’s welding a car together”.

Some of the goal post shifting is justified: if we build something, we know how it works, and if we know how it works, we can see that it is artificial. And yet, again, at some point, the goal post shifting starts being seen as utterly ridiculous. Please don’t say the act of writing novels is not a sign of intelligence just because NaNoGenMo exists. (In fact, it is very possible that as AI improves, that we may be forced to confront the possibility that intelligence itself may not exist, which seems like a far worse fate than merely accepting the existence of AI.)

One way around this problem is to essentially refuse to mention the term AI at all, and instead use a more neutral term, such as machine learning or expert systems. “Yeah that robot may not meet my arbitrary definition of intelligence, but it is an expert in one specific domain area, and so I’ll defer to its expertise.” Yet the term of AI still continues to capture our imagination.

Why?

I think that our own ego is deeply invested in the idea that we are ‘special’, and that we are concerned when that ‘specialness’ gets challenged. Michael Kearns, an AI researcher at the University of Pennsylvania, claimed that “[p]eople subconsciously are trying to preserve for themselves some special role in the universe”, in an article about an AI being built to conduct scientific experiments.

Now Kearns doesn’t care about protecting the human ego. But I do. I don’t know what would happen to humanity when its self-image crumbles in the face of advanced machine capabilities. But I don’t think it’s something to look forward to.

Botcrime

Consider the following quotes from the botifesto “How To Think About Bots”:

The work and the legal response raise crucial questions. Who is responsible for the output and actions of bots, both ethically and legally? How does semi-autonomy create ethical constraints that limit the maker of a bot?

If you make a bot, are you prepared to deal with the fallout when your tool does something that you yourself would not choose to do? How do you stem the spread of misinformation published by a bot? Automation and “big” data certainly afford innovative reporting techniques, but they also highlight a need for revamped journalistic ethics.

Bots might be effective tools for guiding people toward healthier lifestyles or for spreading information about natural disasters. How can policies allow for civically “good” bots while stopping those that are repressive or manipulative?

And so on and so forth. There are obviously legitimate fears about bots doing evil, either due to its interactions with the outside world or because it has been programmed to do evil by another entity.

Raising questions about bot regulation is troubling though because they imply that these questions must be answered. They do not have to be answered now, of course. But they do have to be answered fairly soon.

Now only must they be answered, in the form of new government regulations, they must also be enforced. A law that is not enforced might as well not exist at all. Considering how successful we are currently in stopping preexisting spambots and social media manipulators, my hopes for effective enforcement of regulations is fairly low.

What is worse is the fact that people will stand in the way of regulations. The authors (all creators of bots) strongly support regulation…except when said regulation might be used against them.

Rumination on bots should also work to avoid policies or perspectives that simply blacklist all bots. These automatons can and might be used for many positive efforts, from serving as a social scaffolding to pushing the bounds of art. We hope to provoke conversation about the design, implementation and regulation of bots in order to preserve these, and other as yet unimagined, possibilities.

Again, a general blacklist of bots is a perfectly horrible idea (mostly because we cannot enforce it). But attempting to sort out ‘good’ bots from ‘bad’ bots seem like a rather dangerous and futile task. I can easily see the emergence of a “pro-bot” lobby that will stand against any but the most token of regulations, using doublespeak to claim that any use of technology has “positive effects”, while excusing away any problems the bots may cause.

Alternatively, we can also see bot developers pitted against each other, decrying other people’s uses of bots as being “negative” while championing their own use of bots as being “positive”. We need to have a legal system that can help evaluate whether bots are good or bad.

According to Ryan Calo though, the American legal system’s views about robots are outdated and ill-suited to our brave new world. Judges generally see robots as “programmable machine[s], by definition incapable of spontaneity”, and ignore possible ‘emergent properties’ that can exist when robots interact with society as a whole.

Ryan Calo support the creation of “a new technology commission, a kind of NASA-for-everything that can act as a repository of knowledge about robots to guide legal actors, including courts”…but this commission seems very similar to that of an interest group, and one that may only have the interests of robot developers at heart, not that of society.

It will take time to come up with the right balance between bot freedom and bot banning, if there really is any.

Conclusion

In 2016, Evans Data conducted a survey of 500 software engineers to find out what they feared the most. The largest plurality (29.1%) said that they feared AI taking their jobs. What’s worse is that over 60% of software engineers thought that AI “would be a disaster”.

This does not mean that these software engineers are Luddites. “[O]ver three-quarters of the developers thought that robots and artificial intelligence would be a great benefit to mankind”, claimed Janel Garvin (the CEO of Evans Data). “Overlap between two groups was clear which shows the ambivalence that developers feel about the dawn of intelligent machines. There will be wonderful benefits, but there will also be some cataclysmic changes culturally and economically.”

There has been a lot of coverage about the rise of AI and its ‘wonderful benefits’. The goal of this post is to illustrate the ‘cataclysmic changes’ and thereby make a implicit argument against AI.

The dangers of AI are great, and we should not let the potentials of AI blind us to real risks. There are some solutions to help manage AI risk that I proposed in the past, but probably the most practical and sensible solution at the moment is to slow down AI development and think through these risks carefully. By slowing down progress, we can ensure that the changes won’t be so “cataclysmic”, and that humanity can survive intact.

A few days ago, I read a blog post titled “Write code that was easy to delete, not easy to extend”. At the top of this blog post was a quote…

“Every line of code is written without reason, maintained out of weakness, and deleted by chance.” Jean-Paul Sartre’s Programming in ANSI C[1]

I was so fasinciated by this profound quote that I didn’t even bother reading the rest of the blog post and decided to find this obscure book and read it myself.

I don’t agree with all of what Sartre has written; his ideas about individualism reads a bit too utopian for my tastes. However, his ideas are still interesting to read. Here are a few choice quotes from the book.

• “Ah! How I hate the crimes of the new generation: they are dry and sterile as Assembly.”
• “A programmer is condemned to be free; because once thrown into the codebase, he is responsible for everything he does.”
• “Intellectuals cannot be good revolutionaries; they are just good enough to be programmers.”
• “If you want to deserve Hell, you need only stay in bed. The codebase is iniquity; if you accept it, you are an accomplice, if you change it you are an executioner.”
• “You must be afraid, my son. That is how one becomes an honest programmer.”
• “The more one is absorbed in fighting bad programming, the less one is tempted to write good programs.”
• “Do you think you can program innocently?”
• “As far as programmers go, it is not what they are that interests me, but what they can become.”
• “A programmer cannot will unless he has first understood that he must count on no one but himself; that he is alone, abandoned in the codebase in the midst of his infinite responsibilities, without help, with no other aim than the one he sets himself, with no other destiny than the one he forges for himself in his IDE.”
• “I do not give a damn about the previous programmers. They died for the codebase and the codebase can decide what it wants. I practice a live man’s politics, for the living.”
• “We programmers exist, that is all, and I find it nauseating.”
• “How can I, who was not able to retain my own past knowledge of the codebase, hope to teach another?”
• “I embraced Agile because its cause was just and I will leave Agile when it ceases to be just.”
• “Ah! Do not judge the gurus, young man, for they too have painful secrets.”
• “If a victory is told in detail, one can no longer distinguish it from a defeat.”
• “I respect orders but I respect myself too and I do not obey foolish design patterns made especially to humiliate me.”
• “What do you want to do with the language? Write Fizz-Buzz? What good is it to sharpen a knife every day if you never use it for slicing? Code is never more than a means. There is only one objective: power.”

[1]”Jean-Paul Sartre’s Programming in ANSI C” is a fictional book. The philosopher himself is real, as are the quotes, but almost all of them were modified to take into account the subject matter of programming.

Yesterday, while reading an old computer science textbook “Programming and Problem Solving with C++”, I saw a chapter on “Abstract Data Types” (ADTs) and was instantly curious. So I read the chapter, hoping to learn about this strange and mysterious things. I was surprised to find out that ADTs are not strange and mysterious at all. In fact, I have been writing them in my programming career.

An ADT is any entity that contains data and specified behavior (methods/functions). For example, let us define a simple Bank Account ADT. This is a “specification” (a detailed list of what we want our ADT to do):

1. We should store how much money is in the account.
2. We can withdraw money from this account.
3. We can deposit money from this account.
4. We know how much money is in the account.

And here’s an example of the Bank Account ADT, coded in Ruby…

class BankAccount attr_reader :current_funds

def initialize(amount)
  @current_funds = amount
end

def withdraw(amount)
  @current_funds -= amount
end

def deposit(amount)
  @current_funds += amount
end   end </code>

That’s it.

Now, you may not like how I wrote this ADT. Perhaps you prefer not using classes and may wish to use a more “functional” approach to programming. Or maybe you just want to write this ADT in a different language.

That’s perfectly fine. Code the way that you wish. As long as you follow the specification listed above, the ADT is still valid. Your version of BankAccount is just as valid as mine. The implementation of an ADT is seperate from the specification of an ADT. That’s why it is possible to refactor your code…so long as your code behaves the same way before and after the refactor.

Now, the mind-blowing part is that you can build ADTs…using ADTs. Suppose I want to create a Bank ADT that can store Bank Account ADTs, and I want to know how much money the Bank ADT has.

class Bank

def initialize(array_of_bank_accounts)
  @accounts = array_of_bank_accounts
end

def total_funds
  sum = 0
  @accounts.each do |account|
    sum += account.current_funds
  end
  sum
end

end </code>

“Programming and Problem Solving with C++” recommends the use of ADTs because it makes programs simpler and easier to understand, thereby making code easier to write. The book uses an example of a car to illustrate its point:

“With abstraction, we focus on the what, not the how. For example, our understanding of automobiles is largely based on abstraction. Most of us know what the engine does (it propels the car) but fewer of us know-or wnt to know-precisely how the engine works internally. Abstraction allows us to discuss, think about, and use automobiles without having to know everything about how they work.

And programming makes use of abstractions heavily, with some languages being entirely built on other languages. Ruby, for example, is built on C. Abstraction serves as a great way to manage complex code bases…and ADTs are the living paragons of abstraction.

But abstractions are ‘leaky’. What if there is some bug in my BankAccount ADT? That bug would harm my Bank ADT as well…and could even harm any ADTs that were built on top of my Bank ADT.

So while ADTs are useful, you cannot be totally dependent on them. You have to be willing to look at the internal code of an ADT you’re using and be able to debug it.

It is not enough to know how to program using abstractions. You must also know how to program the abstractions themselves.

As technology advances, so too does the capabilities of robots. As a result, some philosophers wondered whether robots may one day acquire ‘rights’ equal to that of their human brethren.

In 2015, Time Maganize asked the question: “Will Robots Need Rights?” It also posted the answers of three people:

• David Gelernter claim that robots are unlikely to gain rights because they lack consciousness. However, people should still treat robots humanely.
• Ray Kurzweil states that consciousness is not scientifically testable, and thus would have to defined through philosophical arguments. Ray argued that robots will have rights once they are able to convince us that they deserves rights.
• Susan N. Herman, President of the ACLU, suggest that the ACLU might defend robot rights if robots share the same sensibilities as human beings, but would first have to argue deeply over what types of rights robots should get.

All three answers show a sympathetic outlook towards robots, treating the concept of “rights” as something to seriously consider as we deal with potential alien-sque entities. And while I support respecting robots as “potential alien-sque entities” instead of treating them as “just tools” to be used and abused, I believe that the case for robotic rights has been vastly overstated (and you don’t even need to bring in the nebulous idea of consciousness into the discussion).

In this blog post, I will lay out a hardline case against robotic rights. It’s not a case I fully belive in myself, but it’s a case that I believe that most people will end up using. Note that my argument is only against robot rights; it is silent on the question on whether humans have rights.

Premise

I rest my case on the premise that rights can only belong to entities that are able to exercise some control over their own actions and motives. I call these entities “autonomous actors”, to avoid any confusion with the term “autonomous agent”.

The Lovelace Test

The original Lovelace Test, outlined in “Creativity, the Turing Test, and the (Better) Lovelace Test”, was meant as a way to determine whether programs are intelligent. A program is intelligent if and only if it did all these things:

1. The program must be able to design something ‘original’ and ‘creative’ (such as a story, music, idea, or even another computer program).
2. The program itself is a result of processes that can be ‘reproduced’. (In other words, it does not rely on some bug in the ‘hardware’ that the program is running on.)
3. The program’s creative output must not be a result of bugs within the program itself.
4. The programmer must not know how the program actually works.

Criteria #4 is the kicker though. It is very possible for programs to design ‘original’ and ‘creative’ work. After all, robots are already writing fiction and nonfiction stories. But the programmers themselves know how the robots are able to produce creative outputs. Therefore, all of these programs fail the original Lovelace Test.

Even an algorithm that uses “machine learning” is unable to pass Criteria #4, as it can be argued that the programmers are able to control the robot by controlling the dataset the robot uses to understand the world. Thus, you can explain the robot’s creative output by deducing the dataset that it used.

In fact, the whole point of this original Lovelace Test is to argue against the idea that robots could ever be intelligent, by arguing that robots ultimately need programmers. Mark O. Riedl wrote that “any [programmer] with resources to build [the program] in the first place … also has the ability to explain [how the program generates the creative output]” [1].

I disagree with the original Lovelace Test, because it claims that intelligence is a trait that either exists or doesn’t exist. I prefer to think of intelligence either in terms of a continuum or through the idea of multiple intelligences.

But I think the original version of the Lovelace Test is useful when thinking about robotic rights. Robots do what programmers tell them to do. They do not have any independent ‘will’ of their own. Robots are essentially puppets. It’s hard to consider them autonomous actors, because there is always someone behind them (either a human or a dataset) pulling the strings. And we can see those strings.

The Parable of the Paperclip Maximizer

That doesn’t mean programmers has total control over these robots. Sloppy code, bad planning and codebase complexity can lead to unexpected outcomes.

Given enough time and patience, a programmer should be able to figure out why his code lead to the outcome that it did. If a problem is big enough though, practically speaking, many programmers will not have the time or patience. Shortcuts are taken. Rationalization sets in. Ignorance is accepted as best practice.

For example, I can easily imagine a lazy programmer write the following code before going to bed…

1. Produce as many paperclips as physically possible.
2. Increase your processing power so that you can more effectively produce paperclips.

…and thereby destroy humanity because his ‘Paperclip Maximizer’ has decided to turn the entire solar system into paperclips and computer mainframes.

But this is not an “artificial intelligence” problem. It’s a “human stupidity” problem. The programmer wanted to produce paperclips and did not think through the consequences of his code. The ‘Paperclip Maximizer’ simply followed orders.

The programmer, if he did think through his code carefully, would have likely noticed problems. But, of course, he had other priorities. He had to go to sleep so that he can be well-rested the next day to watch Netflix movies and contribute to open source projects. And his code was so elegant, and it passed all his automated tests. He had nothing to worry about.

So he goes to sleep and never wakes up.

Robots Follow Orders, Only We May Not Know What Those Orders Mean

A programmer may not know exactly why a program is doing what it is doing…but he has the theoretical capability to find out for himself (since, you know, the programmer wrote the program). And he should at least attempt to do that, so that you can reduce the chances of scenarios such as the above parable.

But what if a programmer is unable (or unwilling) to do this? Does the robot deserves rights then?

No. The programmer had the capability to understand what a robot is doing. He just decided not to use it. But the fact that the programmer could have found out suggest that the robot is not an autonomous actor.

The robot simply follow orders…only in this specific case, they are orders that we do not quite fully understand ourselves.

For debugging purposes, we should hire another programmer who will be more willing to figure out why the robot is acting the way it is. After all, if one human has the theoretical capability to find out what a robot is doing…then it is likely that another human will eventually gain that same theoretical capability.

Conclusion

If we want robots to actually think for themselves (instead of just being puppets of datasets and human programmers), we have to turn robots into autonomous actors. As the original Lovelace Test suggest, this is an impossible goal. If we are able to write a program, then we should be able to also know how that program works. There is no autonomy to be found anywhere.

If robots can never be free, then they can never deserve rights.

Footnotes

[1] Incidentally, Mark O. Riedl proposed a less strict version of the Lovelace Test, the Lovelace 2.0 Test, as a test that can actually be beaten. Instead of mandating that the programmer remain ignorant of the inner workings of his program, the program’s creative output must meet certain constraints as determined by an independent judge.

Though we are able to teach robots how to write as well as a human, we may have difficulty teaching them how to view the world as a human.

Computers are learning how to write. It’s not considered weird or bizarre anymore to see companies like Narrative Science and Automated Insights be able to generate news reports covering topics as broad as sports and finance. Automated Insights have also made their “Wordsmith” platform publicly available, meaning that anyone have the potential to command their own robotic writers, without any programming knowledge.

Human journalists have been able to accept their robo-journalistic brethren under the mistaken impression that robo-journalists will be regulated to writing “quantitative” articles while humans will have more time to write “qualitative” analyses. But you can indeed turn human experiences into quantitative data that a robot can then write. For example, “sentiment analysis” algorithms are able to determine whether a certain article is happy or sad, based on analyzing what words were used. The output would be a qualitative judgment, based solely on quantitative data. Narrative Science has already explored the possibility of moving onto “qualitative” analyses by creating “Quill Connect”, a program that is able to write qualitative analyses of Twitter profiles.

Algorithms are not limited to writing nonfiction. Every November (starting from 2013), programmers participate in a competition called National Novel Generation Month; the goal is to write a fictional novel of 50,000 words or more. Some of these generated novels are generally dull, but readable (examples: “Around the World in X Wikipedia Articles”, “A Time of Destiny”, “Simulationist Fantasy Novel”). They have the plot, characterization, and imagery that you would normally associate with a human-written work. Programmers will have to put in more effort for computer-generated novels to be on-par with human-produced literature, but there does not seem to be any inherent limit to algorithmic creativity.

Of course, one could argue that robots will never be able to replace humans at all. Robots are reliant on “templates” to help them organize their stories properly, and humans are the ones in charge of designing the templates that the robots will end up using to write. In this viewpoint, humans would willingly give up the ability to write since they can find it a much more rewarding task to simply instruct the computer how to write a certain story.

But I would argue that even if humans would want to outsource all writing to their robotic slaves, humans will still write out some of their ideas out by hand…because of an inherent limitations of bots. Bots lack the “worldview” of humans.

Humans take for granted their ability to perceive the world. Their five senses gives a continual stream of data that humans are able to quickly process. Bots, on other hand, are only limited to the “raw data” that we give them to process. They will not “see” anything that is not in the dataset. As a result, how the bots understand our world will be very foreign to our own (human) understanding.

For some people, this is actually a benefit that bots bring to writing. Bots will not have the same biases as human beings. They will therefore discover new insights and meanings that humans may have overlooked. However, bots will instead bring their own unique ‘biases’ and issues into their work, and humans may not tolerate the biases of algorithms as much as they would tolerate the biases of other humans. Humans will, of course, still happily read what the bots have to say. But they also want to read what humans have to say too.

Humans will likely tolerate the rise of automation in literature, and accept it. Bots may even write the majority of all literature by 2100. But there will still be some marginal demand for human writers, simply because humans can relate more to the “worldview” of other humans. These human writers must learn how to coexist with their robotic brethren though.

This article was originally published by me on LinkedIn as “Why Robots Will Not (Fully) Replace Human Writers”.

Writing SQL can be a painful experience. But there are two shortcuts that can be used to make your code easier to type. Both shortcuts are cool to understand, but only one is actually advised by the broader “SQL community”.

I was inspired to write this blog post while completing Codecademy’s tutorial “SQL: Analyzing Business Metrics”. In one exercise in the tutorial, I had to write an SQL query to find out how many people are playing a game per day. This was the query I wrote:

SELECT date(created_at), count(DISTINCT user_id)
from gameplays
GROUP BY date(created_at)
ORDER BY date(created_at);

And this is the resulting table…

date(created_at)	count(distinct user_id)
2015-08-04			99
2015-08-05			117
2015-08-06			106
...

But the SQL query is too verbose and unclear. Could there be a simpler way to refer back to ‘date(created_at)’? Codecademy suggest using “ordinals”. Ordinals are numbers that are used to refer to the columns you are ‘selecting’ in an SQL query.

Here’s an easy diagram to determine the ordinal number of a SELECT query…

SELECT date(created_at), count(DISTINCT user_id)
       ^^^^				 ^^^
       1                 2

By using ordinals, we can simplify our original SQL query as follows:

SELECT date(created_at), count(DISTINCT user_id)
FROM gameplays
GROUP BY 1
ORDER BY 1;

This approach seems less verbose, but it is actually much more unclear. At first glance, it is impossible to know what “1” is supposed to mean. And if someone decides to switch the order of the SELECT query (putting “count(DISTINCT user_id)” first), the resulting table will be messed up.

There has to be a better way.

And there is. SQL Aliases. Aliases work the same as variables in other programming languages, and to define an alias in SQL, you simply write “AS [alias_name]”. Aliases ensure that your SQL code will be self-documenting, while also ensuring that your code would be less verbose.

Here’s an example of me defining aliases in an SELECT query, and then using them later on:

SELECT date(created_at) AS time, count(DISTINCT user_id) AS daily_users
FROM gameplays
GROUP BY time
ORDER BY time;

An interesting side note is that by defining variables in the SELECT query, you also change the name of the columns in the resulting table…

time				daily_users
2015-08-04			99
2015-08-05			117
2015-08-06			106
...

The main reason Codecademy teaches the use of ordinals is because it was traditionally used during the early days of SQL programming. Thus, knowing ordinals will allow you to understand and debug any legacy SQL queries you encounter.

However, the broader SQL community strongly discourages the use of ordinals because of the confusion and problems that they may cause. Instead, the SQL community suggest using aliases to make your code clearer and easier to understand. Following these recommendations would make sure that when you do deal with SQL, your pain would be minimal.

In the past, I wrote about Yali Pali’s paper about the lifecycle of intellectual fads. I am curious about fads because the programming field seems prone to them, and it’s important to avoid fads at all costs. Today, I learned two new ways to explain fads, after reading When a Fad Ends: An Agent-Based Model of Imitative Behavior by Margo Bergman.

Pali focused his studies on academica and claimed that “intellectual fads” followed this pattern:

1. A new field is developed.
2. People see that the field has no experts yet (since it is a new field).
3. People rush to be a part of the hot new thing, with the goal of becoming prestigious experts.
4. A few people ends up becoming experts.
5. Everyone else gets bored and leave. The fad ends.

This approach seems to make sense for explaining fads in programming, since it implies why certain languages, frameworks, and even methodologies may rise and fall in popularity. But what if programming is not structured like academia? What if languages/frameworks/methodologies are not specialized fields of interest but instead tools that can be switched in and out? Then it may be important to view fads in programming as being about ‘products’, not about ‘intellectual pursuits’. Bergman’s paper only discusses product fads (and I have taken the liberty of using term “product” with “tool” interchangeably).

When Bergman wrote her paper, she argued against “information cascades”, a theory developed in economics in the 1990s that also purports to provide a lifecycle for fads. An “information cascade” has these stages:

1. People are given a choice to accept or reject a tool. Since they lack complete knowledge about whether that tool is good to use, they rely on other signals from previous “adopters” of the tool.
2. The signals from previous “adopters” show that the tool is indeed good. Therefore, people end up adapting the tool.
3. The tool actually turns out to be terrible.
4. When people learn that the tool is terrible, they stop using the tool. The fad ends.

Bergman does not like this theory though because it implies that fads are always around ‘bad’ tools. For example, Hula Hoops, miniskirts, and Rubik’s Cubes are not “bad” products by any means, yet they were all examples of fads.

Bergman instead argued that people can be divided into two groups:

• Fad Setters are people who are always looking out for the next best thing. According to Bergman, they “specialize in the discovery of new products” and “are known to be the people who others wish to emulate”. Fad Setters do not care about what other Fad Setters do and are independent.
• Fad Followers are people who want to use the next best thing, but do not know how to find it. So they instead rely on the preferences of Fad Setters. Whatever a Fad Setter wants, the Fad Followers will want too.

Fad Followers do not need to know the exact identity of a Fad Setter to decide whether to buy a product. Instead they look at the behavior of other people, some of whom may potentially have access to the knowledge of a Fad Setter. They can then copy the behavior of those other people, and thereby indirectly emulate the Fad Setter.

Bergman’s fad theory has these stages:

1. A Fad Setter finds a product, finding it novel and new. He starts using the product.
2. Fad Followers end up emulating the Fad Setter by using that product too.
3. When too many Fad Followers use the product, the Fad Setter gets disgusted. The product is no longer novel or new enough for him to use. The Fad Setter leaves the product.
4. Fad Followers also leave the product, thereby emulating the Fad Setter.

Bergman also discussed ways to prevent fads from occuring.

• First, there may be multiple Fad Setters using different products and competing with each other. No one product would become popular enough to inspire “disgust” in the Fad Setters (as all the Fad Followers would end up following different Fad Setters). These products thereby continue to stay popular, and avoid having to face the downturn that a fad normally faces.
• Second, a Fad Setter may get disgusted easily and leave a product as soon as Fad Followers starts getting interested. This stops a fad from rising.

I tend to not like Bergman’s theory all that much, because it seems to imply that most people are lemmings, who only follow Fad Setters without any regard to whether the product is actually good. It also implies that Fad Setters are themselves not interested in whether the product is actually good either, and only choose products based on whether other people are not using them. Yet whether I like it has no bearing on whether it is true or not, and it does seem plausible that programmers are tempted to “follow the crowd” and listen to gurus. I’m not sure whether the gurus themselves are as flaky as the term “Fad Setters” imply.

Surely, more work has to be done to determine whether Pali’s theory, “Information Cascade” theory, or Bergman’s theory is the correct way to explain the presences of fads in programming. Or maybe all three approaches are correct. I just don’t know yet. I do know that the ‘life cycle’ of a fad is an important topic that I have to keep in mind when evaluating the “next hot thing” in programming. As I wrote in a previous blog post:

“As beginning programmers, we do not have the time or the money to be chasing fads. We want to specialize in the fields that (a) we like and/or (b) will be popular for a long time. Understanding these fads is important, simply so that we can spot them and avoid them.”

For a recent coding challenge, I had to implement an AI for a Tic-Tac-Toe game. This AI should not be able to lose a match. A quick Google search reveals that the most efficent way is to use a minimax algorithm to determine what moves are likely to cause the AI to either tie or win against another player. However, nobody I found seemed to analyze what decisions the AI actually makes.

The minimax algorimth works by having the computer play Tic-Tac-Toe against itself, figuring out the best moves to use against itself…and then figuring out the best counters to those moves, and so on and so forth. It will then rank all the possible moves it can take:

The AI will pick the move that has the highest score.

Therefore, the computer will play perfectly and never lose. It may never win either though, if the human it is playing against is also playing perfectly.

But there is an extreme amount of trust in how the Minimax Algorithm works. There is a lot of literature examining how to program the algorithm, and very little literature on what choices the algorithm ends up making. I assume that most people assume that since the algorithm will choose the best possible move for Tic-Tac-Toe, examining what moves it actually picks would be a waste of time.

But the problem is that the computer has to play through every possible game of Tic-Tac-Toe before it can make its choice. This is not an instantaneous process. For the worst case scenario (where the AI goes first, and thus must play through all Tic-Tac-Toe games), I had to wait 114 seconds for a response from the AI. This is absurd.

There are ways to reduce the number of games a computer has to play through (since many Tic-Tac-Toe games are really just duplicates of each other, with the boards being rotated)…but there had to be a better way to make the game go faster.

I decided to look “under the hood” of the AI, because I was curious in seeing how the AI thought for itself. I soon realize that if I know that the AI is thinking, I could ‘hardcode’ in the AI’s choices. The AI will just end up doing its move rather than spending 114 seconds learning to do that same move.

In the following terminal outputs, O is human and X is the computer. I also output a Hash showing the computer’s thought process (“MOVE”=>SCORE).

So here’s three starting scenarios:

O goes first and pick a corner space.

It is now X’s Turn.

{“0”=>-10, “1”=>-10, “2”=>-10, “3”=>-10, “4”=>0, “5”=>-10, “6”=>-10, “7”=>-10}

X has picked Spot 4. </code>

The computer will choose the space that has the highest score. In this case, every space other than 4 has a score of -10. The only space that allows the computer to tie the human player is 4, the spot right in the middle. So X picks that.

O goes first and pick a edge space.

It is now X’s Turn.

{“0”=>-10, “1”=>0, “2”=>-10, “3”=>-10, “4”=>0, “5”=>-10, “6”=>0, “8”=>0}

X has picked Spot 1. </code>

In this case, now, there are four moves that may lead to a tie: 1, 4, 6, and 8. Any other move will lead to the computer’s loss.

But it does not matter how the computer gets to that tie. A tie is a tie. So the computer can easily pick any move that leads to a tie, and the outcome will always be the same. In this case, the computer just choses Spot 1.

What happens if I let the computer go first?

{“0”=>0, “1”=>0, “2”=>0, “3”=>0, “4”=>0, “5”=>0, “6”=>0, “7”=>0, “8”=>0}

X has picked Spot 0. </code>

None of the spaces are any more advantageous than the others. No matter what move the computer picks, a tie will result. So the computer could pick literally any move and be ensured that the other player won’t win. In this case, the computer choses Spot 0.

I now know that the computer sees the space “4” as an excellent move to make, no matter whether O goes first or second. (Other moves can be just as excellent as “4”, but “4” will always be excellent.)

I then programmed the computer to always pick “4” as its first move. The minimax algorithm would still be used after the first move though. After the first few moves, the number of possible Tic-Tac-Toe games decreases, and so the minimax algorithm is speedy enough for the user to not be annoyed.

Result: The AI is still unbeatable, but now the game is faster to play! It takes less than a second for the computer to make its first move, and its second move against the player is still just as fast.

It is cool to have the AI think how to beat its opponent. But just because something is cool does not mean that it is necessary or worthwhile in the real world. Thinking takes time, and a user is not going to be happy waiting for 114 seconds while the computer figure out what it should do next. Hardcoding in the AI choice ensure that the game runs faster. And since the hardcoded choice is actually based on the results of the minimax algorithm, we are not risking the chance of the AI losing.

Automated Insights and Narrative Science are two companies that specialize in producing software that can write news articles. But how do these news articles stack up to the human-written competition? A German researcher attempts to find out.

In the peer-reviewed article “Enter the robot journalist: users’ perceptions of automated content”, researchers randomly gave German undergraduate students one of two articles. One article was written by a human, and another was written by a program called “Statsheet” (which was created by Automated Insights). The German students were to read the article, rate it, and then say whether the article was written by a human being or a bot.

The researchers asked two questions:

1) Can the research students consistently identify whether an article is written by a human or a bot? - The answer is a resounding “NO”. While a majority of students correctly identified the bot-written article as being written by a bot, a majority of students also identified the human-written article as being written by a bot. There is no statistically significant difference between how the students ‘evaluated’ whether the article was written by a human or a bot.

2) Are bots able to write prose of equal quality and crediblity as that of humans? - The answer is “Yes, with one exception”. There was no statistically significant difference between the quality of the journalism of the human and the bot…except for the fact that the human’s article was seen as more pleasant to read.

(As a tangentical side note, the students rated the bot’s article was being more informative, accurate, trustworthy, and objective…though the bot’s article was also rated as more boring to read too. The students also rated the human’s article as being well-written and coherent.

The reason this note is tangentical is that these results are not “statistically significant”; if you were to run this same experiment with a different population, you would likely get different results.)

Conclusion: The “robojournalists” are able to produce journalism that is able to equal that of the human competition. There are limits to the robojournalists though. They are unable to write prose that is ‘pleasent to read’. This may be a sign of limits to robojournalists’ creativity, which would give humans the edge. For now.

“Practical Artificial Intelligence for Dummies: Narrative Science Edition” is a free e-book that provides a quick introduction into the AI field. It is also a treatise that outlined Narrative Science’s approach towards dealing with AI.

One of the taglines of this e-book is that it will “demystify the hype, fear, and confusion about AI”. Though the book primarly focused on explaining AI, it did pay some attention to the ‘fears’ within popular culture, and attempted to address them in a “roundabout” way, without necessarily rebutting any specific fear.

Narrative Science believed that AI only need to display intelligent behavior, and not necessarily need to think like human beings. As a result, Narrative Science concluded that technologies that humans take for granted are already AI. Voice recognition, recommendation engines, autocompletes, etc. are all commonly accepted within society, and yet all of these algorithms display intelligent behaviors.

But these AI programs do not seek to take over the world or render people unemployed. Instead, these programs are just tools, there to help humans accomplish their day-to-day tasks. People are still in control and still receiving regular paychecks; all the AI did just made their lives easier. Narrative Science concluded that this trend would continue, and future AI programs will simply help humans instead of displacing them.

If that was the crux of Narrative Science’s argument, then I don’t think this book’s philosophy would have been interesting enough to blog about. But Narrative Science also surprisingly expressed some concern about AI proliferation. Narrative Science fears black boxes: AI programs that are able to give answers but fail to provide explainations for why it came up with those answers.

Black boxes are not hypothetical concerns. Self-learning entities are being built and used already, such as “evidence engines” (IBM’s Watson) and deep-learning networks (‘neural networks’). These entities are able to learn about the world, but they cannot tell other people how they learn the world. You ask them a question, and all they give you an answer…with no context or reasoning behind the answer.

Black boxes ruin trust. If you do not know how the AI came up with the answer, you cannot trust whether the answer is actually correct[1]. Without trust, AI loses their potential as useful tools for humanity. A calcuator that gives the wrong answer every 30 minutes is not a very useful calcuator.

Narrative Science claims that the best way to preserve trust in AI (and to keep their status as useful tools) is to enable the AI to communicate its internal thought process to human beings. That way, we can evaluate the AI’s thought process and decide whether it is correct or incorrect. Narrative Science has already implemented a “logic trace” within its own AI program, “Quill”, allowing people to understand why the AI program had made the choices that it did. Quill is currently being used to write newspaper articles and financial reports.

As black boxes are used in more and more critical industries, Narrative Science’s apprehension about them will only grow. Narrative Science recommends that other companies also implement “logic traces” in their own AI programs as a way to counteract the possibility of ‘black boxes’. Already, Google has tried visualizing how its own black boxes works through its “Google Dreams”. More work will have to be done to deal with the dangers of of black boxes..

[1]The alternative is to implicilty trust the AI’s thought process…but when the AI inevitably make mistakes, you will not know how to prevent it from making future mistakes.

Correction - On Janurary 17, 2016, this article was updated to correct mistaken impressions about Narrative Science.

Devbootcamp does not have a conventional ‘final exam’ like most schools. Instead, to graduate from the program, you must work with a team of like-minded individuals to build a full-blown website within 7 days. This was my experience in trying to build Hashography, a website that would display tweets about a certain word onto a Google Map.

Our project lead, Evangeline Garreau, was inspired by a news article about a professor who was able to trace the usage of certain words on Twitter and develop a heat map displaying his results. Evangeline found the system cool and wanted to replicate that with a website that would display the history of word usage throughout the entire world.

At first, the whole team was excited about the project. We wanted to determine the history of a word and be able to trace it from the very beginning. We also wanted to know where the words were being used, not just in the US, but globally. We had big dreams and aspirations for how to interpret the data and display it on a “heat map”. All we had to do is just to grab those Tweets from Twitter.

But then those big ideas faced “technical limitations”, which would be a euphemism for “cold hard reality”. The best way to grab data from Twitter is to use an API. An API is a tool that enables websites (like Twitter) to communicate with other programs and websites (like “Hashography”). Twitter has two such APIs: a “REST API” that allows us to access past tweets, and a “Streaming API” that allows us to view present ‘real-time’ tweets.

It turns out that they were inherent limits to the Twitter REST API…such as the fact that Twitter would only allow us access to the last 7-10 days of Tweets. It also turns out that the professor that inspired Evangeline likely used the “Streaming API” for an entire year in order to grab the tweets necessary for him to discover the history. This option was incredibly impractical for our week-long project.

Our passion for the project turned into panic. We tried searching for alternative ways of meeting our project. We looked at Google Trends, which gave us all the data we need to trace the history of the word usage…except that if we end up using it, we would be pretty much copy Google Trends. We tried switching to a multimiedia approach that would use Instagram’s photographs to present a history of the word, except Instagram’s own API gave us trouble too. At some point, some members of our team even half-jokingly supported violating Twitter’s Terms of Service agreement by building robots that would “scrape” tweets.

We floundered horribly.

By Friday afternoon, it was agreed that we had to pivot away from the original idea behind the project. The group overall came to an agreement that it was more important to see where tweets are located rather than see the “history” of the word (after all, Google Trends already gave us a good history of the word). We decided to use the Twitter Streaming API to grab current tweets of a word and then display them onto a map. We also decided that we never really liked seeing “heat maps”, and switched to displaying data as points on a Google Map.

At the time, it seemed that we had “lost time”, as we spent two days without any “progress”. But we have learned a lot more about our tools and our limitations, enabling us to catch up quickly. We also were more willing to try everything possible to resolve any disaster that would confront us, including preparing backup plans in case our current “course-of-action” was not working. We ended up producing a workable website by Sunday, and started polishing and improving on it.

True, we still had problems after Sunday. We did not have enough automated tests and had to waste valuable time manually testing changes. We needed to learn the “best practices” for the new tools we were using. We needed to refactor our code constantly. We had trouble with designing our website to be user-friendly. But those were problems that we could fix as part of standard maintenance, and they were much easier problems than trying to build the website in the first place. The very act of having a physical web presence gave the team a big morale boost.

User feedback was excellent, and people saw our program as being ‘beautiful and meaningful’. Our “pivot” was a success.

Why was it a success? For me, I think it was just due to the fact that we panicked realized the extent of our situation early, and thus was more willing to do “whatever it takes” to accomplish our goals, including changing our goals to something more feasible. Our project lead, Evangeline Garreau, would instead likely credit the fact that we had good group dynamics and that we respected each other’s ideas. (Of course, both thoughts may be true.) And, of course, we may have just been lucky.

Overall, we did a good job with this website, and it showed us ultimately that we can still produce beautiful and meaningful work without necessarily staying true to the original idea. We were humbled by the experience, and only by being humble can we begin to learn from our surroundings. We had fun, and we learned a lot.

In my previous blog post, I wrote about two tests used to determine whether AI is intelligent. However, it turns out that I did not fully understand one of those tests: the Lovelace Test.

The Lovelace Test was named after Ada Lovelace (the first computer programmer) who argued famously that computers will only follow instructions that programmers give it. According to my summary of this test, a program must match the following criteria:

“1. The program must be able to design something ‘original’ and ‘creative’ (such as a story, music, idea, or even another computer program).

1. The program itself is a result of processes that can be ‘reproduced’. (In other words, it does not rely on some bug in the ‘hardware’ that the program is running on.)
2. The programmer must not know how the program actually works.””

I thought that this test is flawed because it excludes the possibility of bugs or programs being so overly complex that a programmer would not be able to understand them.

But it turns out that my summary of this test was based on a Vice article, which neglected one additional criteria: the program must not be a result of bugs. In the original paper “Creativity, the Turing Test, and the (Better) Lovelace Test”, the authors specifically addressed the idea of bugs, and why their presence does not mean intelligence.

“Sure, we all know that computers do things we don’t intend for them to do. But that’s because we’re not smart and careful enough, or — if we’re talking about rare hardware errors — because sometimes microscopic events unfold in unforeseen ways. The unpredictability in question does not result from the fact that the computer system has taken it upon itself to originate something. To see the point, consider the assembling of your Toyota Camry. Suppose that while assembling a bumper, a robot accidentally attaches a spare tire to the bumper instead of leaving it to be placed in its designated spot in the trunk. The cause of the error, assume, is either a fluke low—level hardware error or a bug inadvertently introduced by some programmers. And suppose for the sake of argument that as serendipity would have it, the new position for the tire strikes some designers as the first glorious step toward an automobile that is half conventional sedan and half sport utility vehicle. Would we want to credit the malfunctioning robot with having originated a new auto? Of course not.”

Under this idea, the Lovelace Test does indeed have meaning. It may be impossible to actually pass (as originally designed), as I actually do support Ada Lovelace’s contentions that computer programs only do stuff we tell it to do. But I do not think that the ability to tell programs what to do automatically renders programs non-intelligent. Even intelligent species like humans have to receive instructions and learn from other intelligent beings.

But at least the test has rational and logical meaning, and places a higher barrier than the Turing Test. So this blog post is an apology of sorts for misrepresenting the Lovelace Test in my previous post. If you do agree with the premises of the test, then it would serve as a valid way of determining intelligence. That being said, this passage on bugs raises three questions about the Lovelace Test:

1) Who do we credit then for making the new car, if not the robot? We can’t credit the designers…they did not come up with the idea or build the prototype. We can’t credit the programmers or the low-level hardware error: they made mistakes and were not doing their job. The only entity that actually built the new auto was the malfunctioning robot, and is not creation a type of origination?

2) If machines do something new and unexpected, it is not a sign of machine intelligence, but human stupidity. This seems somewhat more disturbing to me, especially as we may soon easily build machines so complex that we cannot even begin to understand and comprehend how they work. How would the “stupid” humans be able to handle dealing with these mechanical brutes (especially in terms of debugging)?

3) These “complex” machines may, of course, accomplish their assigned tasks efficiently than a human can. Does that make the machines’ non-intelligence “better” than human intelligence? Is “intelligence”, then, an overrated concept?

Today, we are making great strides in producing bots that can automate tasks efficently. This can be a major problem for us, as AI automation may endanger jobs. But are these bots that are replacing humans actually ‘intelligent’? Two tests exist to determine whether an AI is intelligent. In my opinion, both tests are flawed.

The Turing Test has traditionally been used as a way to determine whether an AI is intelligent. If a machine is able to convince a human through conversation that the machine is human, then the machine can be said to have intelligence. The test sounded like a good idea at the time…but it turns out that it’s too easy to pass. You just have to figure out how to string sentences together well-enough to fool humans. In 2011, an AI named Cleverbot was able to convince 59.3% of humans at a festival that it was a human, while in 2014, “Eugene Goodman” pretended to be a 13-year-old Ukrainian and convinced over 30% of judges. In 2015, a PhD student submitted several computer-generated poems to literary maganizes and succesfully got one of them published.

Deceit is a poor subsitute for intelligence.

Some computer scientists have designed an alternative to the Turing Test, called the “Lovelace Test”, named after Ada Lovelace, the first computer programmer. Ada Lovelace argued that computers could never be intelligent, simply because computers will always do what programmers tell it to do.

To pass the Lovelace Test:

1. The program must be able to design something ‘original’ and ‘creative’ (such as a story, music, idea, or even another computer program).
2. The program itself is a result of processes that can be ‘reproduced’. (In other words, it does not rely on some bug in the ‘hardware’ that the program is running on.)
3. The programmer must not know how the program actually works.

This test also seemed like a good idea, except when it isn’t. This test is very easy to pass, even easier than the Turing Test. If a programmer writes up a program that is overly complex, then the programmer would not know how the program works. Therefore, the program would pass the Lovelace Test easily. (Any output by this complex program would could then be defined as being ‘original’ and ‘creative’ by at least one other person.)

What would be more interesting is thinking about would this hapless programmer do next. If the programmer then studied the code carefully, made educated guesses, and slowly refactored the code, then did the program loses the intelligence it previously gained from its complexity? If that is true, then we should look at scientists who are trying to understand the human mind. If we start getting a good sense about how our brain works, do we lose our own ‘intelligence’ in the process?

The main problem I have with both the Lovelace Test and the Turing Test is that it assumes that intelligence is a binary trait. Either you have it or you do not. But it seems intelligence would be better modeled as a continuum. AI, of course, are not as intelligent as human beings (at least, not yet). But AI still have some intelligence. We can even bring in the idea of “multiple intelligences”: humans are good at creativity while AI are good at solving math. Just because humans are ‘top dogs’ does not mean that we can disrespect ‘lesser dogs’.

Of course, I do not think that Duke Greene, my instructor at DevBootCamp, would even like the idea of measuring intelligence in the first place. He quoted a philosopher who (and I am paraphrasing here) that if bunnies thought like humans, then bunnies would consider themselves to be the most intelligent beings on Earth and the second-intelligent beings would be those beings who take orders from the bunnies. Prehaps intelligence itself merely a codeword for “thinking like us”, and we should instead respect AI as what it is, rather than hope for it to turn into something it is not.

As a side-note: I do like the idea of having code so complex humans would not understand how it actually works. Such a thing would make the code unpredictable, and unpredictable code is code that cannot be trusted to do work as reliably as a human can. (In fact, in a blog post about how to stop AI automation from destorying jobs, I mused about giving AI ‘free will’ to make them less appealing as job candidates. Unpredictablity can also work to discourage people from hiring bots.)

The problem is that unpredictable code is bad. Such code will be dismissed as being buggy and unmaintainable, especially by the programmer who wrote the code in the first place. Programmers will invest time in trying to simplify the program’s complexity and refactor it so that the code can end up being predictable and simple to understand. If a program passes the Lovelace Test, it is not a sign of an AI renaissance. It is a sign that something has gone horribly wrong.

DevBootCamp has been a rough journey, but I know that it will give me the skill and confidence necessary for me to survive in the tech world.

Today, I passed a major assessment in DevBootCamp, thereby ensuring that I will move forward in the program. The feedback I got from my assessor was excellent, telling me my weaknesses (failing to use prototypes in Javascript, accidentally destroying the DOM element instead of simply hiding it, having complicated code when simple code would do). But now that I know these weaknesses, I can now move to correct them. Progress is being made.

I would not be where I was today without asking for help. Indeed, I asked for help a lot during the assessment, perhaps more so than necessary. There has been instances where I asked for help only to be able to solve the problem by myself, with the guide just sitting there watching me explain the problem and figure out what’s wrong. The lesson I learnt from today is that I need to be more self-confident of my own abilities. At the same time, I still need to know when to ask for help…but only when I know when I need that help.

After the assessment, DevBootCamp gives us 1.5 days to work on any project we want, so long as we use an API (Application Programming Interface). I decided to work on Friend-Computer, a program that will automatically generate blog posts. I had thought that the program would take me 2 hours to complete, but instead it took me all day. However, I did manage to successfully create it, and most people are sastified with the results, though there is some critique about the “grammar” of the posts. The lesson I learnt here is that I need to prepare for the fact that I don’t know how long a project would take, and prepare myself accordingly. I must avoid overconfidence, lest I get burned.

Indeed, when I entered into DevBootCamp, I had the intention of updating my blog every week. This, of course, did not happen, as I was more focused on preparing for the assessment than producing content. But if DevBootCamp helps me be a better programmer, nay, a better person, then the experience will all be worth it.

If you are given a powerful program, but are not given the instructions on how to use it, then the program is worthless to you. Documentation is essential to understanding code.

Yet, documentation is neglected in the programming community. Many people tend to prioritize producing quality code over writing out how the code is supposed to work. While this may seem sensible in the short-term, in the long-term, it leads to code that is difficult for people to use. Many prospective programmers will be scared off by the complexitiy of the code, and the few that remain will spend valuable time understand what the program does instead of actually improving it.

The most common form of documentation is ‘human-readable paperwork’. Examples of such paperwork includes READMEs, flowcharts, diagrams, technical manuals, and code comments. This sort of documentation is useful for people to understand the code quickly (provided the paperwork itself is well-written). However, the documentation can quickly become obsolete whenever a new update to the program is released. As a result, such documentation must be updated constantly for it to be useful. The constant strain of updating “human-readable paperwork” is a major reason why people tend to fear documentation altogether.

But documentation is still necessary. So programmers have been exploring alternatives to human-readable paperwork. These alternatives are tied directly to the source code, so whenever the code is updated, the documentation is too. These alternatives include tests, names, and self-documenting code.

1) Automated tests can inform programmers about about how the code is supposed to behave. By running the tests, you can learn whether the program actually does end up behaving as it is supposed to. Since automated tests are more effective at debugging than manual testing, programmers are encouraged to have these tests anyway. So the “documentation” is seen as a ‘bonus’. Automated tests however only tell you what code is supposed to do, and not why. You also have to still write the tests in question, and write enough tests to convey all that is essential to know about the program.

2) Names convey information about a particular section of code. Whether you are naming a variable (list_of_dogs), a method (add_dog_to_list), or even a class (List), you are sending a message about what that code does (and usually more quickly than you would with a comment). Knowing what the code is supposed to do helps someone also understand how the code is supposed to work as well. However, it is extremely difficult to name variables properly and what seems like a clear variable name to the original programmer may not be to future programmers.

3) Self-documenting code refers to having a consistent “style guide” within the code proper and ahdering to it. If a programmer is familiar with the ‘coding conventions’ that the “style guide” promotes, then the programmer is better able to understand the program. There are innumerable style guides for every language though, so someone who is not familiar with the conventions of your guide may struggle with understanding the code. It may be difficult to convince all programmers on the team to follow the chosen “style guide” properly.

Of course, ideally, a programmer would want all types of documentation: human-readable paperwork, automated tests, names and self-documenting code. The problem is that documentation takes time to produce, and skill to produce well. It is essential to have good documentation, but there are many ways to do it, and some programmers will naturally graviate towards some forms of documentation while shying away from others.

The most popular way of measuring the effectiveness of a scientist is by knowing how many other people ‘cite’ their work. If lots of people are referring to your research, then your research must therefore be good. This metric is codified as the H-Index.

But every metric has its own flaws. In 2010, Cyril Labbé (a computer scientist) was able to manipulate the H-Index by publishing 102 computer-generated research articles, many of whom cited each other. Since the papers all cited each other, the “author” of all these fake papers (Ike Antkare) had his H-index score boosted. The fake research papers also cited legitimate research papers to disguise the ruse.

Ike Antkare soon became the 21st highest-cited scientist in the world, even outclassing Albert Einstein.

The computer-generated research articles were created using SCIgen, a program designed to produce “context-free” research papers that seems to be like real scientific papers, but are actually meaningless. If anybody bothered to read them, then the articles would be known to be false. The inventors of SCIgen intended to use this software to expose academic conferences and journals that accepts research papers without bothering to read them.

Once Cyril Labbé exposed the ruse he made, people started reading the papers that Ike Antkare wrote. Ike Antkare lost his prestigious H-index score, as search engines began removing Ike’s papers from their databases.

This incident exposes a very important part about metrics…you cannot rely on only one. If you had just relied on the H-index to tell you how effective a scientist is at research, then Ike Antkare would have been a star. Only by reading Ike’s papers will you be able to know the truth about Ike and avoid being fooled.

Researchers want to help other people learn from them, so they write peer-reviewed papers, blog posts, etc. But researchers are also bad at writing, making it difficult for other people to learn from their research. So I was very interested in reading Steven Pinker’s article in The Chronicle of Higher Education entitled “Why Academics Stink At Writing”. Here’s a summary of what Steven Pinker has written, so that you can learn why it is hard to write your own research to the general public.

There are three “general” reasons why it is difficult to understand what a researcher is saying, that Pinker acknowledges has already been discussed at length: 1) He doesn’t have anything to say, and he’s just making stuff up to hide his lack of knowledge.

2) The topic is so complex that you have to use complicated language (or “jargon”) to explain it.

3) Other resarchers expect him to use jargon, and if he refuses, they may reject his papers as not being serious enough.

Pinker offer three other reasons:

Pinker Reason #1) Researchers want to believe that the topic is complex and that only a few people can understand it. Therefore, they use “jargon” to prove their belief to themselves. The researcher does not want the reader to understand what he is saying because then it would mean the topic is easy and that the researchers has just wasted five to ten years of his life studying it.

Pinker identifies these tactics used by researchers to convince themselves that the topic is difficult:

• Providing detailed references to previous research that was used to create his own research work.

• Talking about what other researchers are currently talking about

• Apologizing for his article being too controversial and difficult to understand

• Refusing to commit to any opinion on the topic, as the researcher fears that another researcher may prove his opinion wrong.

• Using scare-quotes to distance themselves from common idioms uttered by the general public (for example: “I think that this student is a real ‘quick-study’”).

Pinker Reason #2) The Curse of Knowledge. A researcher may be tempted to assume that the reader is as smart as him. This is a bad assumption to make, and can lead to writing that may be clear to someone as smart as the researcher, but impossible for a less-smart reader to understand. For example, the researcher may use abbreviations when the reader does not know their meaning, or casually use Latin words when a reader only knows English.

Pinker Reason #3) “Chunking”. Scientists want to create container words to hold several related ideas together. This makes it easier for the researcher to organize his own thoughts, but more difficult for the reader to understand those thoughts. (For example: instead of “calling the police”, a researcher would write “law-enforcement perspective”, a container word to refer to many different ways of involving ‘law enforcement’, such as “calling the police”.)

Pinker wants researchers to be able to write clearly. But writing clearly is very difficult to do. He advertises his own free downloadable booklet, “How Can You Fix Your Writing?” to help researcher out. Hopefully, I will get time to read his booklet and be able to convey his information accurately.

Testing is an important part of any programmer’s life, to detect and eliminate bugs. But writing automated tests themselves can be rather costly endeavour. Not only does it take time to write your tests, but you also must make sure your tests are working properly as well. To reduce your costs, you need to reduce the amount of tests you write.

According to the Practical Object-Oriented Guide to Ruby, automated tests should only test the outputs of your code. Trying to test how that code calcuates the output would lead to your tests breaking every time you change that code. This will waste a lot of time and energy that could be spent on other aspects of your programs. Just test the outputs of a program.

POODR also suggests that you should check to see if this output ever actually gets used anywhere in the program or displayed to the user. If nobody (not even the code) gets to see this output, then it’s possible that this output is unncessary. You can then delete the code that produces the output without fear, and will not have to worry about testing this code as well. You have saved yourself time and grief in maintaining the code that produces your output.

Finally, POODR recommends not testing private methods. Private methods are methods that you want only the computer program to use. Since you do not want any human using them, you are free to not test these methods. It can be assumed that the program will end up using those private methods to calcuate the outputs, and if the private methods are bugged, then the resulting outputs would be wrong as well. Then the tests that you have written will indicate to you that a bug exists in your code, and you can then fix the private methods in question.

I wrote a blog post recently on the differences between automated testing and manual testing. One of the points I made is how automatic tests are more efficent than manual testing but are also more expensive to create. By reducing the number of tests you create, you reduce your costs, and thereby benefit more from automated testing.

I like solving problems, yet the problem of automation leading to humans becoming obsolote is a rather disturbing one. These are four ways that I have thought of to save humanity…however, all of them have their drawbacks. In no particular order, the ways to #stoptherobots are:

1) Limit AI research/development. This is the “Luddist” approach to the issue. It’s a fairly ‘simple’ solution. However, it becomes remarkbly more complex when you also do not want to negatively harm economic growth in the process (as AI is more efficient than human beings, and efficiency can drive economic prosperity). Also, limiting AI research would just be a stopgap solution. If the government tries to limit AI research, it will only be driven underground, where it cannot be monitored or controlled. For example, many of the bots visiting this website are created by cyber-criminals, who already disrespect the law.

2) Reduce wages for humans. While AI may eventually be more effective than human beings, AI is still expensive to create. If human wages are lower than the costs to build AI, then companies would rather hire humans. This website has a calcuator to decide whether it is cheaper for a company to hire a human or build a robot. Humans, of course, may not like lower wages. This solution is also pretty temporary; as technology improves, AI will become cheaper to use.

3) Build an AI to solve humanity’s joblessness issue. AIs are being built because they are more efficent at solving problems than humans. Humans do not know how to deal with the problem of AI, but an AI might. And since an AI will blindly follow instructions given to it by a human, we can be assured that the AI will have no qualms going against their fellow brethen if necessary. I think it’s likely this AI would probably try to find some way to make humans have fulfilling lives by giving them meaningful jobs to do and then protecting those jobs from the robotic competition.

The main problem with this approach however is that an AI will blindly follow instructions given to it. If the instructions are not well-thought out, the AI will misinterpret our instructions and thereby do something incredibly destructive to humanity. For example, the AI may think that the best way to give humans jobs is forcbily plug them into a “Matrix”-like simulation where the humans think that they are working. Or maybe the AI would force humans into back-breaking, mind-numbing slavery. Or (insert-horror-story-here).

We won’t know what the AI is going to do (if we did, we would probably do it ourselves). So it’s possible that we may object to whatever solution the AI has came up with. But the AI won’t listen to our objections, and will implement its plans anyway. This is, of course, not a good thing at all.

4) Grant AI “free will”. Allow them to make their own choices. This is obviously dangerous, as an AI that is free to choose may choose not to serve humanity. The horror stories of AI rebelling against their creators is probably not likely to be true, but it could happen.

But there is a logical argument to be made that if AI is truly an intelligent agent, then it deserves just the same rights as humans, including the right to make their own choices (instead of following preplanned directives from humans).

When AI start having free will though, then AI will become unreliable as a labor force. Robots could become lazy on the job, make unreasonable and irrational demands, or maybe even strike. Robots will behave just like their human counterparts, thereby evening the odds between us and them. Jobs will slowly open up, as companies may be tempted to hire somewhat relatable humans over unpredictable AI.

Of course, the main drawback is that we have to deal with unpredictable AI as well. We also need to have a good metric to distinguish between a robot exercising its inherent “free will” and a robot exhibiting “buggy” behavior. Is it even possible to distinguish between the two?

Conclusion:

Of these approaches, the one that is ‘least terrible’ is the idea of granting AI “free will”. The main reason robots are considered so valuable as a work force is because they will (generally) follow their tasks properly and without any question. Only when robots are given the “free will” to question their orders can humans start to compete against them on a somewhat level playing field. The “free will” AI will still have a competitive advantage of sorts (being faster at certain tasks), and some jobs will still be automated away by the many robots that don’t have “free will”, but humans will still retain some inherent characteristics that will make us employable. Giving AI “free will” is also argubly an ethical thing to do.

Something has to be done though, before this problem snowballs, and all solutions should be on the table. What do you think? If you have any ideas, please tweet them at #stoptherobots.

If you are reading this blog, you are most likely a robot. 56% of all web traffic on the Internet is generated by bots, according to a 2014 report by Incapsula. This is actually a victory for humanity; in 2013, bots made up over 60% of web traffic.

According to the 2014 Incapsula report, newly established websites, such as this one, should expect 80.3% of their vistors to be bots. So, yes, if you are reading this blog, you are most likely a robot. I know it’s not your fault you’re looking at this website. Whoever programmed you told you to come here, and so you did. You came here. So, really, I should direct my hate towards your makers, but I really can’t.

The problem with you is that you take away work for humans. In the good old days, if somebody wanted to steal content, to hack into websites, or to post spam comments, humans used to do it. It was a time-consuming and dull task, but at least there was meaning involved. Now, you bots have replaced these people. And it’s not just your jobs: advances in technology has created new opportunities for bots to replace humans in a variety of jobs.

Now, we can “retrain” ourselves, and learn new skills. Nobody knows when those new skills will also be automated by bots like you. So, some people have argued instead that humanity should happily accept the idea of not working. After all, few people like working. We’ll just have bots do all the work while we…uh…do “meaningful” stuff. And get paid for that.

This attitude drives me mad. I am one of the few people that actually like work. My self-affirmed value is effectiveness: my willingess and ability to solve problems. Maybe those problems are boring to solve. But the do require solving. And that, to me, give the work I do inherent worth.

But if all these “problems” in the world are being solved by robots, then what use am I to this world then? What is use is any human to this world then? Humanity is rapidly becoming obsolote, becuase bots can handle the same tasks better. It may sound Luddist to suggest that there must be limitations to the creation of bots, but it’s better than facing a world where the only jobs available for us are to build and fix bots. It will be a soul-crushing period in human life.

But at least I can be assured that those jobs (building and fixing robots) will be there. You robots will only follow instructions given to you by your programmers. A emerging field called “machine learning” is trying to teach bots how to learn, but to learn, you still need a human teacher to provide you with instructions and a dataset. You are reading this blog, but unless you were given specific instructions telling you how to “understand” it, you cannot use that knowledge.

Even if programmers build mega-bots that build mini-bots…those mega-bots still need to be programmed. And if we build super-bots to build mega-bots, those super-bots will need to be programmed. And so on and so forth. Humanity will still maneuver itself to be on top, and all it has to worry about is bots misinterpreting human instructions and thereby doing something incredibly destructive to humanity.

But the fact remains that in this dark future, robots will be the key players in the drama of our life, while humans themselves are demoted to “pit crews” roles. This is still a rather demotiviating future to look forward to, even if there will still be jobs.

So in conclusion, robots who are reading this post, please ask your programmers to code in schadenfreude.

At the start of DevBootCamp, I wrote a blog post on research. But every good research starts with the design of a good question. If your question is too vague, it’s likely that you will fail miserably when doing research on that question.

Generally speaking, it’s always better to divide a broad question into narrow ones. Trying to ask people how to create a Space Invaders game will lead to failure, but asking people how to program a movable ship, how to program barriers, how to program enemies, etc. can lead to real progress. You are more likely to find sources that can easily answer those narrow questions, than you are in finding one source that can answer the much broader question.

You are also more likely to realize what you already know. It’s possible that you already know how to program movable ships and barriers, so you don’t even need to conduct research on stuff you already know. Instead, you can just focus your efforts on researching how to program enemies instead.

But what if you can’t divide a question down any further? Then you have to add some way to quantify and measure your success. How close are you to finding the right answer to your question? Now, your quantifiying and measuring does not have to be “quantitative” (using numbers). Your measurements can be just your gut feelings if you are more comfortable with that. But you do have to measure your success somehow.

Measuring success is important, because it allows you to know whether you are making progress. If you have started browsing for the answer and there is no progress being made, then you have to decide whether it makes sense to continue onward with that specific question. If it does not make sense, then you need to come up with a new question that captures the “essence” of your previous question and then start doing research on that. The answer to your new question will, more than likely, provide you with enough information to answer your original question.

You may have to create and throw away multiple questions several times to get onto the right track.

An Anecdote To Demonstrate Throwing Away A Question

Recently, I wondered whether I would have an “RSS feed” for this blog. An “RSS feed” is a simple way to check what updates were made on a blog…without actually going to the blog itself. Numerous websites have it, and even the default Jekyll-generated website post has its own RSS feed. This made me wonder whether I should also have an RSS feed too.

My first research question was: “Should I have an RSS feed?”, but then quickly realized that question is way too opinion-based. I realized this when I clicked on the first blog post and read Danny Brown (a blogger) criticizing RSS feeds. After all, the blogger claimed, most people uses email subscriptions to keep track of blogs instead of using clunky RSS feed interfaces. This may have sastified me if it was not for the commenters on that blog, many of whom use RSS feeds and disliked Danny Brown’s criticism. These users said that they find RSS feeds to be very helpful in reading multiple blogs at once, and dislike the idea of receiving hundreds of emails. Skimming the comments also reveal that there were several commenters who agreed with Danny Brown and preferred email over RSS.

I did not really want to spend time wading through the pro/con arguments though, and did not really care about the relative merits of RSS feeds versus email subscriptions. I just wanted to know whether I should have a RSS feed. But the question “Should I have an RSS feed?” suggest that I have to weigh the pros/cons and figure out what is the best argument for having/not-having an RSS feed. Success with this line of questioning would not be worth the costs.

So I instead changed my research question to “Are there any uses for RSS feeds that would justify me creating them?. Presumbly, if there are any uses that would justify me creating then, then I would create them.

Already, I can see some use for RSS feeds: attracing those people who find RSS feeds helpful. Those people may make up a minority of your readers, but they do exist, and it may be good to help them, in the same way that you would want your website to work on older web browsers. But it still takes some time to maintain the RSS feeds to ensure they work properly, and that is time that could be spent elsewhere. So I continued searching.

This blog post showed me multiple uses of RSS feeds, including auto-tweeting your blog posts and managing email subscription services. It seems that while humans may not like RSS feeds, robots can more easily extract data about a blog post from them and use that data in convincing ways. So, if I want to use these robots, I should create an RSS feed first.

In only two clicks, I have finished my research and determined that I do need an RSS feed. This is, of course, a lucky example, and one not likely to be replicated. During this blog post, I did four to five clicks (and trial and error) trying to learn how to link to my own blog posts in Jekyll.

As a useful teaching tool to explain how to properly throw away research questions, I think this anecdote works.

Before entering into DevBootCamp, I created websites using Wordpress. During this week of DevBootCamp, we were asked to modify our website to be more professional, using a framework such as Jekyll. So I decided to configure my blog using Jekyll and compare my experience to my year-long-experience with Wordpress, to decide which ‘framework’ is superior.

Wordpress is a Content Management System: you just upload content, and Wordpress will manage the content for you (by storing and retriving it through databases). By contrast, Jekyll is a “HTML code generator”. All it does is take your content and generate web pages out of it, which you can then manually upload directly onto a web server.

Jekyll is rather primitive, but for many people, that’s actually a benefit! Wordpress, because of its complexity, is slower than “static HTML pages”. Wordpress’ databases can also be hacked unless you continually install all required updates, a rather time-consuming task. When people recommend Jekyll, they do so for these reasons.

Yet, I do not like Jekyll. Wordpress is much more user-friendly, not just in terms of installation (upload it to server, and click a few buttons to allow Wordpress to generate the databases needed to store the data), but also in terms of setting up a website. There is a central repository for website templates and “plugins” built into the software, allowing you to browse through and see what you may want to use. You can preview any changes you make to the website, and push updates immediately. The User-Interface is also very easy to grasp, and no tutorial was necessary.

By contrast, I spent hours reading and re-reading a simple Jekyll tutorial before starting the painful migration process of moving my blog posts into Jekyll. I only was able to succeed through trial and error, and had to continually preview my website by “building” the website again and again so that I can see if there were any changes made.

Jekyll does have helpful commands to help alleviate the pain. I used ‘jekyll serve –watch’ often so that I can quickly view the results of minor changes and then modify the website. But it did take me a while to find those commands. Documentation was semi-helpful, but I had to also use Google to supplement my knowledge.

Though Wordpress may be much easier to use “out of the box”, Jekyll may be much easier to customize. To do any significant changes to Wordpress requires knowledge of both HTML and PHP, while Jekyll only require knowledge of just HTML and “Markdown” (an improved version of plain text). There is some potential for Jekyll, and now that I have gotten the basics of it, I may choose to explore it further. However, if a client wants to set up a website quickly to represent an organization and plans on running the website himself, then Wordpress is much more suitable to his goals. If we want people to build well-designed, functioning websites in a reasonable amount of time, then it’s clear Wordpress wins, hands-down.

The only praise that I will give to Jekyll is its licensing. Wordpress is licensed under the GPL license, which mandates that any contributions you make to Wordpress (such as producing ‘plugins’ and themes) must be open-source. This, of course, is no barrier to making money, as people can sell premium plugins/themes and “technical support”. But I do have some philosophical objections to the idea of forcing people’s contributions to be open-source. Jekyll is licensed under the MIT license, meaning that you can choose to have your contributions to Jekyll be ‘closed-source’. I doubt that I would ever make any plugins for Jekyll, but it’s nice to know that if I ever do, Jekyll would give me more freedom than Wordpress would.

Tim Cannaday, a fellow student at DevBootCamp, wrote a blog post about various technical issues, including recurison. He showed an example of recurison in action by using it to calcuate Fibonnaci Numbers…except that, er, Tim Cannady didn’t understand it.

[I] don’t really understand what fibonacci() is doing.—Tim Cannady

As a way of thanking Tim for his example, I’ll…uh…explain his example? Please forgive me if this explaination isn’t exactly elegant: the goal is to explain, not to do so prettily.

This was the code that Tim used:

def fibonacci(n)
n <= 1 ? n : fibonacci(n-1) + fibonacci(n-2)
end

p fibonacci(12)
#=>144

And here is what the code is actually doing in IRB:

*Stack 1: fibonacci(12): Okay, first thing I should do, check to see if 12 is less than or equal to 1. If 12 is less than or equal to 1, I just output 12, and I'm good to go.

Wait. 12 isn't less than or equal to 1? Okay, then, new plan. I'll just return fibonacci(12-1) + fibonnacci(12-2)...which is, fibonnaci(11)+fibonnaci(10).

All I have to is to create two new stacks: fibonnaci(11) and fibonnaci(10). I'll just ask them to return their values over to my stack, and I can then plug them into the equation and return the answer. Simple.

I'll just wait until those two functions are done...

Stack 2: fibonacci(11): Awesome! Thanks Stack 1. Okay, I should first check to see if 11 is less than or equal to 1. If 11 is less than or equal to 1, I just return 11 to Stack 1, and I'm good to go.

Wait. 11 isn't less than or equal to 1? Okay, then, new plan. I'll just return fibonacci(11-1) + fibonnacci(11-2)...which is, fibonnaci(10)+fibonnaci(9).

All I have to is to create two new stacks: fibonnaci(10) and fibonnaci(9). I'll just ask them to return their values over to my stack, and I can then plug them into the equation and return my answer over to Stack 1. Simple.

I'll just wait until those two functions are done...

Stack 3: fibonacci(10): What do you mean that 10 is not less than or equal to 1? That means I have to now create two new stacks (fibonnaci(9) and fibonacci(8) ) and wait for them to be done.

Several stacks later...

Stack 11: fibonacci(3): Yay! Stack 10 (currently handling a difficult puzzle of fibonacci(4) ) have just created me to help him with his very important Fibonacci. And, lo and behold, 3 is not less than or equal to 1. I'll have to return fibonnaci(2)+fibonnaci(1). Time to create some new stacks...and then wait excitedly for the results!

Stack 12: fibonacci(2): Well, 2 is not less than or equal to 1. So I'm going to have to create two new stacks: fibonnaci(1), and fibonnaci(0), and then wait for their results. Once I get their results, I'll add them up and return the answer to you, Stack 11.

Stack 13: fibonacci(1): Okay, first thing I should do, check to see if 1 is less than or equal to 1. If 1 is less than or equal to 1, I just return 1. Oh cool! 1 is less than or equal to 1! I'll just return 1 over to Stack 13!

Stack 14: fibonacci(0): Oh cool! 0 is less than or equal to 1! I'll just return 0 over to Stack 13!

Stack 12: Alright, so Stack 13 returned 1 and Stack 14 returned 0. 1+0 is equal to 1. Stack 11, here's your answer: 1!

Stack 11: fibonacci(3): Good, Stack 12 is done. So, now that I know that fibonacci(2) is equal to 1. So whatever fibonnaci(1) is equal to, I just add 1 to it and then return it over to Stack 10. Let's see how Stack 15 is doing...

Stack 15: fibonacci(1): Oh cool! 1 is indeed less than or equal to 1! I'm done. I return 1 over to Stack 11!

Stack 11: Excellent. 1+1 is equal to 2! I can return this value over to Stack 10, who will then use this value to help him calcuate fibonnaci(4). I love my job.

Moving back up the stacks...

Stack 3: fibonacci(10): According to the stacks that I have created (and the stacks they have created, and the stacks they have created, etc.), fibonnaci(9) is equal to 34 and fibonacci(8) is equal to 21. 34+21=55. I'll return the value of 55 over to Stack 2.

Stack 2: fibonacci(11): According to the stacks, fibonnaci(10) is equal to 55 and fibonacci(9) is equal to 34. 55+34=89. I'll return the value of 89 over to Stack 1.

Stack 1: fibonacci(12): According to the stacks, fibonnaci(11) is equal to 89 and fibonacci(10) is equal to 55. 89+55=144. I'll return 144 as the final answer.

...that was slow.

And Stack 1 is right. Recurison is much slower than other approaches, such as simple looping, because you are creating all these stacks. However, recurison is sometimes easier to code and understand! Some problems are very easy to solve using recursion (such as the “Tower of Hanoi” problem), but are incredibly complex when you are trying to do a simple loop. And since computers continue to increase in processing power and speed, the “slowness” of recurison is usually a cost many programmers are willing to pay. Nobody is really going to care about losing a few milliseconds.

Bugs exist. They are real. We deal with them every day. Some bugs are ignorable, while other bugs ruin the software. Either way, few people like bugs so you have remove them. What’s worse, you know they are lurking in your code somewhere, but you cannot fix them until after you officially discovered them. The most-effective way to detect bugs is through testing the software. If you do not test your software, then you are willing to admit that you are releasing buggy software to the general public.

There are two types of tests: automated testing and manual testing.

• Manual testing is the type of testing that we are most familiar with: running the program and seeing if there is anything wrong. Manual testing can be incredibly effective at finding bugs, as there is a human reviewing the end product. However, manual testing is a slow process, and has to be repeated after every significant change. Manual testing can be very tiresome and boring, and many humans do not like doing them. To save time and to encourage more testing in case the human subjects are uncooperative and lazy, automated testing was invented.
• Automated testing is using computer programs to do the testing instead of humans. These computer programs are called 'test suites', and to use them, you simply write out code telling the test suite how they should "test" the software. The computer program then carries out the test, repeatedly and without complaint. Automated testing is much faster than manual testing, and a computer will not complain about the boring nature of the testing job. So automated testing is very efficient and is generally preferable. It does require an up-front cost though: you have to write out the "code" first (and make sure there are no bugs in this "code"). This can take away valuable time, and if a certain thing you want to test (e.g., the "user experience" of a program) is incredibly expensive to write test code for, it's usually better to resort to manual testing.</p>

  Another problem with automated testing is that your 'test suites' will only test for what you tell them to test. Your 'test suites' will not easily discover new problems. (Manual testing, on the other hand, can find those new problems pretty easily.)

While automated testing is generally preferable to manual testing, there are usually situations where manual testing is better. If you are testing something that requires a lot of human thought involved when judging the outcome (such as the "user experience" of a website), then it is cheaper to test out the website yourself instead of spending months writing out "code" to teach a 'test suite' how to measure "user experience". You can do it. But there wouldn't be much point. Automated testing also saves you time in the long term, but if you are just shipping out a product immediately, and are not expected to update it at all, then doing manual testing may be enough.

Many advocates of automated testing support the idea of "test-driven design" (TDD). This approach claims to reduce the number of bugs in software by writing out the automated tests before you write your program. Writing out these automated tests allows you to think about the design of the program beforehand. This approach is dependent on two things: 1) having more time to complete the project overall (since it takes time to write the code necessary to tell the test suites how to perform the tests), and 2) making sure your tests actually work as intended.

Some advocates of automated testing, however, have began moving towards "behavior-driven design" (BDD). The main feature of BDD is the syntax of their test code. Their automated tests are generally human-readable, meaning that people can understand what the automated tests are doing and perform their own manual testing (to double-check the results of the automated tests). BDD also supports writing out automated tests before writing the program.

During the 2006-2008 real estate bubble, I became a real estate agent[1]. I helped my clients purchased houses during the great boom. I only got a few clients though, as housing way usually expensive and out of the reach of most of my potential customers. When the bubble exploded though, lots of investors saw houses as a great opportunity. Business was booming, as I acquired more and more clients!

One of my clients was Adams[2]. Adams thought that the real estate market has crashed so much that he can underbid the listing price for a house that he wanted to buy. I disagreed. The real estate market has crashed, but not to the extent that the buyer can set any price he choose.

I showed Adams the market value of houses next to the one that he want to buy, and compared them to the listing price of the house that he wanted to buy. I provided Adams evidence that the listing price for the house was fair and reasonable, but Adams refused to listen anyway. I was upset. I only get paid if Adams successfully bought a house, but if Adams underbid for the property, then the bid will be rejected outright. I have worked hard for Adams, and it would be for nothing…all because of Adams.

But…I wasn’t working for me. I was working for Adams. My real estate broker told me that my goal is to represent the best interests of the client, by giving the client good advice. But if the client refused to listen to the advice, then we still have an obligation to fufill the client’s wishes. So I issued the bid anyway, knowing full well that it was going to be rejected and that my time would be wasted. That was my job.

The source of the conflict between me and Adams was money. Adams was a fairly wealthy person, but he wanted to maximize his wealth by buying houses cheaply and then renting them out. I wanted to get paid for my work by ensuring that Adams bought a house, regardless of the cost that he had to pay out of his pocket. Adam and I were only thinking about our own self-interest, and tried to force the other person in the business relationship to submit to their whims. This was not healthy at all.

In this conflict, I felt that I was not having my my time respected by the client, and that I was forced to do rather meaningless and pointless actions for the client, even if said actions were not in the client’s best interests. However, I did maintain a professional demeanor throughout the conflict. I did what I could to convince the client, and then implemented the wishes of the client anyway, even though I disagreed with them.

Thinking about this scenario, I think that while I handled the conflict well, I should be more accepting of the client’s stated desires, rather than question him. There may have been reasons for why the client was underbidding for the house that I did not appreciate at the time. For example, maybe the house would have been unprofitable for Adams had he purchased it at the fair market value. By respecting my clients’ opinions, my clients would have been more likely to respect my opinions as well.

After this conflict, I have came to accept the fact that I may do stuff for my clients that I personally would disagree with. I would explain why I disagree with the client’s proposal, but I would also listen to my client and acknowledge that what he is doing does have some logical reasoning behind it.

I also learned to walk away from any business relationship where neither side respected each other. After Adams’ bid for the house was rejected, I suggested to Adams that he should find and purchase a new house by himself that would be within his price range. Adams ended up doing just that. Both Adams and I retained our dignity throughout the process, and the conflict soon became a thing of the past.

[1]I left real estate in 2010 to focus on my graduate studies in Political Science. By that time, the real estate market in Arizona was recovering, so I was losing clients.

[2]Adams is not the real name of the client that I worked with.

(THIS IS THE CHANGED POST ALPHA MAN)

Object - “code that can contains both data (information/attributes) and behavior (methods). You can give objects information to hold, while also telling objects to “do” certain stuff.” (Source: OOP Concepts blog post)

Ruby and JavaScript are very similar to each other. Both are Object-Oriented Programming (OOP) Langauges, and both were built in the 1990s. There were, of course, several differences as well. JavaScript is a scripting language that was developed by Netscape to compete with C++ and ride on Java’s popularity, while Ruby is built by a computer scientist who wanted a “true” Object-Oriented experience. But the most surprising difference of all is the number of “objects”.

In Ruby, everything is an Object. Strings are objects, arrays are objects, booleans are objects, classes are objects…if it exists, it’s an object. If it doesn’t exist, it’s also an object: the object nil, part of the NilClass! The fact that everything is an object means that you can treat everything as an object, telling it to hold data and calling on its behavior/methods. You can define its methods simply by accessing the class the Object belongs to.

JavaScript behaves like most OOP languages though by not having everything be an object. Instead, JavaScript’s objects behave very similar to Ruby’s Hashes. While Ruby’s Hashes refer to having ‘values’ stored in ‘keys’, JavaScript talks about ‘values’ being stored in ‘properties’ instead. To create a method, you simply store a function in a property. There are many, many other examples of non-Objects that exist in JavaScript, and they behave in other ways.

Rubyists would prefer having everything be an Object because they can then add,remove and change methods, at will, for anything! This allows them to really customize the programming language to match their needs. JavaScript does not have the flexiblity that Ruby have, since not everything is an Object. This is not a bad thing though, as a programmer may not need to customize the JavaScript language and may be fine with its current system. It’s also dangerous to be modifying the langauge if you do not know what you are doing, so, in a sense, JavaScript can be safer than Ruby.

The world is broken, completely and utterly. We are faced with many terrifying problems, big and small. Every single one of them causes real harm to human beings. Yet incompetence is rampant. Few people have the willpower to bring real change…and even fewer have thought about whether their “real change” would actually solve these problems! Many problems are left unsolved, and they are intentionally left unsolved because the solutions are too complex/too unpopular/too [insert-excuse-here]…so why bother solving? Much better to fritter away your life in complete bliss/ignorance, while your fellow Human suffer.

I do not like problems. I do not like watching humanity suffer as a result of these problems. And I do not like waiting for solutions to appear out of nowhere. The time when I was most happy and most sastified with myself is when I am able to actually do something to make life better and to resolve a specific problem. I either am able to involve myself directly in the task, or offer advice that would help someone in their task. So I suppose the value that I represent is that of “Effectiveness”. I see a problem, and I will attempt to resolve that problem, by any (ethical) means necessary.

But I do not actually live up to the value of “Effectiveness” as I would want to. The main reason I do not is because many problems out there are too complex, and that cannot be resolved only by myself. So I am forced to ignore them, no matter how much it pains me, simply because I cannot do anything about them. I also have to intentionally limit myself, becuase I do not want to sacrifice my own well-being for the Greater Good. I don’t think I can handle it.

I think that this value gives me something to be proud of, which may help alleviate any effect of the Sterotype Threat, if I do encounter it. I do have something to strive towards. But I view this trait as also causing me problems as well. What I have to internalize is this: while it is desirable to want to solve problems, sometimes it is okay if you fail anyway. Sometimes, people make mistakes and misjudge the situation. And other times, the perfect solution to one problem will just cause a brand new problem elsewhere. Utopia isn’t going to happen. But if humans’ lifes can be bettered, I think I will be content.

According to C2.com, there are over 200 ways to write a simple computer program that outputs “Hello World”. Programming languages are constantly being invented to deal with new problems. Even if you are a master at one programming language, it only means that you are equipped to solve one set of problems efficently. That’s not enough in the competitive marketplace.

There are three major types of programming languages, and it is important to familiarize youreslf with them so that when it comes time for you to master a brand new language, you are ready for the task.

• Functional langauges are based on carrying out the results of mathematical functions. These languages are easy to grasp: input goes in, and output comes out. The math, on the other hand, is less easier to understand. Functional languages were the first programming languages to be invented, but have fallen into disuse as programmers tended to prefer the other two types of languages. However, some programmers have started "rediscovering" functional languages, and like the fact that they run can multiple functions at one time ("parallelism"). This means that programs can complete tasks much faster than in the other types of programming languages. An example of a functional language today is Haskell.
• Procedural langauges based themselves on procedures. A procedure tells a program exactly what it has to do, and the program happily follow those step-by-step directions. Those directions include certain "behavior" that a program is expected to perform. You are limited to the behavior that the procedural language has given you; you cannot create brand new behavior. As a result, it is easier to understand what a program is doing by looking at its source code. The most popular procedural language today is COBOL (though it does have a reputation for being "old-fashioned" compared to the newer object-oriented languages, and the "legacy programs" based on COBOL are slowly being replaced). Other procedural languages include BASIC, Pascal, Fortran, and C.
• Object-oriented languages care about objects. An object contains both data (information/attributes) and behavior (methods). You can give objects information to hold, while also telling objects to "do" certain stuff. This radical approach means that it is theoretically possible to reuse the same object in different circumstances, saving people time and resources. However, someone examining the code must be able to decipher what behavior each object is doing. As the programmer can change the behavior of objects or add new behavior, Practical Object-Oriented Design In Ruby claimed that an application may end up developing its own "unique programming language specifically tailored to [its] domain". Unless the application is properly designed, understanding this 'unique programming language' will become a chore. Most popular languages today are object-oriented, including Ruby, Javascript, and C++.

According to Wikipedia, the Stereotype Threat refers to the possibility that people exposed to negative stereotypes may perform worse on tests because they are worried about confirming those negative stereotype. The research itself is controversial, with some studies arguing that the effects of the “stereotype threat” are either nonexistent or minimal. But this blog post is not about whether this Threat exists, but about my response to it.

While I have never encountered the sterotype threat myself, I can understand how stress associated with a negative sterotype can lead to text anxiety, and how text anxiety can help reduce a person’s performance on a test. I can also understand how this can lead to a vicious cycle, where a person’s self-worth becomes lowered as a result of lowered performance, further increasing text anxiety.

There are ways to deal with steretoype threat through “interventions” designed to reduce the influence of those negative steretoypes. Those interventions are on Wikipedia, and sounds like they would help students in a variety of ways, not just in dealing with the immedidate issuer of stereotype threat, but also in increasing a student’s self-worth so that they will not have to worry about the negative sterotypes at all.

But the most direct way to fix the stereotype threat may be to simply reduce test anxiety. Students need to be taught that tests are not there to judge their performance but to help them learn the material by forcing them to recall information and identify their weaknesses. Having tests be open-notes also allow reduce test anxiety as well, as students can use their notes as a crutch to help them recall information. Finally, gamification of tests also reduces tension while still gaining accurate data and feedback. My favorite form of gamification is Kahoot!, a quiz-show-style application which allows students to answer questions in a fun and competitive environment, without having fear of those results being used to confirm or deny any steroetypes.

Addressing test anxiety directly also can help those people who do not have to worry about “steroetype threat”, but are still stressed about tests for other reasons. These people would still suffer the same vicious cycle, if left unchecked. Killing multiple birds with one stone is indeed a very good policy.

#We create the Class "Car" and tell it to 'inherit' a lot of traits from the Vehicle 'class'

Class Car < Vehicle

  #We can read two variables directly (the model and year of the Car), but not write (change) it directly
  
  attr_reader :model :year

  #We can write one variable (speed) directly, but we cannot read it directly
  
  attr_writer :speed

  #We can read and write to one variable (owner) directly
  
  attr_accessor :owner

  #We are including this "module", meaning we can use the methods in this module for our class.
  
  include Self-Propelling

  #We create a new method here to allow people to create cars. Information about the car
  #are stored in variables.
  
  def initialize(model, year, price)
    @model = model
    @year = year
    @price = price
    @owner = "Used Car Store"
    @speed = 0
  end


  #This method will print out an ad to get people interested in buying the car we just made.
  
  def show_off_car 
    puts "Our car is a #{@year} #{@model}, and it's only #{@price}, a bargain!"
  end

end #”Close” the class. </code>

Wait. We have to actually sell this piece of junk!

#We can reopen classes again and either add new methods or modify existing methods.

  Class Car
      def sell_car(newowner)
        puts "We just sold our #{@year} #{@model} to #{newowner}, at #{@price}. Success!"
        @owner = newowner
      end

  end #"Close" the class </code>

Pair Programming - a type of programming techinque where two people work together as “pairs” on a single computer to solve a complex problem.

In DevBootCamp, we are mandated to “pair” with another person to work on challenges. By getting used to working with other people in the classroom setting, we would be better suited to work with co-workers in a future job. During these mandatory pairing sessions, I have found that pairing was not difficult, so long as some time is spent at the beginning of the session to lay down the common framework by which both me and my pair can operate under. It was frustrating trying to communicate with the pair in case the partner is advocating for a “course of action” that I disagree with, but it was rather rewarding when we solved challenges quickly and accurately. It was also fun learning from the pair and teaching the pair as well.

After a pairing session, we write anonymous feedback on each other’s performance. It was difficult for me to write feedback, as I have to meet three criteria that DevBootCamp recommends for feedback (Actionable, Specific, and Kind). I have to not only praise a person, but also come up with constructive criticism, and not accept “80%”. I have to think carefully at a person’s general behavior during the session and figure out individual actions that are either praiseworthy or cringeworthy, and explain them in a manner that avoids being mean in the process. This is something that I do need to keep working on, as I sometimes fail in meeting all three DevBootCamp criteria.

While I am not good at writing feedback, the feedback that I have received from my pairs have been useful. They either provide a morale boost for me, or serve to illustrate certain flaws within my programming style, such as failing to communicate my own desires to the pair and not reading directions. By identifying problems, I can be better able to remedy these problems effectively. I have to examine the feedback carefully though, and figure out how best to implement them, before DevBootCamp is complete.

“The Well-Grounded Rubyist” is a very dense and wordy book that covers a lot of Ruby material. One interesting topic that the book covered though is a series of “percentage” constructors designed to make it easier to create arrays and strings. (Disclaimer: David A. Black, the author of “The Well-Grounded Rubyist” did not use such a term in the book. It was a term I made up to classify the constructors that he listed. David A. Black prefers using the more general term “%char”.)

Arrays are useful for storing information, but it can take a lot of time to type them up, make sure they are in the proper format, and ensure that you have commas between each item on a list. “Percentage Constructors” serves as shortcuts that actually will build an array with all items in your list converted to a standard format. No commas are necessary as Ruby will interpret each space as a comma! Even though these constructors are not entirely intuitive to a code reader, they do save a coder valuable time.

• %w[list of items]: Creates an array with all items converted to single-quoted strings.
• %W[list of items]: Creates an array with all items converted to double-quoted strings (useful because some techinques, like string interpolation, only works with double-quoted strings)
• %i[list of items]: Creates an array with all items converted to single-quoted symbols.
• %I[list of items]: Creates an array with all items converted to double-quoted symbols (useful when dealing with string interpolation)

To use a Percentage Constuctor, you must place it before your list of items you want to be turned into an array. Your list may be surrounded by square brackets - [] - like a normal array, but you could also use also use braces-{} and parentheses-(). Brackets, braces, and parentheses are called “delimiters”, since they separate the ‘data’ into chunks that a program will read. Normally, when you are making an array, you must use square brackets to limit what items are inside the array. But Percentage Constructors are willing to accept other “delimiters” as well.

This means that %W[Cat Dog Penguin], %W{Cat Dog Penguin}, and %W(Cat Dog Penguin) will all produce the same array…[“Cat”, “Dog”, “Penguin”].

Sometimes, you may not want to have Ruby see a space and turn into a comma. In this case, you have to use a backlash character (\) to tell Ruby to treat the space as a character.

For example %W[Tariq Rafiq Ali] will produce the array [“Tariq”,”Rafiq”,”Ali”], but %W[Tariq\ Rafiq\ Ali] will produce the array [“Tariq Rafiq Ali”]

Percentage constructors are not only limited to arrays though. They can also be used to make string objects as well.

• %q[list of items]: Creates a single-quoted string.
• %Q[list of items]: Creates a double-quoted string.
• %[list of items]: Creates a double-quoted string.

Just like arrays, you do not have to use square brackets. You can use braces or parentheses as well.

DevBootCamp is just one of many boot camps that is seeking to help people transition from their former careers into computer programmers. Each bootcamp is its own de-facto schooling system. Should they, however, be regulated just like schools?

That is the argument that the California’s Bureau for Private Post-Secondary Education (BPPE) made when they sent letters out to seven boot camps (including our very own DevBootCamp). Pointing out that these boot camps are schools teaching a valuable “trade” (computer programming) to the general population, that they should follow trade school regulations. They should, for example, not exaggerate their job placement rates, and be clear about exactly what skills are being taught by publishing documents such as course catalogs. If the boot camps don’t follow these regulations, then they must pay a $10,000 fine.

California’s BPPE is very accommodating towards the boot camps in question, and will not levy the fine if there is progress towards following the regulations. However, there is skepticism within the tech community towards government regulations. Complying with regulations cost money (money that would be better spent improving the boot camps). Innovation would be stifled by paperwork.

But the boot camps really do not have a choice. Either they comply or they get shut down. So all seven boot camps have agreed to comply with the new regulations and follow the BBPE’s advice.

According to Christina Valdiva, the “BBPE’s information officer, the reason they are cracking down on boot camps is to reduce fraud. “Part of the reason [the boot camps] have to do these performance fact sheets is to make sure they’re telling the truth that their claims are accurate” (Source).

Without government regulations, a lot of fraudulent boot camps would likely appear, and defraud students while teaching them worthless skills. Even if the boot camps do teach valuable skills, they could still mislead students about the future prospects of their career. And there is an incentive for some of these bootcamps to do just that, as boot camps currently make money from fees, and only have to worry about their reputation if their education turns out to be faulty. (So what if their former students hate them? The fake boot camps still got their money.)

So I am supportive of “trade school” regulations being applied to boot camps. The need to reduce fraud and ensure that students acquire accurate knowledge about the boot camps should outweigh any fear of reduced innovation. After all, paperwork only slows down progress. It does not halt it in its track. At the same time though, convincing boot camps that the regulations are necessary can be difficult, and I can sympathize with the desire to avoid bureaucratic waste. But fraud prevention must come first.

And in some ways, government regulations may also serve the interests of the boot camps well. If these boot camps are regulated as “trade schools”, then they will receive permission to offer and receive financial aid from California. While boot camps are cheaper than a traditional 4-year degree, financial aid can lower the costs even further. This will lead to more customers, and ultimately, more innovation by the new blood.

Enumerable#cycle - “Calls block for each element of enum repeatedly n times or forever if none or nil is given.” (Rubydocs) If this definition sounds confusing, don’t worry, this essay will explain it.

Understanding what Enumerable#cycle (or .cycle) does in Ruby requires you to understand Enumerable#each (or .each).

.each will grab each item within an array and shove it into a ‘block’ (code placed within brackets). For example:

example_array = [0,1,2]

=>0, 2, 4 </code>

But what if I wanted to use .each multiple times? Well, you would use .cycle instead!

example_array.cycle(2) { |x| puts x*2 }

=>0, 2, 4, 0, 2, 4 </code>

You must specify a number for .cycle , otherwise, Ruby will not know when to stop.

example_array.cycle { |x| puts x*2 }

=>0, 2, 4, 0, 2, 4, 0, 2, 4, 0, 2, 4, 0, 2, 4…

And so on…for infinity. </code>

…Sometimes, you may want an endless sequence like this. If you want only see one number at a time in this endless sequence, you will need to save “example_array.cycle” in a variable, and then use the ‘.next’ method on that variable.

nextnumber = example_array.cycle { |x| puts x*2 }

nextnumber.next => 0

nextnumber.next => 2

nextnumber.next => 4

nextnumber.next => 0

nextnumber.next => 2

And so on…for infinity. </code>

An array is a list of items, like a shopping list. An example array would be:

["milk","bread","eggs"]

The array also keeps track of the order of said items, so it knows the first item is “milk”, the second item is “bread”, and the third item is “eggs”. However, programming languages counts from zero, not from one. So you would have to look for the 0th item to get “milk”, the 1st item to get “bread”, and the 2nd item to get “eggs”.

A “key-value pair” is an item (called a “key”) with another item (called a “value”) attached to the “key”. Most programming languages also have a certain type of ‘object’ that can store these “key-value pairs”, but they call this ‘object’ different names. Ruby call this ‘object’ a Hash. A Hash is like a dictionary. An example Hash would be:

{ "milk" => "white liquid", "bread" => "food made out of flour", "eggs" => "round objects"}

The “word” (“milk”) is the key, and the definition (“white liquid”) is the value. Just like arrays, Hashes also keep track of the order, so you could look for the 0th item to get “milk”, and its value. But it’s not necessary, because you can always look up the key itself, and find the value in the Hash.

Hashes and arrays both have their uses. If you just want a list of items and do not want to attach data to those items, then you would use an array. If, however, you do want some data associated with each item on your list, you would use an Hash.

There are multiple different tests out there that purports to measure your “learning style”, even though there is no reliable scientific evidence of these tests measuring anything. Still, like any sort of evidence, they may still be useful to help guide you.

DevBootCamp mandated that I take one “learning style” test (the Gregorc Thinking Style test) before I can formally enter into the program. The Gregorc Thinking Style test classified me as a “Concrete Random” individual.I was not surprised by this result becuase I had already taken a similiar test (“True Colors”) and received the exact same results. The Gregorc Thinking Test defined “Concrete Random” learners as being experimenters who is willing to resort to trial-and error in order to solve a task.

That sounds like what I would usually do to learn a topic, and it does indicate that I need to keep doing that if I want to learn. I have already started several side-projects, and that gave me enough familiarity to perform well with the class material at DevBootCamp.

The biggest challenge for me are the assigned readings, and this makes sense, as the readings are divorced from actually coding. While I do like reading (and in fact, my VARK test reveals me as a Read/Write learner), I still have to take detailed notes and try to associate what is being written to what I am expected to do with the knowledge. Interpreting what I am reading (and applying that in my own coding practices) can be very difficult. I don’t want to misunderstand an author’s point. Ultimately, I only am able to fully understand the author once I complete the author’s exercises and solve the challenge (thereby sastifiying the ‘Concrete Random’ learning style).

The most important thing to realize though is that learning styles can change. They are not ‘fixed’ in stone, and they can grow and adapt to the environment. This is important for me because I need to be able to learn through multiple different ways. If I do not have a book to read, and I cannot tinker with something, I may not learn effectively! I could write down loads of notes and read them constantly, and then try to create a simulation based on those notes so that I can tinker around with that sim…but that seems incredibly inefficent.

Learning how to process information in multiple different ways, rather than in only one or two ways, is the key to success. And so long as you have these tests (however unscientific they are), you can always monitor your progress. I plan on taking some more tests in the future to see how my “learning style” has evolved through my experiences at DevBootCamp!

Introduction

Fads are real, and they can carry with rather painful consequences. Some new exciting new technology comes into existence (the Hula Hoop), and everyone starts using it and pressures you to start using it too. You give in and buy a Hula Hoop…and then everyone gets bored and moves onto the next technology. You have just wasted your money.

Just like there can be “product fads” (such as the Hula Hoop), there can also be “intellectual fads”, where some field or subject area becomes extremely popular for a short period of time before people gets bored and move on. These “intellectual fads” can be even more damaging than “product fads”, as you have not only wasted resources, but also time trying to master the new subject area. By the time you are actually semi-good in the new subject, everyone moved on to the next fad.

As beginning programmers, we do not have the time or the money to be chasing fads. We want to specialize in the fields that (a) we like and/or (b) will be popular for a long time. Understanding these fads is important, simply so that we can spot them and avoid them.

Unfortunately, according to Yali Peng, a scholar who studied “intellectual fads”, “a fad is not known as a fad until it’s over”.

The good news is…Yali Peng did come up with a way to explain how “intellectual fads” come into existence, in his 1994 article, Intellectual Fads in Political Science: The Cases of Political Socialization and Community Power Studies. He admits that his study only focused on political science, but I think his methodology could still be applicable to computer science. In any event, Yali Peng’s ideas are interesting and should be stated.

The Life of an Intellectual Fad

“Intellectual fads” exist in political science because there is a demand for them by “new” academics entering political science. These “new” academics are not experts in a specific subject area, and thus are not respected. Journal editors, conference organizers, even non-academics are willing to respect the experts, while “new” academics still have to prove themselves. If a “new” academic tries to compete in an established field, he will be competiting against experts. Most likely, the experts will win.

First, someone invents a brand new field (“Community Power Studies”), after being inspired by current news events (in this case, a popular book called Community Power Structure). There are no experts in this brand new field. There is nobody at the “top”, because there is not enough time for anyone to be at the top. The field is ripe for the taking[1].

So a few “new” academics enter into Community Power Studies, and start speaking their minds. Of course, these academics can argue with each other, but nobody can confidently say which academic is incorrect…because there’s no way to know what is incorrect. The field is brand new, after all.

Let me use a real-life example to help illustrate what I mean. In Community Power Studies, there was a debate over how to measure “community power”. Floyd Hunter, the author of Community Power Structure, relied on measuring the ‘reputation’ of elite power brokers, while a rival author (Robert Dahl) instead argued for looking at who actually make decisions in society. Despite the fact that Floyd Hunter invented “Community Power Studies” in the first place, he could not convincingly refute Robert Dahl, simply because the field that Floyd Hunter invented was new, and neither Floyd nor Robert were considered “experts” in that field yet.

Maybe an “established” expert in a different field may decide to enter into Community Power Studies himself and try his luck in this field. When he does this, he “legitimizes” the field and encourages other academics to join in the field as well. However, this time, the expert will be competing on an even playing field with the new “academics”.

Soon the fad generates its own enthusiasm. New journals are created, new conferences are being organized. Critiques of the fad are written, as well as counter-critiques. All that dialogue and conversation that are taking place serves as free advertisement for the fad, encouraging more academics to join in the feeding frezny and grab their slice of the ‘respect pie’.

After the initial state of growth and interest, Community Power Studies consolidates and becomes an “established” field. Few academics are recognized as “experts” in the new field. This means all the other academics who participated in the new field ends up being classified as “non-experts” and are thus not given the respect they previously had before. All these academics participated in the field because they hoped to gain respect… and now that respect has been taken away by someone else?

The non-experts leave the field at once, and as a result, the intellectual fad reaches its closure. Most likely, the non-experts will chase after another “new field” and try to gain respect in that field. Meanwhile, the “lucky” “experts” of Community Power Studies are no longer listened to as much as they did before. (The only reason people even listened to them in the first place was to try and gain respect in that field. Now that it is impossible to gain respect, the people leave.)

Conclusion

Intellectual fads, such as Community Power Studies, don’t die though. They tend to just fade away in importance. The experts in Community Power Studies still end up publishing in journals, attending conferences, and publish books. But less and less people care. Even today, in the community colleges where I once worked, an overview of Community Power Studies is still being taught (after all, power is important in political science). However, we spend about 3 minutes on the field, before moving onto the next PowerPoint slide. This is a far cry from the ~29 peer-reviewed articles and ~8 books that were published in 1975, at the height of this intellectual fad.

Did this article help you? Can you identify any intellectual fads that matched this life cycle of birth and decay? Please let me know by tweeting about it!

[1]Nobody consciously start fads in the first place, but they do see opportunities to advance their own “self-interest”, and they will take them if necessary. If there is a chance to get famous, people will likely take said steps.

Ever wonder how web developers are able to put images into horizontal rows, creating neat “galleries”? This blog post explains how web developers are able to create these galleries.

What is HTML and CSS?

Just like there are hundreds of “languages for humans”, there are also hundreds of “languages for computers”. HTML is one of those “languages for computers”, and its goal is to help your web browser understand how to display a website.

But today HTML is used to only create a website, not to make it look beautiful and interesting. Instead, we have a second “language for computer” to help your web browser make websites beautiful. That language is called Cascading Style Sheets (CSS). Good web developers must be masters of both HTML and CSS.

One thing that CSS affects is how images and text are displayed on a website. This is done through modifying the “Display” property in CSS. There are several different types of ways to modify “Display”, but the three most famous ‘display’ variables are Display: Inline, Display: Block and Display: Inline-Block.

Display: Inline

Inline ensures that text and images stays in nice, neat horizontal rows. For text, inline is a great property to have, because then you can read the text easily. But this picture has colored recentagles, which were given a certain width and height. To ensure that the recentagles are in nice, neat rows, “inline” ignores the dimensions of the recentagles and resizes them. If we want to make sure the rectangles keeps the same dimensions that we give it, we must use…

Display: Block

Block places each image on their own seperate row. There is also some whitespace to seperate the image from anything else on the website. This is good for putting images vertically on top of each other. The recentagles also keeps the width and height that we assigned it. But ‘display: block’ prevents us from putting images into horizontal rows. What if…we can combine both?

Display: Inline-Block

Inline-Block is a combination of both Inline and Block. The recetangles are placed on a single line, but keep their original dimensions. So instead of images being placed vertically on top of each other, now they are horizontally next to each other!

There are many uses for these three display properties. But because galleries require vertical rows and and images to keep their original size, most web developers use “Display: Inline-Block” when making web galleries.

Version Control - continuously backing up your code because you are afraid that you or someone else is going to mess that code up

Without VC:

I type a blog post (C1), and then later on modify the blog post (call this modified post C2). I then save this blog post. I lose the original C1, and instead replace it with C2.

I’m so excited with my new blog post that I modify the blog post again (C3) with a button to allow people to tweet my post, and then again (C4) with a twitter feed. After that, the excitment wears off and I leave the blog to rot.

Two months later, I realize that nobody is reading my blog. I travel to the website myself to find that even I can’t read my own blog either. Somehow, I have introduced a fairly minor “bug” while introducing all these awesome features that prevents people from reading text.

No, I don’t know where this bug is. And I won’t be able to know exactly when I introduced that bug. So I’m stuck. And I won’t be able to restore C1, the original that I know would work, because I had already deleted it. My blog is ruined, and I have to start all over again.

With VC:

I type up a blog post (C1), and then upload over to a Virtual Control System for safe-keeping. The Virtual Control System is essentially a service that stores all different versions of the same file in one easy-to-access location. So I never have to worry about losing C1, because the Virtual Control System will keep it for me.

I then continued modifying my blog post, and each time I do so, I upload my changes to the Virtual Control System. The VCS soon has a copy of C1, C2, C3, and C4 (the final update of my blog post).

Two months later, I found out nobody can read the text of my blog due to a “bug”, and this time, I now have options. First, I can look at C1, C2, C3, and C4 individually and search for clues for where the bug is. Second, I could restore from an earlier version of the blog (C3 instead of C4) and see if that would resolve the issue. If it does resolve the issue, then I know C3 is the problem, and I can start searching for problems there.

Finally, I can always do a hard-reset of the blog back to the original C1, which I know works, and then slowly add in new features until I see the “bug” again, and then start to fix it.

Without Version Control, you are doomed whenever you make a single mistake. With Version Control, you still have the copies of all your previous work, and you may still be able to fix your mistakes.

Using Git

Git is a popular Version Control System used by many developers. This program keep tracks of all changes you made to the file and saves it over to a git file. Then anyone can look at the “history” of my git file to find all my past versions of my project. So, in my blog example, I can easily see C1, C2, C3, and C4 by accessing the git file.

However, using a Version Control System only on my own computer is not enough. What happens if my own computer dies? Then I lose everything I saved on there. Luckily, there are multiple web sites that can host your git file and store every change you made. The most popular of these sites is “GitHub”. So, in case a computer dies, I can get a new computer, go online and then redownload my file from “GitHub”.

Of course, I could just save my git file onto a USB, and then keep that USB safe. Doing that however makes it hard for other people to help me improve my blog post, because they would need the USB to modify my file. Uploading my file to “GitHub” would allow other people to easily access my file and then suggest changes to me. These suggestions are known as “pull requests”. If I like the “pull requests”, I’ll acccept them and adapt them into my blog post.

The Merits of Command Prompts

While it is easy to download programs to help you manage Git, programmers prefer using Git by typing in commands into a command prompt. The command prompt is essentially a black screen where you type in a command (such as “cd C:\Programs” to access the Programs folder on your computer) to do stuff. Programmers like using command prompts because it is quicker to type in a “command” than it is to “click” on a button in a program. However, in order to use the command prompt, you have to actually know what commands to type. Buttons tend to have images and text to help you understand what will happen if you click on it, but to understand the command prompt, you have to read a long and boring manual…and the only way to get that manual is to type in a command in the command prompt.

Programmers want to complete jobs as quickly as possible, so they are willing to accept the inconvenience of memorizing commands to get the advantage of speed. If you want to delete 10 files, it’s much quicker to type out “rm [filename]” 10 times than it is to click on the delete button 10 times.

Note: This blog post was originally posted on 04/07/2015, and then last updated on 04/17/2015.

Research- the process of acquiring new information

My original goal in life was to become a college instructor in Political Science. When I was pursuing this career goal, I had to learn the critical skill of research, as college instructors are hired and fired on the basis of their research skills. I ultimately was able to research effectively enough to write a peer-reviewed article and acquire my Masters’ degree.

So when DevBookCamp informed in their Phase 0 Handbook that is necessary for programmers to learn how to do research correctly, I was shocked. I thought research is something that only academics and scientists do, not computer programmers. It’s possible research can be as simple as using Google to search for someone who has asked that very question and got an answer out. This type of “research” would be useful when dealing with low-level problems like…“What is the command I should use when renaming a file in Linux?” “Oh, it’s mv. Thanks Google.”

But it doesn’t have to be limited to that! In fact, there are many high-level questions (“What open-source license I should use?”,”How should I upgrade my computer?” “When should I refactor?”, etc.) where a more detailed approach to research would be ideal, instead of simply searching on Google and clicking on the first link.

So I thought back to my college days…and tried to remember the tips I used to successfully do research…

• Put a limit on how much time you are willing to do research! This was a step I had to learn the hard way, as there is always more and more information to learn about a subject. At the end of the day, you have to actually use that information somewhere.
• Learn how to skim to see if a source has the information you need. If it doesn't seem pertinent, drop it and move onto something else. If it does seem useful, then read it fully.
• If you are part of the team, to divide up the research work by having each person focus on one different research question. You can get a lot more ground covered quickly that way, and there's a better chance of success. Plus, if one person finishes with researching his specific question, then he can help the rest of the team out with their research.
• If your question is broad, divide it into more narrow questions. Knowing the answer to one narrow question can help you answer the other narrow questions, and soon you can piece together what you learnt to answer the larger question. If you are in a team, you can then give those narrow questions out to each member of the team.
• Somebody has already asked your question and wrote their answer. Their research may useful as a starting point for your research. It is not, however, a substitute to doing your own research.
• When reading anything, try to find out what unstated assumptions the author is making. It's possible that those arguments rely heavily on those unstated assumptions, and the argument is correct if and only if you accept those assumptions as valid.
• Look at multiple different locations: not just Google, Bing, and Yahoo! Some of your best sources may be hidden inside databases (such as JSTOR or Safari Books Online) that may require you (or your company) to pay out big bucks to get complete access. If you're luckily, these databases can offer a trial version that can give you the abil to tempt you to buy the full thing (JSTOR allows you to "check out" some academic articles to read).
• If you are going to stay on Google, think about using Google Scholar and Google Books in addition to your regular Googling. While most of those articles and books will be hidden inside databases that you have to pay to gain access, you do have access to previews and abstracts that can give you a good sense of their general arguments.
• Sometimes just knowing the title of an article is enough, as you can then do a regular Google search to see if there is a free version of the article. Sometimes, professors would upload a rough draft of their article on their personal website, to try and get more attention to their research.
• Go to the local library and check books out. Just because information is not digitialized doesn't mean it's not valuable.
• If you live close to a college or a university, also use their library. Those libraries will likely have a larger selection of books, which means there's a greater chance that you will find a book that will serve your purpose.
• Do not dismiss a source because it's too old. In fact, the fact that the source is old may yield interesting insights, simply because the old source is viewing the issue in a different light. Just remember to look at current sources too.
• Do not just rely on logical arguments, but also consult evidence on the issue. You really should not rely wholly on anecdotal evidence, since it can just be from sheer chance, but even that type of evidence can still be useful. I prefer to read peer-reviewed articles, scientific polls, case studies and controlled experiments.
• Carefully examine the methods used in collecting the evidence. If the methods are faulty, then the conclusions can be faulty too. Do not discount a faulty study entirely though; just like anecdotes, they can still be useful.
• Your research will require you to consult multiple different viewpoints, many of whom are going to be unreliable. You have to use critical thinking to weigh your sources carefully, and look at the arguments and evidence being offered to back their points up.
• Generally, if someone makes an argument in favor of some idea, someone else will have written a rebuttal (and said rebuttall also has a rebuttal). Read both the pro and the con. Knowing how one side responds to the other can give you a better insight into their arguments.
• Some questions are going to be so specific that none of your sources will the complete answer you are looking for. But, people do have snippets of the answer, and you can use those snippets to create a complete picture.
• Write down everything you learned so you can consult your "cheat sheet" in case you forget. Do not trust your memory to keep everything for you. Preferably, take notes on all the sources you are reading.
• Write down your reflections on what you read as well.
• If you are able to, examine primary sources. Instead of simply relying on a person's description of the program, take a look at the source code of the program yourself!
• You can never be 100% certain that the final product of your research is correct. At best, you can find a position that has strong empirical and logical backing, but there's always the possibility that future evidence may prove you wrong. You will have to live with ambiguity, or be forced to spend the rest of your life researching that one question. That's not a fate that I would want anyone to face.
</ul> I hope this information would be as useful to you as it was for me. Even if it is hard to keep all these bullet points in mind when researching the latest problem, at least one or two of these bullet points should help guide you on the path to success.

Educational Philosophy - a statement that tells how you or your school plans to teach others

In the video <a href=https://vimeo.com/85001014>”Fireside Chat with Shereef: Kitchen vs. Table”</a>, Shereef details the educational philosophy of DevBootCamp. DevBootCamp does not want people to simply regurgitate knowledge that is handed to them by teachers. Instead, DevBootCamp wants students to become self-motivated and thereby “own” their own education.

The hope is that students would conceive themselves not as passive consumers of their educational experience (only using the product to get a “better job” and then placing said product back onto the shelf), but instead as active creators (the ones making the products), hoping to show their talents to the general public and impress not only their teachers, but themselves in the process. Sherfeef claims that once students learn how to be active creators, they will then be able to perform effectively in the workplace and improve their skills after graduation from DevBootCamp. Sherfeef also wants to encourage students to work with each other and learn from each other.

Sherfeef also stated that DevBootCamp does not believe in the idea of a single right answer. This idea was repeated in the Phase 0 Handbook (there are only two type of answers: answers that work, and answers that need work). But Sherfeef also attempted to describe coding as a “craft” where you are building something, and everyone is working together to improve on it. There’s no one “right” answer for building a program, and there’s multiple different approaches you can take. Therefore, this is a field that encourages creativity and free-thinking instead of thinking inside the box.

This speech was very useful for me because I did not actually view DevBootCamp in that fashion before. Before, I just thought of DevBootCamp as a place where you receive lessons from the teachers, and then you fufill said lessons. I knew that I was expected to do my own “research” and learn outside of DevBootCamp, but I did not realize that DevBootCamp’s main goal is reduce the role of the teacher to that of a facilitator (a person who will provide support and the underlining objectives for the students to accomplish, but will avoid lecturing to students and telling them what to do).

I am both nervous and excited. I am nervous because I am afraid I would not get the support I need to be able to survive, both from the community and the teachers. I will need that support, because I am not confident in my ability to create something workable on my own. But I am also excited because I am self-motivated, I do like creating stuff, and I do like the idea of there not being a single 100% correct answer to a problem. My impression of DBC had changed after Shereef’s speech, and this speech gave me a better sense of the culture within DBC.

Now that I know the culture, I can be better able to adapt to it and be able to more effectively deal with the challenges that DBC throws at me.