Lambda the Ultimate

"it's just a Lisp in infix clothes"

and without proper tail-recursion, macros and a definite taste for imperative loops.

but yes, a sweet language with good libs. not unlike ruby btw.

All languages are just Lisp in infix clothes... except for Ruby, which is a procedurally camoflaged Smalltalk (which is a Lisp in message-passing clothes). Oh yeah, some of them have type checkers thrown in, too :-).

How to implement a fast interpreter

Implementing a fast interpreter or compiler for Python is not at all trivial. I realize your experience is limited to writing glorified Forth interpreters, so this might come as a shock to you.

How to implement real garbage collection without refcounting

CPython has had a mark-and-sweep GC for a long time now. Reference counting is still used but there is nothing "un-real" about it since the GC takes care of collecting cycles.

Implementing a fast interpreter or compiler for Python is not at all trivial.

I think that was part of the point. The language design of Python is such that it becomes very difficult to make it speedy. The Psyco guys did a very admirable job, they had to jump through hoops to do it.

Granted, Python didn't have speed as a design goal in the first place. And for the vast majority of programs, that seems to be perfectly fine.

All other things being equal, the more perfomant solution is preferrable. Thus, you really need to spend some time proving in an objective manner that the cuts in performance are justified. (In my opinion, they are not.)

Especially divorced from a specific context? And why is the burden of proof on the other party; whereas you offer only your opinion?

Whether or not something is "fast enough" is generally an engineering/design question, not a scientific question. One cannot claim that Python is, or is not, "fast enough", or that the performance issues with it is "justified" or not, without considering what it's being used for.

Is Python fast enough to implement the Quake graphics engine on a mid-range PC with a bare-bones graphics chip? No, it's probably not. Given a suitably souped-up futuristic machine, OTOH, maybe.

Is Python fast enough to implement glue code between a HTTP server (ie apache) and an RDBMS (ie MySql) running on stock server hardware? Much practical experience says yes, it is. OTOH, were you to replace the stock 2005 server hardware with a PC of ten years vintage; the whole system would suck--the overhead of Python probably would no longer be acceptable given those constraints.

Neither observation is Not "proof"; but the question you pose isn't testable/proveable without extensive qualification.

Guess where Python is routinely deployed?

Similar analyses should apply to other aspects of software quality; namely correctness, security, reliability, robustness, fitness-for-purpose, extensibility, scalability, expressiveness, and such. Is proof by formal method an appropriate design technique for a mission-critical app like a heart monitor? Certainly. For a crud screen? 'Twould be a waste of time and money.

...is keeping a certain "conceptual barrier" between the abstract computational model and technical implementation details of compiler writing.

There should be no reason why compiler internals should influence our language spec.

There should be no reason why compiler internals should influence our language spec.

Yeah, well, but there are reasons.

That's an absolutist position; much like "there should be no reason why a database should ever be denormalized", or "there should be no reason why a type test should occur at runtime", or "there should be no reason why a visible side effect should be allowed".

While all four (counting yours) are good statements of principle (though all of them are likely to be the subject of debate), it is exceedingly difficult to construct practical, useful, useable, non-trivial systems which follow all (or any) of those rules religiously. I'm sure it's been done, but it's difficult.

For the record, I support all three of the other statements you made. :)

All other things being equal...

yes, thankfully, a C++ solution most definetely is not the same as a Python one, so merely choosing the "performant" solution is not always a good deal...

I'm a dogmatic Python coder, too. :)

"How to implement real garbage collection without refcounting"

Python's refcounting is a feature. Destructors are actually useful in Python, and I appreciate not being required to manually close files.

Anyway, the semantics of Python may be lacking in some ways, but it has a good mix of useful features that work well together, and that's what's desired for a language of its kind.

A good paper to read about finalization vs. destructors is this one.

Sorry, I had listened to the talk earlier, but I didn't remember that he covered reference counting. I skimmed it again, but the only part I could find on reference counting was about 7 minutes into the second part, and he didn't mention destructors or finalizers there, so I'm not sure if I understand what you're saying. Do you mean that I used the term "destructor" incorrectly?

No. I simply wnated to let others know that Guido talks about "real" gc versus ref-counting. It's one of the explanations he gives as to why Java produces more out of memory errors..

Thanks for the clarification and the interesting link.