Stuff I learned at the Melbourne CFAR workshop. Class name was offline habit training, i.e. actually performing your habit multiple times in a row, in response to the trigger. Salient examples: Practicing getting out of bed in response to your alarm, practice walking in the door and putting your keys where they belong, practice putting your hands on your lap when about to bite nails, practice straightening your neck when you notice you're hunched. These are all examples I've implemented, and I have had good results.

Adding associations is a key part, too. For these examples, I imagine the alarm as an air raid siren and my house getting bombed if I don't get out of bed on time. I imagine Butch being shot by Vincent in an alternate version of Pulp Fiction if his father's watch wasn't on the little kangaroo and he had to hunt around for it. For biting my nails, I imagine Mia Wallace being stabbed in the heart . The connection here is biting nails can make you sick. The vividness and intensity makes up for how tenuous that is. For posture, I imagine Gandalf the Grey compared to Gandalf the White (plus triumphant LoTR music).

Since I made that comment, I got about a third of the way through Moonwalking With Einstein, and practiced the Memory Palace/method of loci a couple of times. I've lived in a bunch of different houses, so that works pretty well for me. Some of the stuff that was mentioned sounds a lot like spacing techniques. ""[...] if you revisit the journey through your memory palace later this evening, and again tomorrow afternoon, and perhaps again a week from now, this list will leave a truly lasting impression."

This is another bit of evidence suggesting that spaced repetition would be powerful in combination with mnemonics. What Anki provides, which is far more important than the flashcard thing, is testing. I've been thinking about applying some of the ideas from test-driven development to self-programming, and Anki cards would be a core part of that.

Sorry, I realize most of that isn't relevant, but I hope the parts that were are useful.

This is not quite a "tech-tree" dependency structure, but you can use tags to stratify your cards and always review them in sequence from basic to dependent (i.e., first clear out the "basic" cards, then "intermediate", then "expert"). Even if the grouping is arbitrary, I think you can go a long way with it. If your data is expected to be very large and/or have a predictable structure, you can always go for a "multiple-pyramid" structure, i.e, have "fruits basic" < "fruits advanced" < "fruits expert", "veggies basics" < "veggies pro" tags &c, and perhaps even have an "edibles advanced" > veggies & fruits tag for very dependent cards.

On the assumption that the Anki algorithm works, just "reviewing down" to an empty deck every tag and proceeding thus sequentially from tag to tag, I think this would work too. Even if it so happened that by one Sunday you forgot "What is an American president" (basic) fact, it might still be profitable to rehearse that day the "Washington was the first president" card, despite the "20 rules" mentioned somewhere above. Presumably, if you had forgotten what a president is, the appropriate card is probably going to appear for review in the next few days, and so with a consistent (or even a semi-consistent) use of Anki, it would probably turn alright. This is more for the anecdotal sake, but this reminds me a time when I burst out laughing out loud while at the dictionary. I was reading at the time "Three Men in a Boat", and there was one sentence in which I didn't know 2-3 of the words; the punchline clicked as I read the definition of the last of them.

Either way, somewhere higher on this commenting thread, I have also thought about the possibility (or rather, lack of) of creating dependencies in Anki. I'm actually thinking of creating an add-on/plugin to enable that--- I'm learning Python these days (on which Anki runs), and I'm just about to start grad school (if I get admitted), so it seems like just the right time to make this (possibly major) meta-learning investment.*

* Not to mention that, since I'm learning Python, it's also a (non-meta) learning investment. Win-win.

Good information! This is really more "a vote against flashcards" than "a vote against spaced repetition", though, at least given your concrete issues with flashcards. Spaced repetition is an algorithm for figuring out when to review material that you want to memorize; flashcards are one thing that spaced repetition is applied to, because it's easy to stick flashcards in a computer. As far as I know, no matter what object-level mnemonic devices you're using, spaced repetition is still strictly better than "when I feel like I'm forgetting" or "right before a test" or any of the other obvious review strategies, if you can deal with the cognitive load of scheduling things, or get a computer to do it for you.

Is there space for some sort of SRS that allows for input of the more helpful types of memorizations that you listed (pictures, venn diagrams, etc.)?

The general idea of Anki is that you learn the knowledge first and then put it into Anki to avoid forgetting it.

