Code Monkey home page Code Monkey logo

homoiconic's Introduction

What was Homoiconic?

Homoiconic was an experiment in publishing code and words about code on a small scale. When I wrote, I added files to the homoiconic git repository, organized by date. Code was included in the posts and also in the folder with the posts that discussed them, so it was easy to download what you liked. You could (and still can) download the entire site as an archive!

Homoiconic was really simple: Snippets of code and words about snippets of code. I avoided words by themselves. And the words existed to amplify and explain the code, rather than the code existing to illustrate the words. This was the opposite of most of the posts we could find on traditional (circa 2004) blogs.

what can I read right now?

Asking me what to read is like asking the chef what's good on the menu. It's all excellent, of course! That being said, I had a few personal favourites:

Many people link to my series on combinators: Kestrels, The Thrush, Songs of the Cardinal, Quirky Birds and Meta-Syntactic Programming, Aspect-Oriented Programming in Ruby using Combinator Birds, The Enchaining and Obdurate Kestrels, Finding Joy in Combinators, Refactoring Methods with Recursive Combinators, Practical Recursive Combinators, The Hopelessly Egocentric Blog Post, and Wrapping Combinators.

There are also a few things about abstractions, functional programming, meta-programming, metaprogramming again, and brevity.

Of course, you can simply read the archives. They're organized by date, so the most recent writing is at the bottom, not the top.

is there anything else to read?

My current blog is called raganwald.

is this code clever?

Whoa, Nellie! Easy with the word "clever." Being interested in some of the things that interest smart people is not the same thing as being smart. Especially in my case. So before rushing off to use each and every technique presented here, be mindful of the fact that programming requires judgment, it isn't a perfectly logical process of solving problems using whatever tools, materials, and techniques happen to be within reach. You don't want to provoke responses like this:

Why do I have a feeling that the professional code you write would be too "clever" for most developers to understand? --devinus

My goal is to be able to say that thinking about the code and ideas presented here is a useful way to learn and grow, whether you use any of this code or not.

credit where credit is due

I originally set up a blog at homoiconic.com, but I spotted David Baldwin's blog, and I knew right away that a blog that is about the how of code ought to be hosted on Github.


(Spot a bug or a spelling mistake? This is a Github repo, fork it and send me a pull request!)

I am Reg Braithwaite. You can reach me by email. My first name is reg, and that works fine for sending email to braythwayt.com. I look forward to hearing from you.

homoiconic's People

Contributors

aag avatar aaronblohowiak avatar bkudria avatar cawel avatar codelahoma avatar cubedice avatar dubek avatar exogen avatar grncdr avatar hardbap avatar hjr3 avatar insin avatar jewel-andraia avatar jonelf avatar joshuacc avatar mattwildig avatar morendil avatar mre avatar nschubach avatar raganwald avatar samwhited avatar steveklabnik avatar xentac avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

homoiconic's Issues

A few examples don't pass JSHint

I parsed the Markdown files, converted them to markdown, extracted the <pre><code>...</code></pre> tags, and ran the inner code through JSHint (using Node.js, but I excluded all the warnings about missing semicolons)...

Not sure how many are valid, versus expected warnings for null type checking.

https://raw.github.com/raganwald/homoiconic/master/2012/12/combinators_1.md

var inventory = {
  apples: 0,
  oranges 144,
  eggs: 36
};

get('oranges')(inventory)
  //=> 144

Errors:

  1. line:3 char:11 -- Expected ':' and instead saw '144'.
  2. line:3 char:14 -- Expected an identifier and instead saw ','.
  3. line:4 char:3 -- Expected '}' to match '{' from line 1 and instead saw 'eggs'.
  4. line:4 char:7 -- Expected '(end)' and instead saw ':'.

function isSomething (value) {
  return value != null
}

function checksForSomething (value) {
  if (isSomething(value)) {
    // function's true logic
  }
}

Errors:

  1. line:2 char:16 -- Use '!==' to compare with 'null'.

function maybe (fn) {
  return function () {
    var i;

    if (arguments.length === 0) {
      return
    }
    else {
      for (i = 0; i < arguments.length; ++i) {
        if (arguments[i] == null) return arguments[i]
      }
      return fn.apply(this, arguments)
    }
  }
}

Errors:

  1. line:10 char:26 -- Use '===' to compare with 'null'.

function checksForSomething = maybe(function (value) {
  // function's true logic
});

Errors:

  1. line:1 char:29 -- Expected '(' and instead saw '='.
  2. line:1 char:36 -- Expected ')' to match '=' from line 1 and instead saw '('.
  3. line:1 char:37 -- Expected '{' and instead saw 'function'.
  4. line:1 char:46 -- Missing name in function declaration.
  5. line:3 char:2 -- Expected an identifier and instead saw ')'.
  6. line:3 char:2 -- Expected an assignment or function call and instead saw an expression.

https://raw.github.com/raganwald/homoiconic/master/2012/12/combinators_2md

function (boundmethod) { 
  return boundmethod() 
}

Errors:

  1. line:1 char:10 -- Missing name in function declaration.

function Cake () {}

extend(Cake.prototype, {
  setFlavour: function (flavour) { 
    return this.flavour = flavour 
  },
  setLayers: function (layers) { 
    return this.layers = layers 
  },
  bake: function () {
    // do some baking
  }
});

var cake = new Cake();
cake.setFlavour('chocolate');
cake.setLayers(3);
cake.bake();

Errors:

  1. line:5 char:26 -- Did you mean to return a conditional instead of an assignment?
  2. line:8 char:25 -- Did you mean to return a conditional instead of an assignment?

string_to_proc may be a code smell

It is a code smell to use programming language constructs to evaluate strings as code, especially where other metaprogramming facilities are readily available. Side effects include, but are not limited to, damaging syntax highlighting and a variety of code inspection / debugging tools.

In general, the string_to_proc method scares me and seems like fundamentally a bad idea.

How About *easier*

I wonder if you really need push to return the pushed value ... what's the use case and why would you need that ? ... cause things could be much easier and faster just using Array.

    function StackMaker() {
      var a = [];
      a.isEmpty = StackMaker.isEmpty;
      return a;
    }
    StackMaker.isEmpty = function () {
      return this.length < 1;
    };

What do you think ?

Discussion?

Hi, I don't want to mess here with discussion about the article, but where can I do so?

The mentioned hacker news discussion page seems to be closed.

Client

This would be even more awesome with a front-end besides github's.

I may in fact start working on such a thing.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.