rosejn's comments

...or why types and the lack of anonymous functions combine to make a language painful, ugly, and annoying.

Apple Corp. sucks as a member of society. As one of the wealthiest and most successful companies on earth they continue to play dirty by abusing the patent system for their advantage. Most of the patents they are "protecting" are describing pretty obvious ideas that any group of good engineers working on this class of devices would bump into, and this behavior does not benefit society in any way. They are clearly protecting a virtual monopoly on tablets by fighting with patents rather than focusing on out innovating the competition. I hope their will one day be real competition in this space.

Great concept. This is kind of similar to an editor we've been talking about for Overtone. How about,

* allow for render plugin functions so values can be rendered with images, rendered canvases, control elements, etc.

* treat the AST as the primary data for each function or form, and then make the source code one of multiple renderings of the data.

- makes paredit type manipulations just operations on the ast

- allow for decorating the ast with additional data, which can be rendered with plugins (for example, heat-up regions of code as a profiler runs)

You're right, and in Overtone we haven't really tried to mirror SCLang at all. The DSP core of scsynth is a great piece of software with many years of testing, debugging, and extension, so it's wonderful that we can leverage this externally by just sending OSC. Of course we want to pull in any good ideas we find from the sc class library or any other music system, but generally we have been working on creating an expressive synthesis language that clearly communicates what is being produced. In SCLang there are many syntactic tricks and shortcuts which allow you to create very terse definitions, but they are often to the detriment of readability. With Clojure's lazy sequences we can easily model many interesting types of generative musical structures, and with easy access to the JVM ecosystem of libraries we can now control our musical processes with external tools or devices, visualize them with nice graphics, auralize external phenomena (e.g. people have hooked into automated build/test systems), etc., far easier than in SClang.

Actually, one of the initial motivations for creating Overtone was to experiment with automating "feel". I was getting into electronic music, and it seemed to me that many of the painful aspects of EQing and adjusting instruments and timing so they don't interfere with each other could be automated. We haven't really gotten to this point yet, but I tend to believe that this is yet another area in life where people will argue forever that software will never compete with humans, up until the point where many of the top tracks are being generated by software. It also opens the door to all kinds of interesting things, like live composition of multiple instruments, or meta-composing, where you modify parameters along axis like tension, emotion, drive, and vibe, rather than figuring out how to modulate to the next key. For now I agree with you though, most of what I create in Overtone still has a robotic feel. Hopefully that won't be the case for long. We'd love to have more musicians joining the discussion though, so if you have ideas join the mailing list.

It's not necessarily that SC is complicated, but it is a custom language that has to be learned to use a single application. Also, many musical ideas and projects extend beyond what sclang can do, or you want to use external libs, etc. By using Clojure you get all of the power of sclang and more, because you also get lisp macros, while also getting access to the whole java ecosystem of libs. We've got a gui library for Overtone in the works, and it will be a good example of this in action.

He has to turn comments off on Daring Fireball or else he would be called out as an Apple fanboy/lobbyist after posts like this. Plenty of companies are willing to compete by creating better products rather than taking their competition to court. The iPhone is getting pushed aside by Android and they are playing dirty to stop it. Unless you can point to some novel technology that Apple should control because it was truly new and different, then Android should be able to compete. Just calling it "competitive" rather than offense and defense is a political tactic that tries to make Google look just as bad as the other guys, or conversely make Apple look just as good as the others. This is not a valid comparison. Combative patent lawsuits are not a requirement for successful businesses. There is a major difference between companies that choose to be litigious to stifle competition rather than focus on creating better products at a cheaper price. Buying a patent portfolio in order to stifle innovation rather than to enable you to create new or better products goes against the purpose of the patent system as it is described in the constitution:

"To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."

They should have pooled these billions to create a massive patent reform campaign. It probably would have been cheaper and more effective in the long run.

They did, and using the manual improved performance considerably.

You make good points, but there are a few factors you have to think about. First, the built-in AI has been designed by people with great knowledge of the game and its strategy. The fact that a totally generic AI system with zero knowledge of the game can learn on the fly and beat the hand-tuned AI is pretty impressive.

