Re:Evolution versus artificial modification
on
Cosmetic Neurology
·
· Score: 4, Interesting
The toothbrush has only been in widespread use for the last few hundered years, so evolution has already had it's chance to do what it could with humans who didn't brush.
You can't "evolve" past the basic fact that your mouth is a breeding ground for bacteria, and that as that bacteria piles up and dies it's going to create unsightly, disgusting plaque. Well, maybe if humans grew stainless steel teeth -- but that'd be quite the stretch in evolution, since we'd need some kind of organ to act as a smelting and refining and we'd need to digest lots of raw ore...
Humans have done quite well without the toothbrush in terms of dentistry. Weston Price's work well documented that primitive people's had very low incidences of tooth decay and other dental problems when subsiting on a native diet, and how members of those same cultures who had transitioned to a western diet had much, much higher incidences of tooth decay.
From the article, "For breakfast every morning, he concocted a slurry of oatmeal, berries, soy milk, pomegranate juice, flaxseed, almond meal, raw eggs, and protein powder. The goal behind the recipe was efficiency: to rely on âoeone goop you could eat or drink that would have everything you need nutritionally for your brain and body.â He explained, âoeTaste was the last thing on my mind; I wanted to be able to keep it downâ"that was it.â"
I started having a nutritionally complete shake for breakfast every morning - and it rocks! But I wouldn't describe it's taste as something that I have trouble keeping down - instead it's very yummy. The recipe I usually use was designed by nutritionist Sam Graci and is:
* 1 cup of berries (blueberries, blackberries)
* 2 scoops of high alpha whey protein
* 1 tbsp high-quality fish oil
* 1/2 tsp borage oil
* 2 tbsps flax seeds and 2 tbsps sesame seeds, ground in a coffee grinder
* 4-6 tbsps plain low-fat organic yogurt
* 1 cup rice milk or soy milk
That's the basic recipe, but there are lots of other ingredients you can use to mix it up: hemp protein powder, other fruits (banana, strawberry, kiwi), acai and goji juice, raw eggs.
The basic idea of the breakfast shake is that your bodies metabolism has started to slow down since you haven't eaten since yesterday evening... you want to have a nice balance of carbs, protein and fat to get your metabolism back in the game. Nutritionally you also want to have lots of omega 3 fatty acids (flax and fish oil) which promotes healthy brain cells and also foods with high anti-oxidant properties to promote healthy blood (berries). Finally the probiotics in the yogurt promote healthy digestion.
Combine the breakfast shake with a daily green drink and a healthy diet of lots of veggies and fruits, and you will notice a marked improvement in overall energy and mental functioning -- I estimated that I could crank out 25% more lines of code after a couple months, and overall my code was of markedly better quality. Plus since your overall mood is better I was about 25% less acerbic in conversations with my co-workers:P
Good advice. Although it shouldn't be a rigid rule, sometimes it's a lot of hassle to install your own separate versions of your own stuff's dependencies. Especially for your own stuff which is install more ephemerally, such as development sandboxes.
For example, Mac OS X provides a working OpenLDAP install. You can make LDAP instances from this install into your own stuff, but rely on their openldap binaries. A lot easier than compiling your own version of OpenLDAP.
But then, it would be nice if Apple kept this rule in mind themselves, and had the distinction between, "Core Apple OS stuff" and "Apple Applications stuff". For example, the Apple Python install is pretty useless, you need to use virtualenv to isolate yourself from all the ancient libraries that are in there to support iCal server. It would be much better if Apple shipped a bare bones Perl and a Python w/ standard library only and said, "We aren't going to provide any form of library management, but we also aren't going to pollute the standard library paths with a bunch of half-maintained crap that our own Apple apps happen to depend upon."
"Once I have a specific idea, what are next steps?"
Refine your idea. Ideas always start vague, they need to be nurtured, rethought, and made even more specific. A good way to do this is TO TELL PEOPLE YOUR IDEA!
OK, I'll start, since I have a great idea: I would like a pony.
Yeah, it's kind of vague - what kind of pony? I'm not a ponyologist and don't know the first thing about ponies so I need to find someone who can help me select the best pony in the world.
Who is going to buy me this pony? I'd really rather not pay for it although I'm willing to part with some spare change.
Where will I put the pony? I've heard you can store them on sourceforge, but that this often results in pony cancer and other nasty pony diseases.
Who is going to feed my pony? I've heard they need to be fed at for at least week, although I good ponyologist probably just needs to feed my pony for a couple of days.
I have already started attempting to develop my idea, so I'll tell you some advice that people have been telling me. I wrote on a piece of paper, "want free pony" and then went down to a busy street corner and started asking strangers to help me and they all gave me the same advice, so I assume it's good... "GET A JOB!"
If an overly open disclosure policy is perceived to affect future sales or the value of the brand (i.e. "goodwill"), legal will tell them to say nothing unless they are breaking a bigger law (i.e. gross negligence) by saying nothing.
However, The Red Hat brand is synonymous with openness and trustworthiness - if they say nothing they could be affecting the value of their brand and breaking the law. But I've never studied any of the laws governing shareholder responsibility. Anyone with knowledge of these things care to comment on how these laws could be interpreted in this case?
There is no such thing as the "Model-View-Controller design pattern". The original Design Patterns book says right in the introduction, "Looking at the design patterns inside MVC should help you see what we mean by the term 'pattern'". At which point they detail some of the patterns in the Smalltalk-80 MVC architecture and describe how different design patterns in it bring certain benefits to the code... MVC is way to many different things to call it a "pattern".
Look at what a "Controller" is in Rails - people put auth/auth code in them, caching code, "helpers" are mixed-in to the Controller class, and all kinds of other concerns that could be separated out into other components - but MVC dogma means that people feel compelled to stuff everything within three simple categories. Silly.
Right now we use External Methods to make specific functions available inside Zope, but the side effect of that is that we have to restart the Zope process every time we want to run new code.
Eww, External Methods. You can refresh an external method without restarting the process - but if you are using external methods then you're most likely using old school style of Zope development. It was cool in the year 2000 - but today one should "run away!" - you'll be much better off with Django or TurboGears.
Zope hasn't been sitting still for the last 8 years though. Zope 3 style development became stable around 2005, which was dramatically different than Zope 2 development - no code-in-the-database, acquisition or any of the less fortunate choices made in the early days of Zope. But Zope 3 has quite a learning curve and doesn't have the immediate productivity of Django or TurboGears. Grok (http://grok.zope.org) is the newest framework from Zope-land, and it's much more similar in development style to Django and TurboGears. It's what I use so, I recommend it:). Conceptually you'll find it a smidge more complex than Django or TurboGears, but there is a lot of nice stuff in Grok - it's the only Python framework that uses convention-over-configuration and it's buildout-based installer makes it easy to upgrade specific parts of the framework easily for example. Of course, porting an old school Zope 2 app to Grok is no easier than porting to Django or TurboGears - Zope 2 and Grok are really quite different beasts.
Any thoughts on the matter? I've used Django for some small projects and my experience kind of mirrored what I'd read: it's brilliant when you want to work with it, and a complete PITA when you're trying to do something unexpected. I haven't written anything with Turbogears yet so I can't personally compare them.
Well, poor Django often gets knocked for "not handling the unexpected". This is because the framework bundles application code with it (the admin app)- but in those cases where the app code doesn't do what you want you can just not use that app code. In which case you are around the same place you'd be with TurboGears. However, TurboGears is already distributing it's framework as individual parts, so you are, at least culturally, one step closer to integrating Python packages that don't ship w/ the framework into your project.
Because Zope is so minimally threaded, that means that other page views are delayed until those reports are finished.
FYI, you can configure the number of threads with the "zserver-threads" option in the zope.conf file (the default is 4). But then your most likely better spending your time porting to newer technologies than mucking around with the old stuff.
And declare a hard-location to your interpreter and every additional library location or egg that you depend upon. Python has tools such as zc.buildout that make it easy to specify the parts (and versions) that your application requires to run. Then a build tool can be used to deploy an explicit set of PATHs to any location on your system. This gives you the best of both worlds, as everything is explicit, but if you move things, upgrade, switch operating systems, etc, then you can just re-run your build recipe to re-create a working application.
The Python 2 to Python 3 transition is not the same as Perl 5 to Perl 6. Perl 6 is a major rethinking of Perl, with a lot of changes. Python 3 is still very similar to Python 2 with very few syntactical changes - the primary motivation for Python 3 to break backwards compatability was to be able to purge implementation cruft from the language that was mostly derived from early design mistakes.
It's true that you'll need to do work to port/test code from Python 2 to Python 3, but learning the syntactical differences can be done in an afternoon, as there aren't that many:
Reporter, "Mr Einstein, would it be possible to take your phone number in case I have any further questions?"
"Certainly" replied Einstein. He picked up the phone directory and looked up his phone number, then wrote it on a slip of paper and handed it to the reporter.
Dumbfounded, the reporter said, "You are considered to be the smartest man in the world and you can't remember your own phone number?"
Einstein replied, "Why should I memorize something when I know where to find it?"
"Beyond this the python notation is terrible; verbose, clumsy, the white-space requirements are completely ridiculous and impositional". The Python syntax excels at creating maintainable software, yes some people take offense that Python is trying to take away their creative control of white-space and other common language styles, but this is only a boon when you have software that has to be maintained by more than a single developer. I would certainly raise the red flag to any team taking advice from someone who can't distinguish between their own personal development preferences and the attributes inherent in a particular technology.
I've delegated Zope/Plone sysadmin responsibilities to people who little about Linux let alone system administration and they were able to keep Plone running without too much effort.
Perhaps you were trying to deploy on Solaris? I've heard Zope runs not-so-good on that OS.
Plone's focus is on being a CMS. It is also often used as a content deployment system, but it doesn't have to be. Products such as Entransit let you manage content in Plone, and then push it out into a relational database/XML formats if your web site happens to already have significant investment in other technologies (ASP/PHP/etc)
I guess a good analogy in regards to the Zope that Plone runs on would be "Python is the 'GNU/Linux', Zope is the 'GNOME', and Plone is the 'Firefox'".
Zope has been around for almost 10 years now, so when people say "Zope" they can mean very different things. Zope 2 was originally used as a content management systems and a through-the-web development environment using the Zope Management Interface (ZMI). This was way back in 1998-2000 when web sites were simpler and mixing these UI of these two applications into one didn't seem so egregious at the time. Today the ZMI still exists, although it is only used to do more advanced customizations to a Plone site. Plone still runs on Zope 2, but Zope 3 was developed starting in 2001 as a from-scratch rewrite. Initially there was the idea that Zope 3 would replace Zope 2, but Zope 3 was also designed to be an extremely "loosely coupled" system - Zope 3 is sometimes called "The Framework without a Frame". Zope 2 started to ship the majority of Zope 3 as libraries, only of course it was still Zope 2, and called Zope 2 except it has Zope 3 inside of it and Zope 3 the standalone framework was also still available and this confused the heck out of everyone. Today Zope 3 is primarily used as a suite of integrated libraries - many of these libraries are now available packaged as Python eggs, and the current Zope 3 focus is on improving the ability for any Python web application to only use "small pieces" of the Zope 3 libraries. Finally there is Grok, which takes the Zope 3 libraries and applies the practice of "convention over configuration" to give you a Ruby on Rails like development experience, while still retaining all of the wonderful capabilites of the Zope 3 library such as a sohpisticated security system and the component architecture.
> The overall effect is that if you try to write something complicated in Python, everything goes along just great until you hit some library bug that can't easily be fixed. Or you discover that you need racks of servers to compensate for the painfully slow implementation.
> That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.
You mean something complicated like a feature-rich Content Management System such as Plone?
Plone has been known to replace racks of servers of commercial CMSes with a single server. And those commercial CMSes are written in things like Java and C++. Python has very little competition from Perl in the feature-rich CMS space.
Personally, I've known a lot of developers who switched from Python to Perl (myself included). I've never met a single person who has made the transition in the other direction.
> Wow, they break compatibility with every dot release? That sounds crazy to me
That would indeed be crazy. Python has not had any significant breaks in backwards compatability since I started using it in 1999. You can run a Python 1.5 or Python 2.0 program just fine in a Python 2.5 program. Of course, if you are taking advantage of a language feature introduced in Python 2.5 of course you can't run it in a earlier release.
There are a few exceptions, such as code that interfaces with C has had changes. But Python developers have put a lot of time and effort into maintaining backwards compatability. This is the point of breaking backwards compatability in Python 3, and the current Python 2.5 implementation has a lot of verbose, length code that deals with a lot of corner cases that almost no one uses. Python 3 is about fixing all those small things that you can't fix without breaking backwards compatability, and about ditching all that backwards compatablity that is in Python 2 that makes maintainence and optimization that much harder.
> I suppose doing stuff like that is hard and boring for most people. So they'd rather do stuff like come out with python3k or perl6 instead of a fast python2.x/perl5.
No. Please read the article(s), it is inaccurate to compare Python 3 development with Perl 6 development. Bruce Eckel was whinging about Python 3 not doing enough "fun stuff" as Python 3 is really only concerned with removing warts that resulted from early design decisions in Python. Perl 6 is about doing "fun stuff". As for performance, the cPython implementation in Python 2 has had a lot of optimization work done to it. Much optimization work done to Python 3 will be available to Python 2 in the form of the Python 2.6 release.
What? No. There are no limitations in the C implementation of the Python 2 runtime environment that are not also in the C implementation of the Perl 5 runtime environment. Both of the languages have a lot of similar characteristics. Both were developed at around the same time, with Perl starting a few years earlier. Perl 4 came out in 1991, Perl 5 in 1993, Python 1 came out in 1994.
The "Perl engine" only runs Perl code. It does not run any other languages.
You can run Python from within Perl though using both runtimes:
In the meantime, if you want to write in a dynamic language you can run Python in the JVM or IronPython in the CLR. Then you can use a single runtime to call into Java or C# or Javascript or Ruby or VisualBasic. You can not do this with Perl 5, it is extremely unlikely that Perl 5 will every be supported outside of it's single C implementation. These limitations in the Perl 5 runtime are why your Perl community has been doing a from-scratch rewrite of Perl these last 7 years or so...
mdfind, the command line interface to Spotlight, allows you to perform searches similar to locate only they are always up-to-date. It's also much faster than find. From 'man mdfind':
DESCRIPTION
The mdfind command consults the central metadata store and returns a list
of files that match the given metadata query. The query can be a string
or a query expression.
Very useful in conjuction with mdfind is mdls, which will display what attributes have been indexed for a given file.
It takes several orders of magnitude more work and money to upgrade a car engine. 12% is a very low number, I'm sure the same question for Windows 95 or Windows would have been very different, and it has also been very different for the last two releases of Mac OS X. In addition, if a new car engine ran slower, this would be considered a failure.
Re:All new 3D Shooters are missing one thing...
on
Prey Review
·
· Score: 1
Co-op mode is making a bit of a come back with the new round of consoles all supporting internet play. Ghost Recon Advanced Warfighter, Perfect Dark Zero and Kameo on the XBox 360 all have a co-op mode.
Re:Why does everyone hate this game so much?
on
Review - Full Auto
·
· Score: 1
I've played Full Auto quite a bit since it came out, perhaps 20 hours worth. Sure, the game lacks depth, but the core game play is really fun. Bombing through a city, clearing traffic with your rocket launcher and then turbo boosting off a jump and flipping end of over end as you fly 400 feet through the air to smash into a car dealership is really very satisfying.
The game feels like a set of Grand Theft Auto mini-games. Sure it feels like only 5% of a GTA game, but it feels like the first 5% of a next-gen GTA game:)
Slashdot Mirror
The toothbrush has only been in widespread use for the last few hundered years, so evolution has already had it's chance to do what it could with humans who didn't brush.
You can't "evolve" past the basic fact that your mouth is a breeding ground for bacteria, and that as that bacteria piles up and dies it's going to create unsightly, disgusting plaque. Well, maybe if humans grew stainless steel teeth -- but that'd be quite the stretch in evolution, since we'd need some kind of organ to act as a smelting and refining and we'd need to digest lots of raw ore ...
Humans have done quite well without the toothbrush in terms of dentistry. Weston Price's work well documented that primitive people's had very low incidences of tooth decay and other dental problems when subsiting on a native diet, and how members of those same cultures who had transitioned to a western diet had much, much higher incidences of tooth decay.
From the article, "For breakfast every morning, he concocted a slurry of oatmeal, berries, soy milk, pomegranate juice, flaxseed, almond meal, raw eggs, and protein powder. The goal behind the recipe was efficiency: to rely on âoeone goop you could eat or drink that would have everything you need nutritionally for your brain and body.â He explained, âoeTaste was the last thing on my mind; I wanted to be able to keep it downâ"that was it.â"
I started having a nutritionally complete shake for breakfast every morning - and it rocks! But I wouldn't describe it's taste as something that I have trouble keeping down - instead it's very yummy. The recipe I usually use was designed by nutritionist Sam Graci and is:
* 1 cup of berries (blueberries, blackberries)
* 2 scoops of high alpha whey protein
* 1 tbsp high-quality fish oil
* 1/2 tsp borage oil
* 2 tbsps flax seeds and 2 tbsps sesame seeds, ground in a coffee grinder
* 4-6 tbsps plain low-fat organic yogurt
* 1 cup rice milk or soy milk
That's the basic recipe, but there are lots of other ingredients you can use to mix it up: hemp protein powder, other fruits (banana, strawberry, kiwi), acai and goji juice, raw eggs.
The basic idea of the breakfast shake is that your bodies metabolism has started to slow down since you haven't eaten since yesterday evening ... you want to have a nice balance of carbs, protein and fat to get your metabolism back in the game. Nutritionally you also want to have lots of omega 3 fatty acids (flax and fish oil) which promotes healthy brain cells and also foods with high anti-oxidant properties to promote healthy blood (berries). Finally the probiotics in the yogurt promote healthy digestion.
Combine the breakfast shake with a daily green drink and a healthy diet of lots of veggies and fruits, and you will notice a marked improvement in overall energy and mental functioning -- I estimated that I could crank out 25% more lines of code after a couple months, and overall my code was of markedly better quality. Plus since your overall mood is better I was about 25% less acerbic in conversations with my co-workers :P
Good advice. Although it shouldn't be a rigid rule, sometimes it's a lot of hassle to install your own separate versions of your own stuff's dependencies. Especially for your own stuff which is install more ephemerally, such as development sandboxes.
For example, Mac OS X provides a working OpenLDAP install. You can make LDAP instances from this install into your own stuff, but rely on their openldap binaries. A lot easier than compiling your own version of OpenLDAP.
But then, it would be nice if Apple kept this rule in mind themselves, and had the distinction between, "Core Apple OS stuff" and "Apple Applications stuff". For example, the Apple Python install is pretty useless, you need to use virtualenv to isolate yourself from all the ancient libraries that are in there to support iCal server. It would be much better if Apple shipped a bare bones Perl and a Python w/ standard library only and said, "We aren't going to provide any form of library management, but we also aren't going to pollute the standard library paths with a bunch of half-maintained crap that our own Apple apps happen to depend upon."
"Once I have a specific idea, what are next steps?"
Refine your idea. Ideas always start vague, they need to be nurtured, rethought, and made even more specific. A good way to do this is TO TELL PEOPLE YOUR IDEA!
OK, I'll start, since I have a great idea: I would like a pony.
Yeah, it's kind of vague - what kind of pony? I'm not a ponyologist and don't know the first thing about ponies so I need to find someone who can help me select the best pony in the world.
Who is going to buy me this pony? I'd really rather not pay for it although I'm willing to part with some spare change.
Where will I put the pony? I've heard you can store them on sourceforge, but that this often results in pony cancer and other nasty pony diseases.
Who is going to feed my pony? I've heard they need to be fed at for at least week, although I good ponyologist probably just needs to feed my pony for a couple of days.
I have already started attempting to develop my idea, so I'll tell you some advice that people have been telling me. I wrote on a piece of paper, "want free pony" and then went down to a busy street corner and started asking strangers to help me and they all gave me the same advice, so I assume it's good ... "GET A JOB!"
If an overly open disclosure policy is perceived to affect future sales or the value of the brand (i.e. "goodwill"), legal will tell them to say nothing unless they are breaking a bigger law (i.e. gross negligence) by saying nothing.
However, The Red Hat brand is synonymous with openness and trustworthiness - if they say nothing they could be affecting the value of their brand and breaking the law. But I've never studied any of the laws governing shareholder responsibility. Anyone with knowledge of these things care to comment on how these laws could be interpreted in this case?
Agreed!
There is no such thing as the "Model-View-Controller design pattern". The original Design Patterns book says right in the introduction, "Looking at the design patterns inside MVC should help you see what we mean by the term 'pattern'". At which point they detail some of the patterns in the Smalltalk-80 MVC architecture and describe how different design patterns in it bring certain benefits to the code ... MVC is way to many different things to call it a "pattern".
Look at what a "Controller" is in Rails - people put auth/auth code in them, caching code, "helpers" are mixed-in to the Controller class, and all kinds of other concerns that could be separated out into other components - but MVC dogma means that people feel compelled to stuff everything within three simple categories. Silly.
Right now we use External Methods to make specific functions available inside Zope, but the side effect of that is that we have to restart the Zope process every time we want to run new code.
Eww, External Methods. You can refresh an external method without restarting the process - but if you are using external methods then you're most likely using old school style of Zope development. It was cool in the year 2000 - but today one should "run away!" - you'll be much better off with Django or TurboGears.
Zope hasn't been sitting still for the last 8 years though. Zope 3 style development became stable around 2005, which was dramatically different than Zope 2 development - no code-in-the-database, acquisition or any of the less fortunate choices made in the early days of Zope. But Zope 3 has quite a learning curve and doesn't have the immediate productivity of Django or TurboGears. Grok (http://grok.zope.org) is the newest framework from Zope-land, and it's much more similar in development style to Django and TurboGears. It's what I use so, I recommend it :). Conceptually you'll find it a smidge more complex than Django or TurboGears, but there is a lot of nice stuff in Grok - it's the only Python framework that uses convention-over-configuration and it's buildout-based installer makes it easy to upgrade specific parts of the framework easily for example. Of course, porting an old school Zope 2 app to Grok is no easier than porting to Django or TurboGears - Zope 2 and Grok are really quite different beasts.
Any thoughts on the matter? I've used Django for some small projects and my experience kind of mirrored what I'd read: it's brilliant when you want to work with it, and a complete PITA when you're trying to do something unexpected. I haven't written anything with Turbogears yet so I can't personally compare them.
Well, poor Django often gets knocked for "not handling the unexpected". This is because the framework bundles application code with it (the admin app)- but in those cases where the app code doesn't do what you want you can just not use that app code. In which case you are around the same place you'd be with TurboGears. However, TurboGears is already distributing it's framework as individual parts, so you are, at least culturally, one step closer to integrating Python packages that don't ship w/ the framework into your project.
Because Zope is so minimally threaded, that means that other page views are delayed until those reports are finished.
FYI, you can configure the number of threads with the "zserver-threads" option in the zope.conf file (the default is 4). But then your most likely better spending your time porting to newer technologies than mucking around with the old stuff.
Looks like they are using Plone as a CMS as well as for deployment, since good ol' /ZopeTime works :P
http://nasascience.nasa.gov/ZopeTime
"You should NEVER read the Silly Parenthesis in LISP, that gets taken care of for you by any one of a gazillion tools."
Tools do your reading for you? How does that work?
#!python:v2.6
..., ...,
That would be:
#!/usr/bin/env python
Or if you want to specify 2.6 only:
#!/usr/bin/env python2.6
Then your application just needs to take care to supply it's own enivronment:
export PATH=/path/to/buildspace/python-2.5.1/bin/:$PATH
Or you can do:
#!/Users/kteague/python/2.4.4/bin/python
import sys
sys.path[0:0] = [
'/Users/kteague/buildouts/my-project/src/',
'/Users/kteague/buildouts/shared/eggs/zdaemon-2.0.0-py2.4.egg',
]
And declare a hard-location to your interpreter and every additional library location or egg that you depend upon. Python has tools such as zc.buildout that make it easy to specify the parts (and versions) that your application requires to run. Then a build tool can be used to deploy an explicit set of PATHs to any location on your system. This gives you the best of both worlds, as everything is explicit, but if you move things, upgrade, switch operating systems, etc, then you can just re-run your build recipe to re-create a working application.
The Python 2 to Python 3 transition is not the same as Perl 5 to Perl 6. Perl 6 is a major rethinking of Perl, with a lot of changes. Python 3 is still very similar to Python 2 with very few syntactical changes - the primary motivation for Python 3 to break backwards compatability was to be able to purge implementation cruft from the language that was mostly derived from early design mistakes.
It's true that you'll need to do work to port/test code from Python 2 to Python 3, but learning the syntactical differences can be done in an afternoon, as there aren't that many:
http://docs.python.org/dev/3.0/whatsnew/3.0.html
Reporter, "Mr Einstein, would it be possible to take your phone number in case I have any further questions?"
"Certainly" replied Einstein. He picked up the phone directory and looked up his phone number, then wrote it on a slip of paper and handed it to the reporter.
Dumbfounded, the reporter said, "You are considered to be the smartest man in the world and you can't remember your own phone number?"
Einstein replied, "Why should I memorize something when I know where to find it?"
Sweet bejezus!
"Beyond this the python notation is terrible; verbose, clumsy, the white-space requirements are completely ridiculous and impositional". The Python syntax excels at creating maintainable software, yes some people take offense that Python is trying to take away their creative control of white-space and other common language styles, but this is only a boon when you have software that has to be maintained by more than a single developer. I would certainly raise the red flag to any team taking advice from someone who can't distinguish between their own personal development preferences and the attributes inherent in a particular technology.
I've delegated Zope/Plone sysadmin responsibilities to people who little about Linux let alone system administration and they were able to keep Plone running without too much effort.
Perhaps you were trying to deploy on Solaris? I've heard Zope runs not-so-good on that OS.
Plone's focus is on being a CMS. It is also often used as a content deployment system, but it doesn't have to be. Products such as Entransit let you manage content in Plone, and then push it out into a relational database/XML formats if your web site happens to already have significant investment in other technologies (ASP/PHP/etc)
http://www.enfoldsystems.com/Products/Entransit
I guess a good analogy in regards to the Zope that Plone runs on would be "Python is the 'GNU/Linux', Zope is the 'GNOME', and Plone is the 'Firefox'".
Zope has been around for almost 10 years now, so when people say "Zope" they can mean very different things. Zope 2 was originally used as a content management systems and a through-the-web development environment using the Zope Management Interface (ZMI). This was way back in 1998-2000 when web sites were simpler and mixing these UI of these two applications into one didn't seem so egregious at the time. Today the ZMI still exists, although it is only used to do more advanced customizations to a Plone site. Plone still runs on Zope 2, but Zope 3 was developed starting in 2001 as a from-scratch rewrite. Initially there was the idea that Zope 3 would replace Zope 2, but Zope 3 was also designed to be an extremely "loosely coupled" system - Zope 3 is sometimes called "The Framework without a Frame". Zope 2 started to ship the majority of Zope 3 as libraries, only of course it was still Zope 2, and called Zope 2 except it has Zope 3 inside of it and Zope 3 the standalone framework was also still available and this confused the heck out of everyone. Today Zope 3 is primarily used as a suite of integrated libraries - many of these libraries are now available packaged as Python eggs, and the current Zope 3 focus is on improving the ability for any Python web application to only use "small pieces" of the Zope 3 libraries. Finally there is Grok, which takes the Zope 3 libraries and applies the practice of "convention over configuration" to give you a Ruby on Rails like development experience, while still retaining all of the wonderful capabilites of the Zope 3 library such as a sohpisticated security system and the component architecture.
Oops, I meant to say Perl to Python. I've never met anyone who switched from Python to Perl though.
> The overall effect is that if you try to write something complicated in Python, everything goes along just great until you hit some library bug that can't easily be fixed. Or you discover that you need racks of servers to compensate for the painfully slow implementation.
> That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.
You mean something complicated like a feature-rich Content Management System such as Plone?
http://plone.org/
Plone has been known to replace racks of servers of commercial CMSes with a single server. And those commercial CMSes are written in things like Java and C++. Python has very little competition from Perl in the feature-rich CMS space.
Personally, I've known a lot of developers who switched from Python to Perl (myself included). I've never met a single person who has made the transition in the other direction.
> Wow, they break compatibility with every dot release? That sounds crazy to me
That would indeed be crazy. Python has not had any significant breaks in backwards compatability since I started using it in 1999. You can run a Python 1.5 or Python 2.0 program just fine in a Python 2.5 program. Of course, if you are taking advantage of a language feature introduced in Python 2.5 of course you can't run it in a earlier release.
There are a few exceptions, such as code that interfaces with C has had changes. But Python developers have put a lot of time and effort into maintaining backwards compatability. This is the point of breaking backwards compatability in Python 3, and the current Python 2.5 implementation has a lot of verbose, length code that deals with a lot of corner cases that almost no one uses. Python 3 is about fixing all those small things that you can't fix without breaking backwards compatability, and about ditching all that backwards compatablity that is in Python 2 that makes maintainence and optimization that much harder.
> I suppose doing stuff like that is hard and boring for most people. So they'd rather do stuff like come out with python3k or perl6 instead of a fast python2.x/perl5.
No. Please read the article(s), it is inaccurate to compare Python 3 development with Perl 6 development. Bruce Eckel was whinging about Python 3 not doing enough "fun stuff" as Python 3 is really only concerned with removing warts that resulted from early design decisions in Python. Perl 6 is about doing "fun stuff". As for performance, the cPython implementation in Python 2 has had a lot of optimization work done to it. Much optimization work done to Python 3 will be available to Python 2 in the form of the Python 2.6 release.
What? No. There are no limitations in the C implementation of the Python 2 runtime environment that are not also in the C implementation of the Perl 5 runtime environment. Both of the languages have a lot of similar characteristics. Both were developed at around the same time, with Perl starting a few years earlier. Perl 4 came out in 1991, Perl 5 in 1993, Python 1 came out in 1994.
...
The "Perl engine" only runs Perl code. It does not run any other languages.
You can run Python from within Perl though using both runtimes:
http://search.cpan.org/~neilw/Inline-Python-0.20/Python.pod
And perhaps one day you can run both scripts interchangeably if Parrot achieves is goals:
http://www.parrotcode.org/
In the meantime, if you want to write in a dynamic language you can run Python in the JVM or IronPython in the CLR. Then you can use a single runtime to call into Java or C# or Javascript or Ruby or VisualBasic. You can not do this with Perl 5, it is extremely unlikely that Perl 5 will every be supported outside of it's single C implementation. These limitations in the Perl 5 runtime are why your Perl community has been doing a from-scratch rewrite of Perl these last 7 years or so
mdfind, the command line interface to Spotlight, allows you to perform searches similar to locate only they are always up-to-date. It's also much faster than find. From 'man mdfind':
DESCRIPTION
The mdfind command consults the central metadata store and returns a list
of files that match the given metadata query. The query can be a string
or a query expression.
Very useful in conjuction with mdfind is mdls, which will display what attributes have been indexed for a given file.
It takes several orders of magnitude more work and money to upgrade a car engine. 12% is a very low number, I'm sure the same question for Windows 95 or Windows would have been very different, and it has also been very different for the last two releases of Mac OS X. In addition, if a new car engine ran slower, this would be considered a failure.
Co-op mode is making a bit of a come back with the new round of consoles all supporting internet play. Ghost Recon Advanced Warfighter, Perfect Dark Zero and Kameo on the XBox 360 all have a co-op mode.
I've played Full Auto quite a bit since it came out, perhaps 20 hours worth. Sure, the game lacks depth, but the core game play is really fun. Bombing through a city, clearing traffic with your rocket launcher and then turbo boosting off a jump and flipping end of over end as you fly 400 feet through the air to smash into a car dealership is really very satisfying.
The game feels like a set of Grand Theft Auto mini-games. Sure it feels like only 5% of a GTA game, but it feels like the first 5% of a next-gen GTA game :)
Podcast != MP3
Podcast == Audio(mp3 or aac or ogg) + XML (RSS)
The difference being that the podcast was automatically downloaded and synced to my iPod when I put it in the cradle last night.