Slashdot Mirror

An anonymous reader writes "I was asked to manage a number of Linux servers at work. I would like to use volume snapshots to improve my backup scripts and keep recent copies of data around for quick restore. I normally manage Windows servers and on those I would just use Microsoft's Volume Shadow Copy for this. I tried Linux LVM snapshots, but most of the servers I manage run regular partitions with ext3 file systems, so LVM snapshots will not work. I found some versioning file systems out there like ext3cow and Tux3. Those look interesting, but I need something I can use on my existing ext3 file systems. I also found the R1Soft Hot Copy command-line utility, but it does not yet support my older 2.4 Linux servers. What are you using to make snapshots on Linux?"

An anonymous reader writes "I was asked to manage a number of Linux servers at work. I would like to use volume snapshots to improve my backup scripts and keep recent copies of data around for quick restore. I normally manage Windows servers and on those I would just use Microsoft's Volume Shadow Copy for this. I tried Linux LVM snapshots, but most of the servers I manage run regular partitions with ext3 file systems, so LVM snapshots will not work. I found some versioning file systems out there like ext3cow and Tux3. Those look interesting, but I need something I can use on my existing ext3 file systems. I also found the R1Soft Hot Copy command-line utility, but it does not yet support my older 2.4 Linux servers. What are you using to make snapshots on Linux?"

KentuckyFC writes "The critical concept that makes a black hole black is the event horizon: a theoretical boundary in space through which light and other objects can pass in one direction but not the other. Since light cannot escape the event horizon, it must be black. The event horizon is a nuisance to astrophysicists because it hides the interesting new physics that must go on inside a black hole. What they would like is a way to get rid of the event horizon so that they can see what goes on behind it. It turns out that just such a thing may be possible, say physicists. According to the mathematics of general relativity, the event horizon should disappear if a black hole were fed enough charge and angular momentum relative to its mass. However the calculations are so fiendish (PDF) that nobody knows whether the black hole would shed this extra angular momentum and charge before it could settle into a stable 'naked' state. However, the possibility that the event horizon could be destroyed raises the question of what astrophysicists would see behind this veil. According to some, black holes are regions of spacetime with infinite curvature called singularities. Many believe that 'naked' singularities cannot exist in nature. And yet there are enough question marks to suggest that this mystery is far from settled."

eldavojohn writes "South Korea suffered its second straight setback today as its Naro-1 rocket carrying a scientific satellite exploded. The rocket produced a bright flash during stage-one ignition as the ground crews lost contact with it. South Korea paired with Russia to produce the Naro-1 and was looking to both relieve its dependence on other nations to put its satellites in orbit and compete with the space programs of China, India, and Japan. Following a failure on August 25, 2009, this marks the second failed attempt for Naro Space Center to launch a Naro-1 rocket. It appears the old adage revolving around the complexities of 'rocket science' remains valid."

kthreadd writes "The LLVM project is now working on a debugger called LLDB that's already faster than GDB and could be a possible alternative in the future for C, C++, and Objective-C developers. With the ongoing success of Clang and other LLVM subprojects, are the days of GNU as the mainstream free and open development toolchain passé?" LLVM stands for Low Level Virtual Machine; Wikipedia as usual has a good explanation of the parent project.

leathered writes "Tinfoil hatters around the world are abuzz that UVB-76, the Russian shortwave radio station that has been broadcasting its monotonous tone almost uninterrupted since 1982, has suddenly gone offline. Of course no one knows what the significance of this is, but best brush up on your drills just in case."

Gooseygoose writes with a link to this analysis by Boston University professor Cutler Cleveland. "Some reports in the media attempt to downplay the significance of the release of oil from the Deepwater Horizon accident by arguing that natural oil seeps release large volumes of oil to the ocean, so why worry? Let's look at the numbers." Read on for a few more stories on the topic of the Deepwater Horizon spill. theodp writes with some information on the remote-controlled efforts to stanch the oil's flow: "The work Tito Collasius does sounds a little like science fiction: Men on ships flicking joysticks that control robots the size of trucks as they rove miles beneath the sea in near-freezing depths no man could hope to reach. But BP's spill efforts rest in the hands of underwater remote-operated vehicle (ROV) pilots, who 'fly' the ROVs from command centers aboard ships, joysticks in hand and large banks of screens in front of them offering a view of the challenges they confront in the waters below. ROVs are typically used for commercial (as in the oil industry), oceanographic (science research and exploration), and military (mine reconnaissance and recovery) missions. If you're interested in joining Tito, training's available." Even if BP were to effect a perfect block for the oil, though, there's still quite a bit of it swirling in the Gulf — you've probably seen some gut-wrenching pictures of the affected wildlife. Reader grrlscientist writes "Some people claim that we should euthanize all oiled birds immediately upon recovering them. But I argue it is our ethical responsibility to protect, clean, and save these birds, even after they've been oiled, just as we should preserve and clean their habitats."