They were training online during gameplay, so each round started fresh with an untrained system.

I was about to fix it, but using jekyll that breaks the link...

yeah, I screwed up on the date...

I very much agree with the sentiment. LaTeX works well and it produces the best technical documents of anything I've seen, but the world could really use a modernized replacement. The syntax is a pain in the ass, the error messages are horrible, and it takes documentation to figure out how to do anything new. If it could be made more user friendly I think something like Tex would be used much more widely as well. (It works with version control, unlike word docs which are hell to manage in group collaboration.)

Seriously, why does anyone care what this Apple fanboy thinks?

Microcosm: E. coli and the New Science of Life - Carl Zimmer

* This was one of the best science books I've ever read. Zimmer uses e-coli as the primary actor a tour of genomics and history of the big breakthroughs in micro-biology. I'm a developer, but this book was a page turner that really opened my eyes to to how cells operate, perform logic-like functions, and communicate.

The Rational Optimist: How Prosperity Evolves - Matt Ridley

* Ridley's basic thesis is that specialization and trade are the primary means of the betterment of the human condition, and he has a lot of thought provoking ways of looking at the world that will forever change the way I think about technology and business. A wide ranging and enjoyable read

Routing traffic to wikileaks would have been a perfect demonstration of this new system. Instead they decided to show how much they respect freedom of speech.

And tptacek, yes we should speak about wikileaks when discussing Amazon, from now on. This isn't a fanboy site, this is a place to discuss the real ramifications of a company's actions.

I was pretty happy with my cybook before leaving it on an airplane. Don't go Kindle, unless you want to support them after dropping WikiLeaks, thus taking the freedom of the press and flushing it down the toilet.

Go for Clojure. It's a modernized common-lisp with access to the wealth of Java libraries. There are resources online, and you should be able to get up and running in a matter of minutes.

We had a blind classmate all through my undergraduate program in CS, and he was a very capable hacker. He lived inside emacs using emacspeak with a high speed synthesized reader voice, and you could often hear his terminal talking to him in the front row if you listened carefully during class.

Blind people develop good memories because they are constantly building detailed mental models of spaces they need to navigate, and I think this might give them a leg up programming because they are used to working with mental models rather than referring to maps, diagrams and documentation. Their are obvious drawbacks, but I think programming is probably a pretty good choice of profession for blind people.

I found it interesting that in the post he criticizes previous discussion of lock based concurrency, while not providing anything close to the level of analysis that he apparently requires of his fellow disputant.

'“Locks are not modular and do not compose, and the association between locks and data is established mostly by convention.” Again, no data, no qualifiers, no study, no rationale, no evidence of experience trying to develop such systems...'

It is well known that lock based concurrent libraries do not compose, and anyone writing articles about concurrency should not require an explanation of this central issue in the discussion[1]. Of course with millions of hours of developer investment in a centrally managed codebase like Solaris it is possible to achieve incredible parallelism with locks, but that isn't practical for the vast majority of modern software, which continues to use ever more external libraries.

Clojure's STM paired with immutable data structures are an especially well suited combination that are unlike most of the research systems presented in this area. Of course there are additional resources that will have to be managed, such as access to I/O, but I would argue that access to I/O is by far the easier problem to deal with in comparison to concurrent access to memory - primarily because I/O devices are typically accessed serially so you can just queue up requests.

[1]: Here's one explanation with a code example of why locks don't compose: http://www.drdobbs.com/article/printableArticle.jhtml;jsessi...

I've had more eye opening experiences programming in Clojure than in any language I learned before it. (C, C++, Java, Python, Ruby, common lisp) It provides a fairly unique set of tools that really let you boil programs down to their essence: persistent data structures, software transactional memory, and an amazing standard library for operating on maps, sets, and sequences. Instant access to Java libraries means it isn't just about academic beauty.

To each their own, but I highly suggest you take a weekend and experiment. You won't regret it.