Not necessarily. In some cases, the flashcard format is quite suited for learning new content as well - especially such things as vocabulary. Allowing inter-card dependencies could easily expand on these use cases.

It would also be directly useful in language learning: for instance, you could memorize some vocabulary words and then be prompted to learn related idioms, or collocations (i.e. words that are "often used together"). Despite its usefulness, this content is quite hard to memorize effectively in the absence of such specialized support.

For what it's worth: Though I do not claim to be a perfect user of SRS flashcards, I used them intensively for 3 years of medical school, constantly refining my technique. Many people here have suggested ways to improve my strategies. I have not yet seen an idea that I have not already tried extensively. Though I'm far from perfect, I think it's safe to say I have a better understanding than most beginners. There certainly is room for me to improve, but not much. If someone is considering using SRS long term for high volumes in medical school, here is my advice: it is possible a Perfect SRS User could use it more effectively than I did, but if you haven't already used SRS for years, you aren't such a person.

I never read that article, but I figured out many of those on my own. I agree with many of them, disagree with some. My input, for those that use it:

-Cloze deletion is simple, but to me, it is far too easy to "guess the teacher's password" using that technique, and is of limited use. It's great for high-school level fact regurgitation, but less useful for post-graduate stuff. You will quickly become good at the deck, but it does not strongly help your understanding of the material. That's an important point: your skill at answering questions in the deck does not necessarily translate to your skill at answering questions in real life.

-Graphic deletion - I used to do this all the time, but it is really time consuming to set up. I consider myself fast with an image-editor, but it's still a big drain. (Again, this is more of an issue in high volume) It also runs into the Cloze deletion problem.

-Use imagery: heck yes. I highly agree, in any situation (flashcards or no)

-Any technique splitting a larger whole into many smaller flashcards (the article lists several): This is possibly the WORST suggestion for high volume. While this is certainly very useful, again, when you use it in high volume I have found mental fatigue to become an issue. If you don't include the entire whole, you miss out on the big picture in a situation where the big picture truly is important. If you DO include the whole, you run into the cloze deletion "guessing the teacher's password" problem. That said, it has its uses in smaller volume, but I will never again use it in a high-volume deck.

To give an example: As the article suggests, I used to take a diagram, set up graphic deletion (make a series of images where a single element was blotted out), and run through the cards.

1) this takes a lot of startup time

2) Even ignoring the time to make the cards, I found reviewing the cards to be more time consuming than simply looking at the diagram, covering up the lables, and attempting to recall.

3) You get no practice recalling the diagram from memory

4) This technique is most effective if you will later see that exact diagram in real life/on the test, I argue it is a pitfall for guessing the teacher's password and provides less intuitive understanding of the diagram.

The strength in SRS comes from not wasting time on the easy parts and only spending time on the hard parts of the diagram. The theory is, after the first two cycles, you're only reviewing the "hard" parts of the diagram. On the other hand, you've spent more time making the cards, more time for the first and second card cycles, you're taking a big hit to the "big picture" style, and have no practice conjuring the diagram itself from memory. Ignoring the big picture and general understanding elements: if SRS provides any time benefit for the rote memorization vs going without SRS cards, i would only expect the benefit to "catch up" in 3 weeks BARE minimum; for me (for fatigue reasons in high volume) I pin the crossing point at 3 to 6 months, assuming it's an unintuitive diagram I use infrequently enough that I will forget it without review. I also argue that it provides a weaker general understanding of the diagram as a whole.

Think of programming paradigms as construction techniques and programming languages as tools. There is no technique or tool that is ideal in all situations.
If you want a broad education, you might want to study one representative language for any of the main paradigms, for instance C (imperative, static typed), C++/Java/C# (imperative-object oriented, largely static typed), one of the Lisp family, such as Scheme (multi-paradigm, mostly imperative and functional, metaprogramming, dynamic typed), and one of the ML family, such as F# (functional and imperative, static typed).
Python is very popular and very useful, and its basic syntax is easy to learn, but given that it is rather multi-paradigm and very high level (hiding lots of the underlying complexity) perhaps it is not the ideal place to start if you want to really understand what programming is about. At least, learn it aside something else. Similar considerations apply to "Python-like" languages such as Javascript, Ruby, Lua, etc.

But as I understand, what you say is that if one opts for going for Haskell, he'd be better off going for F# instead?

Generally yes.

