rads

Day-to-day life isn't superficial to everyone.

No method_missing please. The lack of it is one of the things I appreciate about JavaScript in contrast to Ruby. It's used similar to macros, but it tends to be used by those who forget that the first rule of macros is Don't Write Macros.

"It's incompatible with standard Javascript libraries, which is why you would use Dommy because you can't use jQuery."

Not true.

    (def $ js/jQuery)
    (.append ($ "body") "hello world")

The reasons you'd use Dommy over jQuery are outlined in the original post.

I never felt like I was doing my best at college. After my first internship at a large software company, I didn't understand why people had told me to stay in school for as long as I could. I actually wanted to start working! So, a year before graduating, I dropped out and moved from Wisconsin to California.

I worried at first that my lack of a degree would make it hard for me to find a job in the Bay Area, but the market is incredible right now. If you're good enough, it doesn't matter if you have a degree. I managed to find a great job with people I have fun working with. Sometimes I forget I'm getting paid for it.

Reader, your mileage may vary. College is great, but it's not for everyone. I got a lot out of my three years (especially studying abroad -- if you can afford it, do it), but I knew I was ready for something else. The other path turned out great for me.

Slate probably thinks it's worth giving up short-term profits for long-term reader trust, which is particularly important for an online newspaper. The referral money is still money, but it's icing on the cake.

Who are you to say what people should enjoy doing in their free time? You know what's bottomlessly tedious? Doing things you wouldn't normally do simply to appear more interesting to people who don't get you.

That example is full of state. There's nothing to prevent you from calling any of those setX methods at a later point in time and changing the object's state. That interface very well could avoid state, but Swiftmailer doesn't seem to be implemented in that way. [1]

The stateless way would be to return an entirely new Swift_Message instance with each setX method. In languages that aren't built with immutability in mind, like PHP and Java, you end up instantiating and throwing away a lot of objects. Sometimes it doesn't matter, but when it does you use a mutable Builder to create the immutable instances.

[1] http://swiftmailer.org/docs/messages.html

Here's another mirror: https://dl.dropbox.com/u/249607/all/Statecharts.pdf

One problem with a state machine approach compared to MVC is that it isn't as familiar. Do you use a Moore or a Mealy machine? A combination of the two? Most people don't use state machines to model the flow of an entire web application, so if you try it out, you might feel like you're on your own.

It can be worth it, though. I used state machines for a client-side UI in ClojureScript a few months ago. It forced me to think hard about the structure and flow of the app. But after that, my state was in an explicit, contained area. If I had been using something like Backbone, the state would have been hidden among the various model objects. I felt like I had a much better mental model of how the program worked after the initial design process. Keeping state in control reduces complexity. [1]

Another benefit was that the state machine library I used allowed me to audit the trail of states as they happened. When a user toggled a checkbox to trigger an event, I could look in the JS console and see the moment the checkbox was triggered. If something wasn't working, I could often debug it by seeing if the states and transitions happened in the right order. I wouldn't be able to do this with a traditional MVC framework.

There's one very important thing that nobody has mentioned yet: state machines look ugly in your code. When they get big, they are difficult to follow. I started out using a state machine library that was just too simple. Once the interactions became complex, I was getting lost in my code. I looked for a clearer, more succinct way of modeling state machines, and eventually I came to Harel statecharts. [2]

Statecharts are a way to model state machines without explicitly writing out a ton of redundant states. The number of states becomes a problem when you actually try to model an application with a basic non-deterministic FSM. If you're interested in using state machines in your web application, you need to read the linked paper. The example of modeling a digital watch with statecharts makes it easier to see how you could use them in a web app.

I believe statecharts are to MVC as Clojure is to every mutable state language out there. It feels weird at first, but once you get used to it, it's much simpler. It's just not necessarily easier. [3] If you want to try them out, there's a good library called Stativus for writing statecharts in JavaScript: https://github.com/etgryphon/stativus/

[1] See "Out of the Tarpit" for why state and complexity are closely related: https://dl.dropbox.com/u/249607/all/Out%20of%20the%20Tarpit.... (The original link is down, so I made a mirror.)

[2] The original article on statecharts: http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Stat...

[3] More about the idea that simpler things are not necessarily easier: http://www.infoq.com/presentations/Simple-Made-Easy

All this talk about IE usage numbers led me to a website Microsoft made to say goodbye to IE6: http://www.ie6countdown.com/

The site reports that in the US, IE6 has 0.6% market share — relatively nothing. But look over at China: 22.4% of its 500 million Internet users still browse with IE6. Moving forward benefits the Internet as a whole, but the Chinese market is one instance where backward compatibility is important.

Yes, functional programming does give you more options, and that's the point. Each style of programming -- functional, object-oriented, relational, imperative, etc. -- has its strengths and weaknesses. It's up to the programmer to choose which one best fits the problem at hand.

In some languages, like Java, you're stuck in the OO style of programming because its syntax and features make anything else too cumbersome. Clojure actually works the other way around: though the most common style is functional, it's easy to work in terms of objects. It might not look the same as Java OO, but that's for the better.

Here's a good book about switching between programming styles within a single program: http://www.amazon.com/Concepts-Techniques-Models-Computer-Pr...