Roblimo writes "Zappa's 'Dinah-Moe Hummm' is totally about Linux, at least in spirit, while the song 'Montana,' with its talk of zirconium-encrusted tweezers and dental floss, 'is obviously about Mac users.' Not only that: In the early '70s Zappa wrote a song called 'Penguin in Bondage,' an obvious foretelling of the anti-Linux lawsuits and threats from SCO, Microsoft, and other evildoers. Zappa was also a heavy user of the Synclavier, an electronic music machine that was a precursor to today's 'studio on a computer' recording and sound editing software. According to an article on DevX, today Zappa would no doubt be using Linux and Ardour for most of his recording and composition."

An anonymous reader writes "The recently published Top 500 list of the world's fastest supercomputers is based on the Linpack benchmark developed decades ago by Jack Dongarra. This same test has been ported to Android mobile phones, which means that we can compare the performance of our phones against that of the supercomputers of the past. For example, a tweaked Motorola Droid can hit 52 Mflop/s, which is more than 15 times faster than the CPUs used in the 1979 Cray-1." But even today's most powerful cellphones don't come with an integrated bench.

theodp writes "Slate's Ben Paynter looks into why Indian kids dominate the Scripps National Spelling Bee, and concludes it's because they have their own minor-league spelling bee circuit (having the discipline to spell 7,000 to 8,000 words a day probably helps too!). Indian-Americans make up about 1% of the US population, notes Paynter, but this year an estimated 11% of the competitors at Scripps will hail from regional contests run by the North South Foundation. The NSF competitions function as a kind of nerd Olympiad for Indian-Americans — there are separate divisions for math, science, vocabulary, geography, essay writing, and even public speaking — and a way to raise money for college scholarships for underprivileged students in India. BTW, Strollerderby has the scoop on Whatever Happened to the Spellbound Kids? (RIP, Ted Brigham)."

rbook writes "Remember :CueCat, the "free" (as in beer) bar code scanner that was supposed to change everything by allowing advertisers (or whoever) to put hyperlinks in printed material? Well, the idea is back, according to the Chronicle of Higher Education: 'People who prefer print books over e-books may still want extra digital material to go with them. That's the idea behind Sorin Matei's project, Ubimark, which embeds books with two-dimensional codes that work as hyperlinks when photographed.' Photographing an image and uploading it sounds like more trouble than scanning a bar code to follow a URL, but they figure you can take the photograph with your smartphone and view the web page automatically on the mobile device." It looks like standard QR codes are embedded; what Ubimark is pushing is "a publishing environment which combines print books, ubilinks, a centralized Internet based interactive information repository and computer displays."