Haskell forces you to program in the pure functional programming paradigm. This, and other related idiosyncrasies of the language (such as default lazy evaluation), require you to use specific design patterns which take time to learn and even when mastered are of questionable convenience. At best, they don't seem to provide any advantage, and at worst they actively harm expressivity and efficiency.
Haskell seems mainly used by enthusiasts for hobby purposes, there seems to be very little free software written in Haskell besides tools for Haskell itself. Some companies claim to use it for commercial software development and/or prototyping, but it appears to be a small market.

If you like the static-typed functional approach, but you don't want to struggle with the pure functional paradigm, you may want to take a look at the ML family: F# is the biggest, Microsoft-backed, member of the family, it runs on .NET but it has an open source compiler and runs on Mono. OCaml is its non-.NET ancestor which still has some significant user base.
If you prefer dynamic typing, then try Scheme (Racket).

Would be cool if one of the items was a nugget of "computation fuel" that could be used to allow a robot's register machine to run for extra steps. Or maybe just items whose proximity gives a robot extra computation steps. That way you could illustrate situations involving robots with quantitatively different levels of "intelligence". Could lead to some interesting strategies if you run programming competitions on this too, like worker robots carrying fuel to a mother brain.

Hey,

Sounds very cool, promising and enticing. I do have a technical question for you (or anybody else, naturally).

I was wondering how "intentional" the choice of Haskell was? Was it chosen mainly because it seemed the best fitting programming language out of all familiar ones, or due to existing knowledge/proficiency at it at the time of formulation of the bot-world idea? How did cost/utility come into play here?

My inquiry is for purely practical, not theoretical purposes--- I’m looking for an advice. In the summer two years ago I was reading as much as I could about topics related to evolutionary psychology and behavioral ecology. During the same period, I was also working with my physics professor, modeling particle systems using Wolfram Mathematica. I think it was this concurrence that engendered in me the idea of programming a similar to yours, yet different, “game of life” program.

Back at the time programming things in AutoHotkey and in Mathematica was as far as my programming went. Later that year I took a terribly basic python course (that was concerned mainly with natural language processing), and that was about it. However, in the last couple of weeks I returned to python, this time taking the studying of it seriously. It brought back the idea of the life game of mine, but this time I feel like I can acquire the skills to execute the plan. I’m currently experiencing a sort of honeymoon period of excitement with programming, and I expect the following few months, at least, to be rather obligation-free for me and an opportune time to learn new programming languages.

I’ve read the above post only briefly (mainly due to restrictions of time--- I plan to read it and related posts soon), but it seems to me that our motivations and intentions with our respective games (mine being the currently non-existing one) are different, though there are similarities as well. I’m mainly interested in the (partially random) evolution/emergence of signaling/meaning/language/cooperation between agents. I’ve envisioned a grid-like game with agents that are “containers” of properties. That is, unlike Conway’s game where the progression of the game is determined purely on the on-the-grid mechanics, but like yours (as I understand it), where an individual agent is linked to an “instruction sheet” that lies outside the grid. I think what differentiates my game from yours (and excuse me for any misunderstandings), is the “place” where the Cartesian barrier is placed. [1] While in yours there’s the presence of a completely outside “god” (and a point that I had missed is whether the “player” writes a meta-language at t=0 that dictates how the robot-brain that issues commands is modified and then the game is let to propagate itself, or whether the player has a finer turn-by-turn control), in mine the god had simply created the primordial soup and then stands watching. Mine is more like a toy, perhaps, as there is no goal whatsoever (the existential version?). If to go with the Cartesian analogy, it’s as if every agent in my game contains an array of pineal glands of different indices, each one mapped to a certain behavior (of the agent), and to certain rules regarding how the gland interacts with other glands in the same agent. One of the “core” rules of the game is the way these glands are inherited by future agents from past agents.

What I had foreseen two years ago as the main obstacle to my programming of it remains my current concern today, after I had acquired some familiarity with python. I want the behavior-building-blocks (to which “the glands” of the agent are mapped to) to be as (conceptually) “reduced” as possible –– that is, that the complex behavior of the agents would be a phenomenon emerging from the complexity of interaction between the simple behaviors/commands –– and to be as mutable as possible. As far as I can tell, python is not the best language for that.