This article was last updated January 14, 2012. Since then, a number of real-time JavaScript frameworks have been released, like Meteor, Derby, and Firebase. You can't have a complete picture of the JS framework landscape without these newcomers.

http://meteor.com/ http://derbyjs.com/ http://firebase.com/

Cheddar is the name of his app: https://cheddarapp.com/

Bootstrapping and consistency across platforms. The goal of Clojure-in-Clojure is to write the Clojure compiler in as much of Clojure itself as possible. Right now the ClojureScript compiler is actually closer to this goal than the Clojure compiler.

If ClojureScript were ported to the JVM, maybe it would replace the current Clojure compiler as the official implementation. Clojure-in-Clojure would be further along, and implementations across host platforms would share a larger portion of code.

"If the GPL doesn't work for your project, get in touch (contact@meteor.com) and we will write you a commercial license to your specifications. We are happy to be flexible. What's important is that we have a conversation about how you are using Meteor, and what support and further development you need, so we can keep everyone in the community on the same page."

http://meteor.com/faq/how-is-meteor-licensed

I had one of the authors of this book, Remzi Arpaci-Dusseau, as a professor for my OS class last spring. It was one of the best classes I've ever taken. This book is a direct result of the effort he puts into his teaching. In light of the recent submission about XV6 (http://news.ycombinator.com/item?id=3753216), this book will be very helpful if you want to dig into its internals.

It depends on the person. Does writing tests help you understand the problem, and if so, does that help you solve it faster? Only you can answer that. Here's a quote from Rich Hickey that really struck home with me:

> I never spoke out 'against' TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design. (http://www.codequarterly.com/2011/rich-hickey/)

Another question to ask is does this help others understand the problem? You often don't write tests for yourself, but for other people, including the later you that has popped the problem off the mental stack long ago. Writing tests might lose you time right now, but the net gain of time saved by others may make up for it. Let me emphasize the word "may", because you might make the problem clearer by writing documentation in English rather than code. So the only conclusion is that it depends, it depends...

I just installed the preview myself, and the answer is yes! It still gives the other displays a linen background and renders them useless, though.

My favorite programming music:

  Any of Brian Eno's ambient stuff
  The Field - From Here We Go Sublime
  The Field - Looping State of Mind
  Luomo - Vocalcity
  Boards of Canada - Music Has the Right to Children
  Boards of Canada - Geogaddi
  Pantha Du Prince - Black Noise
  Burial - Untrue

Does Mountain Lion allow you to make apps full-screen on non-primary displays? This is the main problem I have with Lion.

As one commenter pointed out: I didn't know you could buy DVDs in 1995.

I switched to this from Command-T for some key reasons:

- Faster.

- Includes a most recently used list.

- Creates files with <c-y>.

- Automatically :cds to the project directory using Git or a dotfile.

However, there were a couple problems I had to fix myself:

- Doesn't follow symlinks, though it did in the older versions. This should be a config variable.

- Breaks on filenames that have spaces.

Those issues aside, this is great. Thanks!

If you squint (a lot), /. looks like a lambda.

I think I was twelve or thirteen when my parents bought me my own Mac. I didn't know this then, but, besides my parents and close friends, Steve Jobs was one of my most important role models. He made Apple unstoppable, but even during the hard times he had a dead set focus on making products people would really love, even if many others didn't like them. He was so passionate about his job; he loved it so much that it inspires me that one day I can start a business and have a job that I love, making things that other people love. RIP Steve.

Militia

The tape installations in the photos are so cool. I looked up the designer, Stephen Doyle. His firm has an impressive portfolio: http://doylepartners.com/

Some of my favorites:

http://doylepartners.com/project/hypertext/index.html

http://doylepartners.com/project/david_byrne/index.html

http://doylepartners.com/project/thinking_fingers/index.html

I haven't read this book, so I don't know what it's actually like. I could be completely wrong about this. However, if in my first days of programming I was given a book on low level details such as signed vs. unsigned numbers, I wouldn't have wanted to become a programmer right then.

My programming career started with Webmonkey's PHP tutorial[1], when it was first published some years ago. It doesn't talk about floating point operations or binary representations. Instead, you first learn how to print "I am the CHICKEN MAN" in your browser. Shortly after, you're taught to use forms, and by then you've created something that takes input and processes it.

You type your stuff in, click the button, and it shows up in the browser. The code you wrote -- this strange language that seems like magic -- clearly works. You've made the machine do something. Just to make sure, you type something else in, click the button, and there it is. That's what inspired me to become a programmer. The ones and zeros came later.

[1] http://www.webmonkey.com/2010/02/php_tutorial_for_beginners/ (I don't recommend this tutorial to anyone learning to program. It was useful when it was written, but it's not up to date, and some of the examples are broken. In 2011, there are lots of good beginner books.)

The average color of the Seattle sky, updated every 5 minutes: #DDDDDD

Is there a vim theme for that?

> I think he has a good point, and as someone who really likes functional languages, I agree with him, but I think there really needs to be a better explanation of functional "patterns" and how to structure large functional programs before it will catch on more.

Are there any good existing resources for learning these things?