crc

> 229A is close to worthless > This course included gems such as "if you don't know what a derivative is, that is fine".

It also included other gems like debugging models with learning curves, stochastic gradient descent, artificial data and ceiling analysis. I have not come across practical things like these in more mathematically oriented ML books that I have tried reading in the past.

Interestingly, your arrogance is in sharp contrast with the humility of the professor, where he admits in places that he went around using tools for a long time(like SVM) without fully understanding the mathematical details.

You should put an end to this mode of trying to figure out some kind of globally optimum sequence of learning. There is none. If somebody tells you otherwise, they are either lying or they have forgotten the countless hours/days/months/years they spent trying to hone their craft and in-retrospect they feel they could have avoided all this if only they knew some optimum way to learn. You are in a partially observable environment. The only way to learn is to explore a bit, consider what you now know, re-explore. rinse, repeat. Pick something, anything, that interests you and jump at it.

> I think for myself

Then you should think that there may be others who aren't really that concerned about being their own boss and financial freedom(strange as it might sound); others who love learning new perspectives. Other than saying that clojure may not be worth your time, you offer no insight. Thanks for making your preference clear, now can we get back to discussing the talk?

> I just think this point tends to be overlooked when talking about "social" websites, almost like it was not polite to point out where these businesses make their money.

I am not sure that this is overlooked. I think most people know it is as so obviously true that it doesn't need restating anymore.

Don't pride yourself too much on being "honest". It is far easier to go around always telling the truth than to apply discretion.

Egan looks interesting. Which is a good book to start reading Egan?

I was a little disappointed by the abstract nature of some of the later chapters. I bought the book the same week that I stumbled on his blog, but after having read the book, I had to go and deep dive into his blog archives and only then I could connect the dots. I would also recommend reading "Impro" in parallel.

> 2. ubiquitous laziness can lead to some really subtle bugs

After the recent compiler change to prevent accidental head retention of lazy sequences, I don't remember having faced any subtle issue with laziness. Can you give me an example of what bit you?

> So it reduces to, "For any given language some things are simple and others complex. For other languages what is simple and complex differ".

Though that might be the case, what doesn't change with languages is what users typically consider as simple problems. So "simple problems" are specific to user expectations, not language features. So I think the parent's point still stands.

Clojure was the first lisp that I could seriously get into. I have a java background and the familiarity of JVM was partly helpful when I was learning it. I guess for people who are new to both java and lisp, it may be bit harder.

The language changing fast wasn't a concern to me then, and I was putting lot of time to keeping up with the changes by lurking in the mailing list and irc. It was fascinating to watch language design happen in front of my eyes. I think newbies would do fine with clojure (particularly at its current relatively stable state). I guess it just takes a bit of an effort.

The fact that we could get design so wrong if we just rely on intuition surprises me everytime I re-learn it. The discussion on the cultural challenges and the things can go wrong with A/B testing were fascinating. This is wisdom from people that are battle scarred.

"Its kind of like about time". That is the point. This is just concurrency control, and looking at as time is just a different perspective. (Actually, it is more than concurrency control, since he also talks about aliasing, but anyway..)I find that perspective intriguing.

I am not worried that it will confuse people. Ideas and perspectives that don't have merit will lose out to more powerful and clearer ideas over time. Also, I have always had more clarity only after passing through a state of confusion.

An introduction to probability - Vol I (William Feller)

Introduction to dynamic systems - David Luenberger

I didn't know about the stale attribute for couchdb(mentioned in a comment in the article). I can see places where it will speed up things in our set up.

Also, Mongo DB is interesting and I have plans to evaluate it for our setup(batch reads and writes, no master-master replication requirement, but need master-slave replication, also need sharding rather desperately). Does anyone have any experience couchdb-lounge mentioned in the same comment?

Been there! :). Clojure was my first lisp and I was learning emacs along with it. Looking back, emacs was a really good investment. Also, the ability to develop and debug through remote swank connections is so useful. Slime(with paredit) and swank bring out the best of lisp development.

Some generic advice:

1. Read lots of clojure code. There is clojure-contrib which has lots of little libraries, read through them and see how things are done.

2. I will second the SICP suggestion, atleast the first few chapters. Bottom up programming, building layers of abstraction, is a natural way of doing things in the lisp world.

3. The REPL is your friend. Having a really good working environment is crucial to initial learning as well as later development. I would strongly recommend taking the time to set up one of the clojure working environments(Slime/VimClojure/Enclojure) as a first thing, if you have not already done so.

4. It takes a while, but it gets easier. Keep at it.

> Possibly that should be partition-all from seq-utils

As of June 20th, there is now an optional padding argument in clojure.core/partition.

On #clojure, Rich once mentioned that Jim Gray's "Transaction Processing.." influenced his design of clojure's STM. IIRC, he mentioned that the MVCC aspect of the STM and the commute operation were some of the ideas that he took from the book.

Another paper that gets repeatedly mentioned as being influential in Clojure's design is http://web.mac.com/ben_moseley/frp/paper-v1_01.pdf

Once you finish the above paper, you should also look at http://code.google.com/p/clojure-contrib/wiki/DatalogOvervie... for seeing one way of doing FRP in clojure.

The biggest advantage of CouchDB - compared with its competition - seems to be the ability to create views to query the schema less dataset. If I have to do this in mysql, then I will have to create and maintain seperate columns with indices; making sure that updates to the data gets propagated to these columns etc. Do any of the CouchDB alternatives provide a cleaner solution?