While browsing for languages in Wikipedia, I came across LISP, which appealed to me since it (quoth Wikipedia) “treats everything as data” – functions and statements are cut from the same cloth, and it is further suggested there that it is well suited for metaprogramming. What do you (or anybody else in here) think? Also, quite apart from this pursuit, I have intentions to at least begin learning R. I suspect it won’t have much relevancy for the construction of this game (but perhaps for the analysis of actual instance of the game play), but if it somehow goes into the consideration of the main language of choice--- well, here you go.

Thank you very much for your time,

[1] My point here is mainly to underscore what seem to be possible differences between your game and mine so that you could – if you will – advise me better about the programming language of choice.

Hey,

Sounds very cool, promising and enticing. I do have a technical question for you (or anybody else, naturally).

I was wondering how "intentional" the choice of Haskell was? Was it chosen mainly because it seemed the best fitting programming language out of all familiar ones, or due to existing knowledge/proficiency at it at the time of formulation of the bot-world idea? How did cost/utility come into play here?

My inquiry is for purely practical, not theoretical purposes--- I’m looking for an advice. In the summer two years ago I was reading as much as I could about topics related to evolutionary psychology and behavioral ecology. During the same period, I was also working with my physics professor, modeling particle systems using Wolfram Mathematica. I think it was this concurrence that engendered in me the idea of programming a similar to yours, yet different, “game of life” program.

Back at the time programming things in AutoHotkey and in Mathematica was as far as my programming went. Later that year I took a terribly basic python course (that was concerned mainly with natural language processing), and that was about it. However, in the last couple of weeks I returned to python, this time taking the studying of it seriously. It brought back the idea of the life game of mine, but this time I feel like I can acquire the skills to execute the plan. I’m currently experiencing a sort of honeymoon period of excitement with programming, and I expect the following few months, at least, to be rather obligation-free for me and an opportune time to learn new programming languages.

I’ve read the above post only briefly (mainly due to restrictions of time--- I plan to read it and related posts soon), but it seems to me that our motivations and intentions with our respective games (mine being the currently non-existing one) are different, though there are similarities as well. I’m mainly interested in the (partially random) evolution/emergence of signaling/meaning/language/cooperation between agents. I’ve envisioned a grid-like game with agents that are “containers” of properties. That is, unlike Conway’s game where the progression of the game is determined purely on the on-the-grid mechanics, but like yours (as I understand it), where an individual agent is linked to an “instruction sheet” that lies outside the grid. I think what differentiates my game from yours (and excuse me for any misunderstandings), is the “place” where the Cartesian barrier is placed. [1] While in yours there’s the presence of a completely outside “god” (and a point that I had missed is whether the “player” writes a meta-language at t=0 that dictates how the robot-brain that issues commands is modified and then the game is let to propagate itself, or whether the player has a finer turn-by-turn control), in mine the god had simply created the primordial soup and then stands watching. Mine is more like a toy, perhaps, as there is no goal whatsoever (the existential version?). If to go with the Cartesian analogy, it’s as if every agent in my game contains an array of pineal glands of different indices, each one mapped to a certain behavior (of the agent), and to certain rules regarding how the gland interacts with other glands in the same agent. One of the “core” rules of the game is the way these glands are inherited by future agents from past agents.

What I had foreseen two years ago as the main obstacle to my programming of it remains my current concern today, after I had acquired some familiarity with python. I want the behavior-building-blocks (to which “the glands” of the agent are mapped to) to be as (conceptually) “reduced” as possible –– that is, that the complex behavior of the agents would be a phenomenon emerging from the complexity of interaction between the simple behaviors/commands –– and to be as mutable as possible. As far as I can tell, python is not the best language for that.

While browsing for languages in Wikipedia, I came across LISP, which appealed to me since it (quoth Wikipedia) “treats everything as data” – functions and statements are cut from the same cloth, and it is further suggested there that it is well suited for metaprogramming. What do you (or anybody else in here) think? Also, quite apart from this pursuit, I have intentions to at least begin learning R. I suspect it won’t have much relevancy for the construction of this game (but perhaps for the analysis of actual instance of the game play), but if it somehow goes into the consideration of the main language of choice--- well, here you go.

Thank you very much for your time,

[1] My point here is mainly to underscore what seem to be possible differences between your game and mine so that you could – if you will – advise me better about the programming language of choice.