Showing posts with label Tools. Show all posts
Showing posts with label Tools. Show all posts

Sunday, October 02, 2016

The Secret of our Success, by Joseph Henrich

Joseph Henrich's The Secret of Our Success has a fair amount of overlap with Herculano-Houzel's The Human Advantage, which I reviewed in July. Both spend most of their attention on explaining why humans, of all the products of evolution, turned out to be the smartest and hence dominant species on the planet. The Human Advantage focused on what makes the human brain unique, and found some surprising neuronal traits that sets mammals apart from other other animals, and that make primates unique among mammals in their neuronal architecture. Henrich, on the other hand, takes pains to point out that individual humans (even very smart ones) aren't very good at figuring out how to survive in new environments. He uses that evidence to argue that communication and culture make the difference. As individuals, he claims, we aren't much smarter than other primates.

They both agree that cooking was a huge step forward for us, but Henrich takes pains to point out that this only an advantage when we're raised in a cultural group. Unlike practically all other animals, we don't instintively know how to unlock the nutrition in common foodstuffs—without training, it would take a long time (during which you have to be subsisting on something else) to figure out how to prepare most of what we eat.

The book starts out with several stories about lost european explorers becoming stranded, and if they didn't get help from locals, they would starve in the midst of what the locals would consider plenty. In Australia, the Arctic, and Florida, well-funded and trained explorers slowly starved because they couldn't figure out how to find, harvest, or prepare the foods the locals subsisted on, and they either didn't think to ask for help, or they drove away those who tried to help them. In contrast, there are a couple of stories of individual aborigines who are separated from their kin, and do just fine for years, since they grew up gathering and preparing the local bounty. His point is that our strength, as a species, is learning from one another, and picking up on every small increment in survivability.

I've been saying for years (since reading Jared Diamond's Guns, Germs, and Steel) that the thing to realize about the spread of humans and their ability to make use of local flora and fauna is that there were enough people, and people are curious enough that we tried to exploit everything, and we tried to make use of everything available in all conceivable ways. How else to explain the fact that people ate acorns, seal livers, and nardoo. In preparing nardoo, the Australian aborigines grind seeds, leech them with water, mix them with ash during heating, and use mussell shells to serve them. If you miss any step, then like the explorers, you'll die of poisoning or stavation with a full belly.

Along the way, this book has lots of interesting proposals about how culture affects prestige and dominance in ways that make it possible for us to live in larger groups and take advantage of the skills and abilities of more people; how competition for living space between groups leads to cultural differences, and how our ability and drive to share culture and learn from each other leads to increasing communication abilties and common grammar strength across the species. There are interesting tidbits spread throughout.

In talking about how living in larger groups with a larger repertoire of tools and techniques make us more capable without requiring more individual smarts or inventiveness, Henrich gave a list of simple tools that is more interesting than the standard list of 6 simple machines known since antiquity:

wheels, pulleys, springs, screws, projectiles, elastically stored energy (e.g. bows, spring traps), levers, poisons, compressed air (blow guns), rafts, leisters [a barbed spear], and heating (fire and coooking).
Instead of focusing on mechanical advantage as we do with the simple machines, this focuses on shared, reusable knowledge, and shows that there were ideas around to be re-used even in societies that were very primitive by modern standards.

Henrich has a longer more detailed time-line than Herculan-Houzel, and his focuses on evidence about tool use showing accumulation of culture rather than archeological evidence relating to brain size, cooking, and gut size. I enjoyed this book as much as Human Advantage, and it added an interesting, non-conflicting story about the roots of our intelligence. It didn't feel as if it has as much relevance to the question about our place in the universe—once we set out on the path toward communication and shared culture, Henrich didn't mention further roadblocks toward increasing advantage as we exploited the new niche better.

Sunday, November 01, 2009

Neal Gershenfeld: Programming Bits and Atoms

I followed a pointer from the Long Now Blog to The Perimeter Institute's Quantum to Cosmos Festival, and found some interesting talks. I enjoyed listening to Lee Smolin talking to Neal Stephenson and Jaron Lanier about how science informs and learns from fiction. But I had a much stronger reaction to Neil Gershenfeld's talk on what he's been doing at the Center for Bits and Atoms. It involves multi-scale parallel computronium, and fabricators in the hands of kids all over the world who are vaulting past us in understanding what it means to build stuff with embedded intelligence. A fascinating talk.

Thursday, October 15, 2009

IntelliJ IDEA open sourced

