Chandler finally reaches a 1.0 release

Speed, certainly, resources hardly.

There are solutions on the horizon to get Python execution speed comparable to C or C++. Have
a look at the PyPy and LLVM projects.

> Yes, but Python also suffers from a 10-fold disadvantage in speed and resource usage, even
when the algorithms are identical. 


Quite frankly that irrelevant. It really is. It doesn't seem like it at first, but it is. 

Why?

Because the vast majority of a program isn't speed sensitive in any sense of the world. Only a
small amount of most programs consume the vast majority of resources the program uses.  And
because of the nature of programming it's often very difficult to determine which parts of the
programs are going to be the troublesome part.

(Now, of course, the following does not trump good programming design or performance oriented
thinking.. in fact it augments it.)

So when you program in python and you reach a point in your program which performance becomes
a serious issue, so that figuring out better algorithms in python isn't going to get you
better performance, then you have to hunker down and rewrite the troublesome parts in C and
import it back into your program as modules. 

And, since, there is a number of different ways to do this that makes it easier then it used
to be.. Such as programming in python-C hybrid languages like Cython or Python.. AND you've
already done the hard work of designing better algorithms in a higher level language then
you'll likely end up with better performing code then if you started off programming in C in
the first place.

That is the key to having very complex python applications that perform very complex things is
to not program everything in python.

Python isn't like Java were everything needs to be java-this or java-that. It's quite happy
integrating with other languages. So you use what is appropriate.


--------------------------------------

A case in point:

Git is a example of a program that uses lots of high level languages and is very good
performing. It does not use any python, but it does use a large amount of Perl and bash shell
code. 

Given that Perl is slow, and shell scripting is not only extremely slow.. it is very very
limited in what it can do, then that means that Git should be very slow and limited, right? 

Well no. Of course not. 

Git not only is faster, it's magnitudes faster most any other RCS (for the features that the
designers care about). Many that have been written in C++ and don't use any shell or perl. And
they've done that in less time and effort then what other RCS have benefited from.

--------------------------------------

Given infinite amount of time, skill, and resources C++ will always be a better choice then
Python. No question about it.

And given infinite amount of time, skill, and resources C will always be better then C++, and
in turn Assembly will always be better then C. 

(since C was originally written in assembly, and C++ was written in C, then nothing that is
done in C++ can't be done in C, and nothing that can be done in C can't be done in assembly.
And, of course, the reverse is not true.. Assembly can do things that can't be done in C, and
C can do things that can't be done in C++.)

None of us have infinite resources and infinite skill.

----------------------------------------


The theory is that using high-level language isn't going to just allow you to crank out more
code quicker. The theory is that it allows you to crank out _better_quality_ code more
quickly.  (But I can't tell you for certain that is true. I just don't have that much
experience.)

It is not a crutch for lack of skill, like many people treat it. In fact you still have to be
very aware of everything from the hardware on up if you want to have quality software.

What I can say is that I've used plenty of python things that were faster then plenty of C++
things, even though that's usually not the case. Generally they crash much less and don't have
memory leaks, which is usually the case.

*shrug*

Sometimes it helps to think aloud (write) before I realise such things.

Indeed, this behaviour is interesting.

My first guess:

* it's not usual to delete some thing.

More usual:

* change the nature of the thing.

Changing its nature may be:

* triage to: done
* triage to: later
* add to calendar, or remove from calendar.

Let's rewind.

Q: Why did you create the item? (If it wasn't a note, task, event, whatever, then what was it?)

The question of most relevance:

Q: Why did you immediately delete it?