Pickens writes "USNWR is reporting that the needle pricks involved in acupuncture may help relieve pain by triggering the natural painkilling chemical adenosine. There are also indications that acupuncture's effectiveness can be enhanced by coupling the process with a well-known cancer drug — deoxycoformycin — that maintains adenosine levels longer than usual. Dr. Maiken Nedergaard of the University of Rochester Medical Center and her colleagues administered half-hour acupuncture treatments to a group of mice with paw discomfort. The investigators found adenosine levels in tissue near the needle insertion points was 24 times greater after treatment, and those mice with normal adenosine function experienced a two-thirds drop in paw pain. By contrast, mice that were genetically engineered to have no adenosine function gained no benefit from the treatment." Read below for some acupuncture skepticism engendered by other recent studies.
However, many remain skeptical of acupuncture claims. Ed Tong writes in Discover Magazine that previous clinical trials have used sophisticated methods to measure the benefits of acupuncture, including 'sham needles' (where the needle's point retracts back into the shaft like the blade of a movie knife) to determine if the benefits of acupuncture are really only due to the placebo effect. 'Last year, one such trial (which was widely misreported) found that acupuncture does help to relieve chronic back pain and outperformed "usual care". However, it didn't matter whether the needles actually pierce the skin [paper here with annoying interstitial], because sham needles were just as effective,' writes Tong. 'Nor did it matter where the needles were placed, contrary to what acupuncturists would have us believe.'"

Hugh Pickens writes "'Sticky,' in the social sciences and particularly economics, describes a situation in which a variable is resistant to change. For websites or products it usually means that visitors or customers keep coming back for more. Now Fortune Magazine reports on an analysis by Deutsche Bank's Chris Whitmore on what makes the (iTunes-based) iPhone-iPod-iPad platform so sticky and why it's going to get harder, not easier, for Apple users to switch, no matter what Google and the rest of Apple's competitors have up their sleeves. Whitmore says the investment Apple's customers have made in content for those devices in terms of apps, videos, and music purchased at the iTunes Store creates Apple's 'stickiness.' Apple has an installed base today of about 150 million iTunes-dependent devices that could grow to more than 200 million by the end of 2011. Whitmore comes up with a cumulative investment in those devices of about $15 billion today, growing to $25 billion by the end of next year. 'This averages to ~$100 of content for each installed device,' Whitmore writes, 'suggesting switching costs are relatively high (not to mention the time required to port). When Apple's best-in-class user experience is combined with these growing switching costs, the resulting customer loyalty is unparalleled.'"

astroengine writes "The flying telescope SOFIA took its maiden flight on Wednesday, and its 'first light' images have already been released. The cool thing about SOFIA is that it flies high enough (integrated inside a converted 747, taking it to an altitude of 41,000 ft) to carry it above 99% of the atmosphere's infrared-absorbing water vapor. This means it can collect 80% of the IR radiation that hits orbital telescopes (like NASA's Spitzer) but without the huge cost of being launched into space. Also, SOFIA is expected to last 20 years, many times the operational lifespan of space missions. Already, SOFIA has returned stunning results, including the observation of heat leaking through Jupiter's clouds, heat that was generated billions of years ago when the gas giant was forming."

TrisexualPuppy writes "A team of scientists at Boston University has created a cure for the Ebola virus, first discovered in 1976. After setting the correct dosages, all monkeys tested with the vaccine survived with only mild effects. No tests have been performed on humans yet, as outbreaks happen infrequently and are difficult to track. Quoting NPR: '[The drug] contains snippets of RNA derived from three of the virus's seven genes. That "payload" is packaged in protective packets of nucleic acid and fat molecules. These little stealth missiles attach to the Ebola virus's replication machinery, "silencing" the genes from which they were derived. That prevents the virus from making more viruses.'"

krou writes "Under plans drawn up by Ofcom, UK ISPs are going to draw up a list of those who infringe copyright, logging names and the number of times infringement took place. Music and film companies will then be allowed access to the list, and be able to decide whether or not to take legal action. '"It is imperative that a system that accuses people of illegal online activity is fair and clear," said Anna Bradley, chair of the Communications Consumer Panel.' The Panel, in partnership with Consumer Focus, Which, Citizens Advice, and the advocacy body the Open Rights Group, has released a set of principles it believes should govern the code of practice. The principles say sound evidence is needed before any action is taken, consumers must have the right to defend themselves, and the appeals process must be free to pursue. The code shall come into practice by 2011, and initially applies only to ISPs with 400,000 customers or more." Update: 05/29 09:11 GMT by T : As an anonymous reader points out below, that's 400,000 users, rather than 40,000 as originally rendered.

Xistic writes with news that the XB in XBMC won't mean Xbox any more. Quoting the project's own website: "The last official release for the XBOX by the XBMC team was Atlantis, over 18 months ago. Since then, one brave soul (Arnova) has been merging code from the main codebase into the XBOX branch in our repository. Because there were many users out there that took advantage of these updates, we had no problem with this. But times have changed. The XBOX has hard limits for what it can handle. Some users are satisfied with these limits, and we encourage them to use XBMC there if they are happy. But it is a popular misconception that official XBOX development is still taking place by the team, so we have decided to set it free. We have enough on our plates already, and worrying about a deprecated platform just increases our workload. A few days ago the XBOX branch was finally removed from our subversion repository."

NewYorkCountryLawyer writes "Several years ago a federal court in Texas ordered the RIAA, in an 'innocent infringement' case against a teenager, to either accept $200 per infringed work, or to go to trial over the innocent infringement issue, in Maverick Recording Co v. Harper. Recently, an appeals court reversed, saying that the defendant could not avail herself of the innocent infringement defense since there were CDs, bearing copyright notices, available in stores, even though the copies she had made were from MP3 files which bore no such notice. Now, a petition for certiorari has been filed on the defendant's behalf, arguing that the 5th Circuit's ruling would make it impossible for anyone to interpose an innocent infringement case, even where they had never seen a copyright notice. The lawyers filing the petition on defendant's behalf are the same firm that represented Jammie Thomas in her second trial, and the motion which resulted in her verdict being reduced from $1.92 million to $54,000."

An anonymous reader writes "We all know that flash and other types of solid state storage can only endure a limited number of write cycles. The open source Flash Destroyer prototype explores that limit by writing and verifying a solid state storage chip until it dies. The total write-verify cycle count is shown on a display — watch a live video feed and guess when the first chip will die. This project was inspired by the inevitable comments about flash longevity on every Slashdot SSD story. Design files and source are available at Google Code."

jamienk writes "Imagine if you could grab and manipulate audio with JavaScript just like you can images with Canvas. Firefox experimental builds let you do just that: crazy audio visualizations, a graphic equalizer, even text-to-speech, all in JavaScript! Work in progress; you need a special build of Firefox (videos available), being worked on via W3C."

johnmccollum writes "A wealth of tools are available to debug and test Django applications, but knowing when and how to use these resources can intimidate the new user. Django 1.1 Testing and Debugging, by Karen M. Tracey, aims to walk the user through the process of creating a web application from scratch, ensuring that the resulting code is bug-free and ready for production." Keep reading for the rest of John's review. Django 1.1 Testing and Debugging author Karen M. Tracey pages 409 publisher Packt Publishing rating 9/10 reviewer John McCollum ISBN 978-1-847197-56-6 summary Building rigorously tested and bug-free Django applications In a way, Django makes it deceptively easy to write a dynamic web application. With a few lines of code, you can have an fully functional application up and running in a short space of time, and complex applications take less time than ever to develop. Inevitably, though, bugs will creep in to the development process, and the professional developer will want to make sure that their application is as bug-free as possible before launching.

The book opens with a simple question: "How do you know when code you have written is working as intended?" The answer, of course, is that you test it. But if you're not a cowboy coder, you'll want to leverage the full power of Django's automated testing framework for best results. In the course of this book, the author develops a full web application, from start to finish, and describes how each section would be tested and debugged.

The author's intended audience for this book is perhaps one that is relatively new to Django. Ideally, the reader will have a functioning installation of Django, will have worked through at least the tutorial, and may well have written a couple of applications. This book would also be excellent for someone migrating to Python from another language, or moving into MVC frameworks for the first time. Crucially, the book doesn't just explain how to test, it also explains when and what to test too, so it serves as an ideal introduction into testing in general. There are many code examples and screenshots, and each line of code is fully explained.

The book kicks off with an examination of doctests and unit tests. Their relative pros and cons are explained in some depth, and the author does a great job in this section of discussing exactly what you should be testing, initially beginning with data models. She then moves on to more advanced unit testing strategies and applications, such as testing views and customizations of the admin area.

One of Python's greatest strengths is its ecosystem, and the following chapters cover some of the other tools you might want to integrate into your project. Django-coverage provides reporting on how much of your code is covered by tests, and Twill is a package that essentially replaces Django's test client to provide enhanced functionality — particularly for working with forms. Both packages have fully explained and in-depth examples to work through. (Code downloads are available at Packt Publishing's web site for the terminally lazy!)

With the testing section of the book complete, the author moves on to the debugging section of the book. Starting with the very basics (setting up Django in debug mode), the book then takes a detailed look at the Django debug page. This is something that I could see being useful for many new users — the debug page contains a wealth of information (and not all of it is always entirely relevant, if not outright misleading), so learning to understand this page is crucial to your success as a Djangonaut.

The book then takes a tour of the excellent django-debug-toolbar, before moving on to what was, for me, the most valuable chapter of the book: "When you don't know even know what to log: Using Debuggers." This chapter introduces the PDB (Python Debugger) library.

Like many others, I suppose, Django was my first introduction to Python. For that reason, my knowledge of the standard library is perhaps not as strong as it could be. For me, learning about the different ways of using the debugger was the highlight of the book, and something that will probably change the way I develop with Django.

The book concludes, of course, by taking the application into a production environment. And in line with the latest advice, that means setting up the site using Apache and mod_wsgi. In keeping with the theme of the book, the most common issues in deployment are identified and resolved.

This book weighs in at over four hundred pages, and its greatest strength is its wide scope. Although the basics of testing in Django are easy to understand, it's another thing entirely to see an entire application built from the ground up with testing at the forefront. As I mentioned before, the focus is as much on developing a testing and debugging strategy as it is on the technical aspects.

From a more technical point of view, the subject matter ranges from beginner to advanced. From writing the most basic doctests to debugging multi-process race conditions, the difficulty level increases incrementally, and no important details are skirted over. The prose is well-written and easy to read throughout.

If I had one gripe about the book, it would be that in places, it goes into a little too much detail. There's a section on using the Django web site (the bug tracker, the mailing list etc.) that I could have done without entirely. Although it might be useful for some users, the site is pretty self-explanatory and doesn't really warrant the attention it gets, in my opinion.

You shouldn't let that put you off though — this really is an excellent exploration of the topic. In addition, Packt Publishing will make a donation to the Django project for every book sold, so in purchasing this book, you'll be indirectly helping the project financially too.

This book is worth a place on any Django developer's bookshelf.

You can purchase Django 1.1 Testing and Debugging from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Hugh Pickens writes "Science Daily Headlines reports on research by Oregon State University marine geologist Chris Goldfinger showing that earthquakes of magnitude 8.2 (or higher) have occurred 41 times during the past 10,000 years in the Pacific Northwest. By extrapolation, there is a 37% chance of another major earthquake in the area in the next 50 years that could exceed the power of recent seismic events in Chile and Haiti. If a magnitude-9 quake does strike the Cascadia Subduction Zone, extending from northern Vancouver Island to northern California, the ground could shake for several minutes, highways could be torn to pieces, bridges might collapse, and buildings would be damaged or even crumble. If the epicenter is just offshore, coastal residents could have as little as 15 minutes of warning before a tsunami could strike. 'It is not a question of if a major earthquake will strike,' says Goldfinger, 'it is a matter of when. And the "when" is looking like it may not be that far in the future.'" Read below for more.
The last major earthquake to hit the Cascadia Subduction Zone was in January 1700. Scientists are aware of the impact because of written records from Japan documenting the damage caused by the ensuing tsunami, which crested across the Pacific at about 5 meters (15 feet). Knowledge about what happened in Oregon and Washington is more speculative, but the consensus — gleaned from studies of coastal estuaries, land formations, and river channels — is that the physical alteration to the coast was stunning. The outer coastal regions subsided and drowned coastal marshlands and forests, which were subsequently covered with younger sediments. "Perhaps more striking than the probability numbers is that we ... have already gone longer without an earthquake than 75% of the known times between earthquakes in the last 10,000 years," says Goldfinger. "And 50 years from now, that number will rise to 85 percent."

An anonymous reader writes "A study presented last week at the IEEE Web Security and Privacy workshop shows that frame busting code used at popular websites is easily circumvented. Frame busting is a widely used technique to prevent clickjacking attacks. The researchers propose better frame busting code and suggest that websites migrate to this new code."

An anonymous reader writes "A study presented last week at the IEEE Web Security and Privacy workshop shows that frame busting code used at popular websites is easily circumvented. Frame busting is a widely used technique to prevent clickjacking attacks. The researchers propose better frame busting code and suggest that websites migrate to this new code."

scamdetect pointed us to an interesting bit of news about a new security risk called tabnapping that was recently outlined by Aza Raskin. The short story is that background tabs are updated with login forms impersonating the sites they originally contained, but hosted by helpful third parties primarily interested in your password. (CT:Original writeup removed at request of submitter)

neogramps writes "It's been a long time coming, but the first Pandora consoles are finally rolling off of the production line. (Well, this one actually walked out the door to a customer who lived near the 'factory.') Initial estimates had put production and development at taking two months, but Murphy had other ideas. Banking issues, design problems, problems communicating with the Chinese moulding company, escalating assembly costs, and even a volcano all managed to get in the way, but the small and dedicated team soldiered on, and just over a year and a half later, the wait is coming to an end for the 4,000 pre-orderers."

From James Randi's blog comes word that science writer Martin Gardner has died at the age of 95. I never met Gardner, but one of his books (Entertaining Science Experiments With Everyday Objects) has been a favorite of mine since I was 6 or 7 years old; I didn't realize until just now quite how many books he authored.

eldavojohn writes "People in mainland Louisiana are seeing the beginnings of the oil's full effects on wildlife in the area. Sticky, rust-colored oil covers the reeds like a latex paint, indicating that the efforts to lay miles of floating booms to keep it away from the fragile marshes are useless. They are experiencing what the Plaquemines (mouth of Mississippi River) saw last week, and it now appears that their defenses were inadequate. Only time will tell how much worse it can get as BP still scrambles for a solution. NPR also ran a story critical of Obama's 'scientific approach' that he promised to use in office and how well it's being applied and holding up during this crisis."

siliconbits writes "Some say that the Windows 3.0 GUI (remember, it needed MS-DOS or DR-DOS to work) was the single most important version, as it allowed Microsoft to get its day. The first truly successful Windows operating system is 20 years old today; Windows 3.0 was launched on 22 May 1990 and was the successor to Windows 2.1x."

Hugh Pickens writes "Alan D. Mutter writes on his 'Reflections of a Newsosaur' blog that the economics of local broadcasting may begin to unravel as dramatically in the next five years as they did for newspapers in the last five years, due to the unparalleled consumer choice made possible by a growing mass of (mostly free) content on the Internet. 'Once it becomes as easy and satisfying to view a YouTube video on your 50-inch television as it is to watch "Two and a Half Men," audiences will fragment to the point that local broadcasters will not be able to attract large quantities of viewers for a particular program,' writes Mutter. The economics of cable TV programming already are geared to serving small but targeted niches, but as audiences shatter, those options won't be available to local broadcasters, who will be deprived of the vast reach that enabled the high ad rates and enviable profits long associated with their businesses. Although barely 8% of US households had access to IPTV in 2009, this technology is likely to be available to some 20% of the more than 100 million homes subscribing to pay-television services in 2014, according to senior analyst Lee Ratliff of iSuppli, a private market research company. 'We already have gotten a hint of what the future could hold. Acting to trim spending during the recession, many local stations cut back their news staffs, resulting in a decline in the caliber and depth of their coverage,' writes Mutter."

Pax681 writes "[London Mayor] Boris Johnson declared that London will have all bus stops and lamp posts Wi-Fi enabled by 2012 for the Olympics. In an article on Tech Eye, Boris waxes lyrical (or as lyrical as he can get) about how it would be done at a Google Zeitgeist event in Hertfordshire. These would be public Wi-Fi hotpots; as such, would these break the new law on open access points? Would they be just the thing for people to use to infringe with impunity and anonymously bypass the chances of running foul of the Digital Economy Act?"

Dr. Eggman writes "Physorg.com brings us news of a synthetic genome, produced by the J. Craig Venter Institute, being used in an existing bacterial cell for the first time. Using a combination of biological hosts, the technique produces short strings of DNA by machine which are then inserted into yeast to be stitched together via DNA-repair enzymes. The medium sequences are passed into E. coli and back into yeast. After three rounds, a genome of three million base pairs was produced." (More below.) "Specifically, the genome of M. mycoides was synthesized from scratch. This synthetic genome was then inserted into the cells of a bacteria known as Mycoplasm capricolum. The result is a cell, driven by a synthetic genome, producing not the proteins of Mycoplasm capricolum, but of M. mycoides. The institute has far-reaching plans for its synthetic life program, including designing algae that can capture carbon dioxide, make new hydrocarbons for refineries, make new chemicals or food ingredients, and speed up vaccine production." The BBC has coverage of the hybrid cell as well.

An anonymous reader writes "Someone got permission to sniff the wireless traffic during an MIT class. The professor: none other than Robert Morris, creator of the first Internet worm! The lecture: computer security! I love it."

An anonymous reader writes "Someone got permission to sniff the wireless traffic during an MIT class. The professor: none other than Robert Morris, creator of the first Internet worm! The lecture: computer security! I love it."

Hugh Pickens writes "The New York Times reports that President Obama's plans for reducing America's nuclear arsenal and defeating Iran's missiles rely heavily on a new generation of antimissile defenses which last year he called 'proven and effective.' Now a new analysis being published by two antimissile critics at MIT and Cornell casts doubt on the reliability of the SM-3 rocket-powered interceptor. The Pentagon asserts that the SM-3, or Standard Missile 3, had intercepted 84 percent of incoming targets in tests. But a re-examination of results from 10 of those apparently successful tests by Theodore A. Postol and George N. Lewis finds only one or two successful intercepts, for a success rate of 10 to 20 percent. Most of the approaching warheads, they say, would have been knocked off course but not destroyed, and while that might work against a conventionally armed missile, it suggests that a nuclear warhead might still detonate. 'The system is highly fragile and brittle and will intercept warheads only by accident, if ever,' says Dr. Postol, a former Pentagon science adviser who forcefully criticized the performance of the Patriot antimissile system in the 1991 Persian Gulf war. Dr. Postol says the SM-3 interceptor must shatter the warhead directly, and public statements of the Pentagon agency seem to suggest that it agrees. In combat, the scientists added, 'the warhead would have not been destroyed, but would have continued toward the target.'"

xt writes "The Boltzmann equation is old news. What's news is that the 140-year-old equation has been solved, using mathematical techniques from the fields of partial differential equations and harmonic analysis, some as new as five years old. This solution provides a new understanding of the effects due to grazing collisions, when neighboring molecules just glance off one another rather than collide head on. We may not understand the theory, but we'll sure love the applications!"

KentuckyFC writes "Any proof that quantum cryptography is perfect relies on idealized assumptions that don't always hold true in the real world. One such assumption is related to the types of errors that creep into quantum messages. Alice and Bob always keep a careful eye on the level of errors in their messages because they know that Eve will introduce errors if she intercepts and reads any of the quantum bits in a message. So a high error rate is a sign that the message is being overheard. But it is impossible to get rid of errors entirely, so Alice and Bob have to tolerate a small level of error. This level is well known. Various proofs show that if the quantum bit error rate is less than 20 percent, then the message is secure. However, these proofs assume that the errors are the result of noise from the environment. Now, physicists have come up with an attack based on the realization that Alice also introduces errors when she prepares the required quantum states to send to Bob. This extra noise allows Eve to intercept some of the quantum bits, read them and then send them on, in a way that raises the error rate to only 19.7 percent. In this kind of 'intercept and resend attack,' the error rate stays below the 20 percent threshold and Alice and Bob are none the wiser, happily exchanging keys while Eve listens in unchallenged. The physicists say they have successfully used their hack on a commercial quantum cryptography system from the Geneva-based startup ID Quantique."

Halo1 writes "Demonstrating it's not just about Flash, Apple has officially rejected for the first time another alternative iPhone development environment following its controversial iPhone SDK Agreement changes. Even though RunRev proposed to retool its HyperCard-style development environment to directly expose all of the iPhone OS's APIs, Steve Jobs still rejected its proposal. The strength of RunRev's business case, with a large-scale iPad deployment project in education hinging on the availability of its tool, does not bode well for projects that have less commercial clout. Salient point: at last February's shareholders' meeting, Jobs went on the record saying that something like HyperCard on the iPad would be great, 'but someone would have to create it.'"

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

tyen writes "Any suggestions for a 'developer-friendly' bank for small businesses? The banking world is awash in data protocols that business customers who are/have coders would find useful, like BAI to extract all the raw data from an ACH or SWIFT transfer. Unfortunately, the ones I have spoken with about this access are still stuck in the Dark Ages of computing; they price the access like only big companies still have the skills to tap into these interfaces. For example, one of the four US banks with a perfect trading record this past quarter quoted us USD five figures for access to several of our accounts via BAI format. Per year. After waiving sign-up fees. Are there any banks out there that have a more progressive attitude about letting small, entrepreneurial developers work with their business accounts in a more modern, dare we say automated, way? With big businesses demanding EFT integration from small business vendors, and globalization rewarding premiums to nimble, lean businesses that automate wherever possible, automating the retrieval of this information (which is not available in consumer-oriented access like OFX) becomes an increasingly pressing issue for the small guys."

tyen writes "Any suggestions for a 'developer-friendly' bank for small businesses? The banking world is awash in data protocols that business customers who are/have coders would find useful, like BAI to extract all the raw data from an ACH or SWIFT transfer. Unfortunately, the ones I have spoken with about this access are still stuck in the Dark Ages of computing; they price the access like only big companies still have the skills to tap into these interfaces. For example, one of the four US banks with a perfect trading record this past quarter quoted us USD five figures for access to several of our accounts via BAI format. Per year. After waiving sign-up fees. Are there any banks out there that have a more progressive attitude about letting small, entrepreneurial developers work with their business accounts in a more modern, dare we say automated, way? With big businesses demanding EFT integration from small business vendors, and globalization rewarding premiums to nimble, lean businesses that automate wherever possible, automating the retrieval of this information (which is not available in consumer-oriented access like OFX) becomes an increasingly pressing issue for the small guys."

tyen writes "Any suggestions for a 'developer-friendly' bank for small businesses? The banking world is awash in data protocols that business customers who are/have coders would find useful, like BAI to extract all the raw data from an ACH or SWIFT transfer. Unfortunately, the ones I have spoken with about this access are still stuck in the Dark Ages of computing; they price the access like only big companies still have the skills to tap into these interfaces. For example, one of the four US banks with a perfect trading record this past quarter quoted us USD five figures for access to several of our accounts via BAI format. Per year. After waiving sign-up fees. Are there any banks out there that have a more progressive attitude about letting small, entrepreneurial developers work with their business accounts in a more modern, dare we say automated, way? With big businesses demanding EFT integration from small business vendors, and globalization rewarding premiums to nimble, lean businesses that automate wherever possible, automating the retrieval of this information (which is not available in consumer-oriented access like OFX) becomes an increasingly pressing issue for the small guys."

theodp writes "Holy Logan's Run, Batman! Google on Friday began giving students priority access to its Google Voice service, which has remained in a closed beta since its transition from GrandCentral in March of last year. Typically, invites for the service can take anywhere from a few hours to several months to arrive after a user signs up. But Google is now promising students who cough up an .edu e-mail address access to the service within 24 hours. Good thing CMU closes e-mail accounts after graduation, or old fuddy-duddy alums like Brian Reid might try to sneak in!"

analysethis writes "In the UK last month the author/compiler of the well-known-in-Internet-circles 'terrorist handbook' pleaded guilty to seven counts of collecting information that could have been used to prepare or commit acts of terrorism, with a maximum jail term of 10 years. Today the first people caught with downloaded copies have been put behind bars — a white-supremacist father and son pairing getting 10 and two years respectively, convicted of three counts of possessing material useful for acts of terror. How many will be emptying their recycle bins after this conviction? As of writing, the book is still freely available on Amazon.com to buy." Note: it seems that there's some overlapping nomenclature at play. Terrance Brown, the man who pleaded guilty to terror charges last month, is said to have been distributing a CD set including among other things extracts from Al-Qaeda manuals. His "cookbook" differs then from William Powell's 1971 book by a similar title, though (confusingly enough) the linked Wikipedia article implies that the father-and-son pair arrested possessed a copy of the Powell book as well; its text may well have been among the materials that Brown distributed.

Amigan writes "Over on Groklaw, PJ is reporting that an actual demonstration of the Amiga OS (circa 1988) on an Amiga A1000 may have been the turning point in the lawsuit of IP Innovation v. Red Hat/Novell."

An anonymous reader writes "Here's a listing of several scientific and economic guides for estimating the volume of flow of the leak in the Gulf of Mexico erupting at a rate of somewhere around 1 million barrels per day. A new video released shows the largest hole spewing oil and natural gas from an aperture 5 feet in diameter at a rate of approximately 4 barrels per second. The oil coming up through 5,000 feet of pressurized salt water acts like a fractionating column. What you see on the surface is just around 20% of what is actually underneath the approximate 9,000 square miles of slick on the surface. The natural gas doesn't bubble to the top but gets suspended in the water, depleting the oxygen from the water. BP would not have been celebrating with execs on the rig just prior to the explosion if it had not been capable producing at least 500,000 barrels per day — under control. If the rock gave way due to the out-of-control gushing (or due to a nuke being detonated to contain the leak), it could become a Yellowstone Caldera type event, except from below a mile of sea, with a 1/4-mile opening, with up to 150,000 psi of oil and natural gas behind it, from a reserve nearly as large as the Gulf of Mexico containing trillions of barrels of oil. That would be an Earth extinction event."