JetBrains has just announced that they've released the IntelliJ platform as open source! This is great news, as I've always maintained that IntelliJ IDEA is significantly better than all the other Java IDEs, and their main disadvantage was price, and the second biggest weakness was Eclipse's ability to let users add support for new languages. At one stroke, JetBrains has undercut both of these problems and enabled many more people to make use of the platform.

I only know what I read in the announcement and the FAQ, but it appears that JetBrains has done this for the right reasons, and probably in the right way. Their goal is to increase adoption of the platform, and to encourage third-party developers to work with IntelliJ rather than competitive products. They have kept some of their technology proprietary in order to be able to continue to run a business, and they're focusing on the larger enterprises that they make most of their money from. This is reasonable and proper.

The license they're using is Apache, which is very open and provides no significant restrictions on re-use. I'm very happy about this.

Sunday, February 24, 2008

One of the big new features of Leopard, the current release of Apple's OS X is Spaces, and I was really looking forward to using it. Unfortunately, the actual details fell short of my expectations, and I have turned it off. I've used similar features before (under X Windows, for instance) and being able to organize a larger virtual desktop can make handling many simultaneous open windows easier.

I currently have 22 application windows either open on my desktop, or collapsed in the dock. It's not unusual for there to be 10-15 open browser windows, but right now I have only 8. I have a couple of terminal windows for talking to remote computers, three emacs windows (two currently collapsed), Word, ITunes, two for Numbers (Apple's spreadsheet program), one Preview pane, Idea, Thunderbird, and Shrook (blog reader). I'd expect to separate tasks by project, so I might have a Space for tracking Real Estate, one for working on Zocalo, one for reading blogs and web pages, and so on. Without Spaces, each shelved project takes up several slots in the dock, making it harder to find whatever I'm looking to do next.

When I attempted to navigate between applications using the keyboard, Spaces would throw me around somewhat arbitrarily, breaking whatever train of thought I had going. If I used keyboard commands to switch applications, I expect the system to choose a window for that application that is already open in the current space, or if there are none, to allow me to use Command-N or Command-O to open a new one. Instead, it would arbitrarily choose an open window for that application and switch me to whatever space contained it.

In the end, I decided that I'm better off with a cluttered dock, and a single desktop than with their implementation of Spaces. Maybe the next version will do better.

Tuesday, September 26, 2006

Tools I use: Nostalgy for Thunderbird

I haven't posted anything in this category for a while, but I recently found an extension for Thunderbird that has really made my day. I've noticed for a while that re-filing messages is too mouse-oriented for my tastes, and have hoped to find a solution.

You see, I'm a keyboard-oriented person. I use emacs as my preferred text editor, but even when I use Word I learn all the keyboard shortcuts, and customize the interface to add more shortcuts so I can do as much as possible from the keyboard. I know the keyboard shortcuts for most of the programs I use regularly, and have little trouble keeping them straight between different programs.

I often say "Bill (meaning Microsoft) thinks people feel productive when they're moving the mouse, and he wants you to feel productive, so he makes sure you have to move the mouse to get anything done." The Mac has unfortunately followed in this direction more and more recently with many monologue boxes (my term for a confirmation window with only one choice.) And too many of the dialogue boxes won't let you tab to a different choice: you have to move the mouse. I thought this went against usability guidelines, but it increases nonetheless.

So anyway, back to Thunderbird. In order to refile messages in off-the-shelf Thunderbird, you can either navigate menus manually, or drag the message to a folder. If you have a large folder tree (as I do), this can be a serious hassle. I haven't figured out how to invoke the menu tree from the keyboard, since the menu is hierarchical, and AFAICT you can only add a shortcut for a leaf of the menu hierarchy. That means invoking the menubar (minimum 5 keystrokes or a mouse movement) or a context menu (mouse movement) then navigating the menus (mouse movement at each level, sub-menus might be on the right or the left; keyboard requires moving up and down with arrow keys, since individual menu items don't have live shortcuts).

Steve Putz's mail reader, Babar (only available in the version of Smalltalk that was used at PARC; the user community never exceeded 50) had a short menu of the most recently used folders that you could reach quickly for filing or visiting. The other alternative is a quick textual search from the keyboard. The Emacs front-end for mh (which I still use regularly to peruse my filtered junk mail) supports this.

Now there's a new (first release was in May) extension for Thunderbird that supports filing from the keyboard. It's called Nostalgy, and it was written by Alain Frisch. Hit a key: "s" (for save?) to refile, "c" to copy, and you can then type a regular expression while the applicable list is narrowed down as you type. And the most recently used folder is immediately accessible by capitalizing the command key, so filing to the same folder you just used (which is quite common) is just "S".

