I confess that I knew very little about the terracotta soldiers until I read The Terracotta Army. They were just an impressive array of workmanship uncovered somewhere in China. I had gone to see a couple of them on display at the Melbourne Town Hall years ago. I was impressed, but admittedly a little more impressed that that's where The Beatles waved to swarming streets of screaming teenagers in an earlier time.
John Man brings them as much to life as is possible in a book. Alternating between the present and the past, in a style of writing that wouldn't be amiss in a historical movie, with frequent flash-backs. He seems to have a strong sense of both visual and haptic presence. Olfactory as well, as you scent the packed earth of the pits, and the fine clays brought to the terracotta factory. The photographic colour plates are stunning, and he took many photos that didn't make it into the book. And there were touching moments when he felt some of the objects themselves.
John Man doesn't just tell the reader what happened or what might have happened. He takes the reader through some interesting thought experiments, based on available manufacturing techniques of the times, materials, availability of workmen in sufficient numbers, and the intriguing manufacturing techniques of a modern maker of terracotta soldiers not far from the originals. The numbers and scenarios are of course estimates and probabilities. But following through his thinking processes makes it dead interesting.
He cites a few times the works of Joseph Needham which reminds me of another wonderful work of history Bomb, Book and Compass: Joseph Needham and the Great Secrets of China. by Simon Winchester which I heartily recommend.
I spent a month in China last October, and did only a brief tour of major attractions such as The Great Wall. John Man's works (and I'll be reading his The Great Wall: The Extraordinary Story of China's Wonder of the World when I can) turn tourist attractions into pilgrimages into the past, and also into the future as he describes some of the plans for further excavations and what archeologists might find.
As I was walking up the very steep inclines of The Great Wall, I wondered what it would have been like as a soldier back then. I'm looking forward to finding out.
Sunday, January 24, 2010
Tuesday, July 22, 2008
What Has Scala Got To Do With Being A Boiled Frog?
I'll take the analogy back to its analogue.
With limits approached on processor core speeds, multi-core processors have arisen to provide the additional performance that cannot be squeezed out of individual cores. That means that on my computer one application can be running in one core, and another in another core. If my computer has two cores, it seems that it is running those two applications twice as fast as it would have done if it had only one core.
That's true. And with each doubling of the number of cores in my computer's processor, it will be able to run more applications and all will seem well and good with Moore's Law -- from a computer user's perspective.
Computer users are not the potentially boiled frogs. It's computer programmers who will begin to feel those tiny bubbles swirling around their nether regions as they float around happily in a pot of soothing warm water with convective currents tickling their toes.
And guess what? All computer programmers are computer users. From a user perspective we see our computers getting faster. In that respect we are surprisingly good at seeing things from a user point of view. The irony is that in this case we should not be guiled by user experience. We have to think of ourselves for a change.
Our individual programs are not running much faster. Unless you are writing Fortran or Fortress (eventually) on a supercomputer and your code is pipelined by the compiler to be parceled out to multiple CPUs, then your programs are running in a single core. And those cores are likely to experience only marginal speed improvement in future now that some physical limits have been reached.
With Scala (and Erlang) it is possible to write functional style programs that are thread safe and more capable of utilising the power of multiple cores so your programs will run faster. Faster than those who don't adopt the functional style of programming. There's a lot coming to mind in this one sentence. Sure, you can write multi-threaded programs in Java. But it's a bit mind bending. And yes, it's a steep learning curve going from object oriented and procedural programming to functional programming, but the payoff may be immense. And you have to get yourself out of that pot before it's too late.
Where Scala is different is that it's a hybrid language that blends both object oriented and functional language facilities. That means you can begin learning Scala from a Java perspective and dip your toes into functional programming at your own pace. And you won't get your toes boiled. And because it runs on the JVM (like Groovy and JRuby) you can use all your familiar Java classes, and import from the amazing array of class libraries available for the Java platform.
And you could write one or two helper classes in Scala and use them into your Java programs, just to get your feet wet.
Are you dreaming wistfully of the next major advance in physics or nanotechnology that will lift your gently out of your predicament with a quantum leap in core performance? The steam may be already dulling your senses.
Let's assume that Moore's Law resumes its pace at the core level. Multi-core processors are not going to go away. As in economics or biology, once a business or plant variety has spread, it tends to take root and retain its selective advantage. A multi-core processor will always be better than a single-core processor. That won't get you out of the pot. Multi-core is here to stay. Programmers who realise this and take advantage of multi-core programming languages and techniques will do better than those who don't.
Don't be a boiled frog. Learn Scala now!
Here's a link I have found useful as I begin to transition from Java to (Java + Scala).
Scala for Java Refugees by Daniel Spiewak is a series of posts about Scala from a Java point of view. The comments too are of high quality, and he makes corrections based on those comments.
With limits approached on processor core speeds, multi-core processors have arisen to provide the additional performance that cannot be squeezed out of individual cores. That means that on my computer one application can be running in one core, and another in another core. If my computer has two cores, it seems that it is running those two applications twice as fast as it would have done if it had only one core.
That's true. And with each doubling of the number of cores in my computer's processor, it will be able to run more applications and all will seem well and good with Moore's Law -- from a computer user's perspective.
Computer users are not the potentially boiled frogs. It's computer programmers who will begin to feel those tiny bubbles swirling around their nether regions as they float around happily in a pot of soothing warm water with convective currents tickling their toes.
And guess what? All computer programmers are computer users. From a user perspective we see our computers getting faster. In that respect we are surprisingly good at seeing things from a user point of view. The irony is that in this case we should not be guiled by user experience. We have to think of ourselves for a change.
Our individual programs are not running much faster. Unless you are writing Fortran or Fortress (eventually) on a supercomputer and your code is pipelined by the compiler to be parceled out to multiple CPUs, then your programs are running in a single core. And those cores are likely to experience only marginal speed improvement in future now that some physical limits have been reached.
With Scala (and Erlang) it is possible to write functional style programs that are thread safe and more capable of utilising the power of multiple cores so your programs will run faster. Faster than those who don't adopt the functional style of programming. There's a lot coming to mind in this one sentence. Sure, you can write multi-threaded programs in Java. But it's a bit mind bending. And yes, it's a steep learning curve going from object oriented and procedural programming to functional programming, but the payoff may be immense. And you have to get yourself out of that pot before it's too late.
Where Scala is different is that it's a hybrid language that blends both object oriented and functional language facilities. That means you can begin learning Scala from a Java perspective and dip your toes into functional programming at your own pace. And you won't get your toes boiled. And because it runs on the JVM (like Groovy and JRuby) you can use all your familiar Java classes, and import from the amazing array of class libraries available for the Java platform.
And you could write one or two helper classes in Scala and use them into your Java programs, just to get your feet wet.
Are you dreaming wistfully of the next major advance in physics or nanotechnology that will lift your gently out of your predicament with a quantum leap in core performance? The steam may be already dulling your senses.
Let's assume that Moore's Law resumes its pace at the core level. Multi-core processors are not going to go away. As in economics or biology, once a business or plant variety has spread, it tends to take root and retain its selective advantage. A multi-core processor will always be better than a single-core processor. That won't get you out of the pot. Multi-core is here to stay. Programmers who realise this and take advantage of multi-core programming languages and techniques will do better than those who don't.
Don't be a boiled frog. Learn Scala now!
Here's a link I have found useful as I begin to transition from Java to (Java + Scala).
Scala for Java Refugees by Daniel Spiewak is a series of posts about Scala from a Java point of view. The comments too are of high quality, and he makes corrections based on those comments.
Wednesday, July 2, 2008
Groovy or Scala? Don't be a Boiled Frog!
Both!
Groovy is a fabulous language. Just read Groovy In Action and some of the other Groovy books. Just about every page brought a Wow response from this Java developer. And the Grails web stack builds on Groovy to provide a quick and powerful website building experience.
With Groovy I've written several scripts to do JSON processing. Groovy allowed me to choose an existing well tested Java class library and use it directly in my script. There was no sifting through CPAN-like libraries of varying quality and performance. And in Groovy I could throw in a few assertions and try-catch blocks. Try doing that in a shell script.
And Scala? It's harder to find documentation that is accessible to Java developers. But learning Groovy makes it easier, because there are some similar concepts.
Ted Neward has written some accessible Scala tutorials at DeveloperWorks, such as The Busy Java developer's guide to Scala: Functional programming for the object oriented.
Most of the Scala documentation that I've seen takes you to the deep end of the swimming pool very quickly. And some constructs are not well explained. For instance, what does => mean? And does it have multiple meanings in apparently syntactically similar formats?
But I find Scala intriguing, and I read on, and write small educational Scala scripts and programs despite the steep learning curve. If there were no new concepts, why would a Java developer bother learning Scala? (To paraphrase Ted Neward.)
Groovy has a gentle learning curve and the payoff in programmer productivity is rapid.
Scala (for me, a Java developer) has a steep learning curve. Is it worth it? The intellectual pleasure is substantial. Significant amounts of Scala documentation are based on Structure and Interpretation of Computer Programs which is itself a pleasure to read and keeps you thinking.
Probably type safety, versatility and performance alone make Scala well worth a close examination. Type safety doesn't eliminate the need for testing, but can catch subtle and silly bugs. Versatility: you can script it (like Groovy), delve into functional programming, and you've got all the Java libraries available to you (like Groovy).
Speed may be the killer feature. I've seen performance stats that indicate Scala is about as fast as Java. And with immutable objects and the Actor class library, it is possible to write safe multi-processor programs. This means that you can write software that can take advantage of multi-core processors.
Scala is already fast. And with its multi-threading capabilities it will get faster, along with other languages such as Erlang and Fortress.
As single-core developers we are like frogs in the pot of warm water heating gently to boiling point. For a while we are developing and deploying on machines using yesterday's high-end processors. But with Moore's Law stalled at the level of the individual core, we will fall behind the multi-core performance possibilities if we don't learn to program in multi-core environments in a scalable way. Using Java's existing multi-threading libraries is not a practical option for most developers. It's hard. And that's what Scala (and Erlang and Fortress) makes easier. Not dead easy, but easier.
Learn Groovy. Learn Scala.
Don't become a Boiled Frog!
Groovy is a fabulous language. Just read Groovy In Action and some of the other Groovy books. Just about every page brought a Wow response from this Java developer. And the Grails web stack builds on Groovy to provide a quick and powerful website building experience.
With Groovy I've written several scripts to do JSON processing. Groovy allowed me to choose an existing well tested Java class library and use it directly in my script. There was no sifting through CPAN-like libraries of varying quality and performance. And in Groovy I could throw in a few assertions and try-catch blocks. Try doing that in a shell script.
And Scala? It's harder to find documentation that is accessible to Java developers. But learning Groovy makes it easier, because there are some similar concepts.
Ted Neward has written some accessible Scala tutorials at DeveloperWorks, such as The Busy Java developer's guide to Scala: Functional programming for the object oriented.
Most of the Scala documentation that I've seen takes you to the deep end of the swimming pool very quickly. And some constructs are not well explained. For instance, what does => mean? And does it have multiple meanings in apparently syntactically similar formats?
But I find Scala intriguing, and I read on, and write small educational Scala scripts and programs despite the steep learning curve. If there were no new concepts, why would a Java developer bother learning Scala? (To paraphrase Ted Neward.)
Groovy has a gentle learning curve and the payoff in programmer productivity is rapid.
Scala (for me, a Java developer) has a steep learning curve. Is it worth it? The intellectual pleasure is substantial. Significant amounts of Scala documentation are based on Structure and Interpretation of Computer Programs which is itself a pleasure to read and keeps you thinking.
Probably type safety, versatility and performance alone make Scala well worth a close examination. Type safety doesn't eliminate the need for testing, but can catch subtle and silly bugs. Versatility: you can script it (like Groovy), delve into functional programming, and you've got all the Java libraries available to you (like Groovy).
Speed may be the killer feature. I've seen performance stats that indicate Scala is about as fast as Java. And with immutable objects and the Actor class library, it is possible to write safe multi-processor programs. This means that you can write software that can take advantage of multi-core processors.
Scala is already fast. And with its multi-threading capabilities it will get faster, along with other languages such as Erlang and Fortress.
As single-core developers we are like frogs in the pot of warm water heating gently to boiling point. For a while we are developing and deploying on machines using yesterday's high-end processors. But with Moore's Law stalled at the level of the individual core, we will fall behind the multi-core performance possibilities if we don't learn to program in multi-core environments in a scalable way. Using Java's existing multi-threading libraries is not a practical option for most developers. It's hard. And that's what Scala (and Erlang and Fortress) makes easier. Not dead easy, but easier.
Learn Groovy. Learn Scala.
Don't become a Boiled Frog!
Friday, December 28, 2007
Brief review of Spring In Action 2 -- by Craig Walls
Spring In Action (2nd edition) by Craig Walls is a pleasure to read. It's practical, direct, and leads the reader through Spring in a progressive, upward moving learning curve. Just when you had thought you now knew the neatest way to use Spring to perform a task, the book takes you higher with an even better way. This happens so consistently throughout the book, that I suspect it's a conscious learning-enhancement strategy by the author and editors. Early in the book, I was curious to know: How could this get any easier? And then in the next section there would be an even easier way!
The use of metaphor at the beginning of each chapter mentally sets the scene for what's to come. It's not left to chance. And the extended (but easily digested) examples using knights, quests, minstrels, jugglers and related metaphors enchant and amuse the reader while quietly driving the lessons home clearly and concisely.
Chapter 16 Integrating with other web frameworks provides up-to-date integration tips and techniques for the usual suspects, such as Struts 2 and Tapestry, finishing with DWR. This was my first contact with DWR (Direct Web Remoting), which is a Java framework that outputs to JavaScript and under the hood uses XMLHttpRequest to communicate with the server.
Spring In Action 3rd edition, when it is written, will likely follow DWR with a section on GWT (Google Web Toolkit) which does this and much more. See Google Web Toolkit: Build AJAX apps in the Java language. I am using GWT to write an internal corporate web application that displays images. Users are astonished at how fast it is compared with its non-Ajax predecessor. And I have to say it's pure pleasure to write Java in Eclipse and have a web application with all the necessary event handling, JUnit testing, refactoring, and cross-browser compatibility.
And I daresay there will be a further section on integrating Spring with Groovy and Grails. Actually, Spring is already integrated with Grails. Groovy and Grails are in an accelerating ascent, based on the Java ecosystem in style and substance, and with other proven scripting languages and application stacks such as Ruby and Rails for inspiration and learning. Groovy and Grails are such a great set of ideas, that they are bound to take off in a big way. I enjoyed watching some of the Grails eXchange 2007 conference presentations, and listening to some podcasts. These are well worth your attention and thought. Groovy and Grails still have their rough spots: the Grail needs a little more polishing. But their current use in production applications at such a young age suggests they have an impressive future ahead of them.
You may also wish to check out the 2G Groovy / Grails Experience 21-23 February 2008 for future developments.
The use of metaphor at the beginning of each chapter mentally sets the scene for what's to come. It's not left to chance. And the extended (but easily digested) examples using knights, quests, minstrels, jugglers and related metaphors enchant and amuse the reader while quietly driving the lessons home clearly and concisely.
Chapter 16 Integrating with other web frameworks provides up-to-date integration tips and techniques for the usual suspects, such as Struts 2 and Tapestry, finishing with DWR. This was my first contact with DWR (Direct Web Remoting), which is a Java framework that outputs to JavaScript and under the hood uses XMLHttpRequest to communicate with the server.
Spring In Action 3rd edition, when it is written, will likely follow DWR with a section on GWT (Google Web Toolkit) which does this and much more. See Google Web Toolkit: Build AJAX apps in the Java language. I am using GWT to write an internal corporate web application that displays images. Users are astonished at how fast it is compared with its non-Ajax predecessor. And I have to say it's pure pleasure to write Java in Eclipse and have a web application with all the necessary event handling, JUnit testing, refactoring, and cross-browser compatibility.
And I daresay there will be a further section on integrating Spring with Groovy and Grails. Actually, Spring is already integrated with Grails. Groovy and Grails are in an accelerating ascent, based on the Java ecosystem in style and substance, and with other proven scripting languages and application stacks such as Ruby and Rails for inspiration and learning. Groovy and Grails are such a great set of ideas, that they are bound to take off in a big way. I enjoyed watching some of the Grails eXchange 2007 conference presentations, and listening to some podcasts. These are well worth your attention and thought. Groovy and Grails still have their rough spots: the Grail needs a little more polishing. But their current use in production applications at such a young age suggests they have an impressive future ahead of them.
You may also wish to check out the 2G Groovy / Grails Experience 21-23 February 2008 for future developments.
Subscribe to:
Posts (Atom)