It's wonderful!

Filed in:

Friday, June 23, 2006

Cool Tools

I was looking at the longbets site, and followed some pointers and ended up on Kevin Kelly's Cool Tools page. As a certifiable tool hound (cf. my " Tools I Use" occasional feature) and follower of Kelly's Whole Earth Review and CoEvolution Quarterly, I was captivated for a couple of hours. He has them nicely categorized, so I could skip a couple of categories and concentrate on the good stuff. I bookmarked four items on Delicious, and added one to my wish list. That's a pretty high rate of return for a single site.

Filed in:
  • Monday, February 06, 2006

    Hibernate mappings are Order-Sensitive

    This won't mean much to most of you; I record it here so the search engines will be able to find it. I spent about a half day debugging a new Hibernate mapping (hbm.xml) file I just wrote. Maybe the next person to run into this will see this problem description before they spend that much time.

    This is about the tenth mapping file I've written, so I'm starting to feel like I know what I'm doing. I am defining a mapping for an object that holds a Map (Java's Dictionary: look up an Object, indexed by another Object.) In order to store a Map in an RDB, you need columns for the Object holding the Map (to identify the particular Map in the DB), the key, and the value. Once I described the mapping, I got a compilation error. The error message said mainly:

    Caused by: org.xml.sax.SAXParseException: The content of element type "map" must match "(meta*,subselect?,cache?,synchronize*, comment?,key,(map-key|composite-map-key| map-key-many-to-many|index|composite-index|index-many-to-many| index-many-to-any),(element|one-to-many|many-to-many| composite-element|many-to-any),loader?,sql-insert?,sql-update?, sql-delete?,sql-delete-all?,filter*)".

    I re-read my description several times, read the documentation many time, searched for examples using map-key-many-to-many (found very few), and scratched my head a lot. Finally, I did find a sample use of map-key-many-to-many in a different section of the manual, and wondered whether the order of declaration could possiby matter. That turned out to be the problem. Somehow, I'd been following templates and not consciously noticed that XML documents described by a DTD are order-sensitive. If there's anything in the Hibernate documentation saying that it is order-sensitive, I missed it. If you swap the lines with map-key-many-to-many and many-to-many, it won't work.

    <map name="positions" cascade="all" inverse="true">
        <key column="ACCOUNTS_ID"/>
        <map-key-many-to-many class="net.commerce.zocalo.claim.Position" />
        <many-to-many class="Coupons"/>
    </map>
    

    You can change the order of elements within a tag, but you can't change the order of the tags. Beware!

    Monday, October 10, 2005

    Catalogues I Regularly Read

    I thought I'd mention two catalogues that I actually read cover-to-cover whenever they arrive. I get plenty of catalogues that I file for when I need something (Mac stuff, cameras, fruit and nuts, hot sauces), and several that I throw away without opening. These two have a high enough hit rate that I actually page through the whole thing seeing what's interesting and new. I'm not going to mention things like Laissez Faire Books that everyone already knows about.

    One is Levenger, "Tools for Serious Readers". They have furniture, innovative office supplies, stationary, carrying cases and more. I've probably purchased things from them a dozen times. Before the era of the Palm, I used their note cards and carrying case for my calendar, contact list, todos, etc. They have wonderful variations on paperclips, papercutters, and notepads that are the perfect answer to many minor problems. Their bags are well-designed (need a computer carrying case?), they have great side tables for books, as well as lap desks to make working in an easy chair more comfortable. They spend too many pages on fancy fountain pens, but their reading lights can't be matched in any of the lighting stores I've looked in over the years.

    The other catalogue I read is Daedalus Books. They sell remainders, and seem to have good taste. I regularly find interesting history, science, occasionally science fiction, and general non-fiction. For many years, I carefully read all the pages of children's books looking for good new stuff to read to the nieces and nephews, but they're mostly past that age at this point. A few years ago, Ted Kaehler mentioned that he'd been reading a lot about the history of espionage in WW II, and I found that Daedalus had one or two of those most months, so I've been reading them as well.

    When you know what you're looking for, searching on-line works well enough, but when you want someone to recommend things that you hadn't realized you needed, there's still no substitute for a paper catalogue. I can do a much more thorough job of perusing the pages of Daedalus than any book store or library I've ever been in, and I don't know of any stores that can change their inventory every month, or have as high a hit rate as Levenger.

    Wednesday, July 27, 2005

    Tools I use: Ant

    I've been using , a build tool for Java. It works pretty well, and overall I'm glad I'm using it. Zocalo builds cleanly on my desktop Mac, my PowerBook, and the linux server at CommerceNet. Any of the platforms will compile, test, and build javadoc or tar files, even when I couldn't find a copy of javadoc without a lot of effort. Ant is much more flexible and powerful than the special purpose shell scripts we used at Agorics. We had all previously used Make, so we knew that that style of approach had its advantages, but Make apparently doesn't really work with complex Java projects, so it's nice that Ant has been built to fill that gap.

    But I just don't understand the fascination with XML. XML is a really lousy language for people to interact with directly. I could understand it if people wanted to use XML as an interchange language between programs, but it doesn't seem to have any advantages over s-expressions. The extra syntax just leads to extra possibilities for mistakes, without any value when edited by hand. Shouldn't Ant ship with an editor that lets you fill out a form to create your ant description? Why do we have to hand edit the XML?

    Anyway, I also wanted to point out the solution to one of my problems. It took a while to find the right way to invoke . There's apparently a common problem caused because the ant task for JUnit relies on an optional package that isn't in the standard classpath. Rather than mucking up your classpath for your project with ant's optional tasks, you can just write a recursive call on ant that sets the appropriate classpath and then invokes the simple JUnit task. The details are given on the Open Source Lab's wiki. The recursive call is simple:

    <target name="test" description="Run JUnit Via Exec">
       <exec executable="ant">
           <env key="CLASSPATH" path="${basedir}/lib/junit.jar"/>
           <arg line="testTask"/>
       </exec>
    </target>
    

    Once you've done that, the JUnit task works correctly, so you can specify which tasks to run using a fileset pattern, rather than enumerating all the test classes as you'd have to do if you tried to work around the classpath problem by execing JUnit directly.

    I added one thing to Open Source Lab's suggestion: I wanted a short listing of failures printed out, so I grepped JUnit's output files. All I had to do was add these lines before /target:

    <exec executable="egrep">
       <arg line="-r" />
       <arg line="'(Failures: [^0]|Errors: [^0])'" />
       <arg line="TEST" />
    </exec>
    

    Thursday, July 21, 2005

    Tools I Use: realage.com

    I'm going to occasionally write about tools I use that do their job well. These can range from software to garden tools to tips and tricks that I think will be new to other people. Most often, they'll be software of one kind or another. Today's tool falls in the category of and .

    I have several sources that I rely on for health advice: Janet (my S.O.), Health Magazine, and realage.com are the primary ones. Health Magazine used to be aimed at a wide audience, but now is more focused on women. It still has a fairly high standard for articles on health-related issues. All I have to do is skip over the beauty tips, and the rest is fairly useful. (Their main sections are Body, Mind, Food, Beauty, and Fitness.) There's more relationship advice than I need, but it's about getting along with your boss as often as about getting along with your mate, and they don't have silly articles about how to attract the perfect man, so I don't object to it. As I said, their standards are fairly high in terms of insisting that their writers cover subjects where there's research behind the advice. They don't alays give sources, but often do refer to the scientists behind the findings, or even interview them.

    The other source I go to is realage.com. Their schtick is to ask you a bunch of health, lifestyle, exercise and dietary questions, and then tell you your "real age", reflecting your life expectancy as a comparative age. They tell me I'm doing many things right, so my "real age" is about 39, while I'm chronologically 46.

    They also have plenty of advice about what you might change about your lifestyle to decrease your real age. The feedback and memetics on this are really good for those with a little ability for delayed gratification. The things you change about your life are reflected immediately in your expected lifespan, and apparent youth! If you backslide, you know it's increasing your real age *now*, not eventually.

    I was initially attracted to this site by an article in "Health" Magazine that said that the people running the site are doing a good job of relying on and referring to the best scientific research on what changes make an actual difference in longevity. They provide references to the review papers that establish the efficacy of their advice when I've dived deeper into particular recommendations. Their policy is to only rely on results that are stable across repeated clinical trials. Their "real age" metric gives a very good feel for the effectiveness of lifestyle changes. You can easily decide whether you're willing to make different changes in your life when the benefits are expressed in a commonsense unit like an extra 6 months or 3 years of expected lifespan.

    I currently take Vitamins C and E, Folic acid, and Calcium on the basis of the advice from RealAge.com. I'm slowing down to closer to the speed limit when I drive, because this makes almost a year's difference in my RealAge. I occasionally revisit the site and update my answers when something changes in my life to find out how I'm doing. I changed jobs recently, and so I'm riding my bike more often than I have in 15 years, for example.

    I recommend the site.