[SFJulie]

Well, C/Fortran/C++/ASM are a PITA when it comes to dynamic structures like the one for handling configurations.

Plus authors missed that boxing in python has a tendency to fragment data in a non controlable way in the memory thus making the use of L1/L2/L3/mem (on x86) or other memory architecture with similar layout very hard to use.

If you code often you know the 80/20 rule: 80% of your code is the setup preparing for the 20% of heavy lifting.

Numpy (which relies on Fortran) is a nice Proof that when done correctly python is really useful.

A computing a Moving average in pure python is 10 000 times slower than using numpy (especially if you use FFT).

So ... I am saying since python (like Tcl or Perl) is a good language for doing FFI (foreign function integration) it should be used this way.

And thanks to the often unfairly hated GIL it enables to use un-thread safe foreign language library in a thread safe way.

All being said and done, if python used this way is slow, I dare say it is because some coders do not understand how to build there data/execution flow. And this is not language dependent, but a question of coder.

I thought they were 10x coders in the past.

I recently realized there are /10 coders in fact.

The one that are pissed at coding when «it does not work the way it should» and expect language to be magically doing most of the job without learning.

The 1x coders on the other hands are boring, slow coders and accept that when the «stuff» is not behaving the right way, it may not be the stuff that is not working, but him/her that have a misconception.

1x coder is not a state, it is a trajectory that can degrade or improve with new challenge and poor/good state of mind, hence the misconception on 10x.

[lokedhs]

It is possible to make a dynamic language natively compiled and very fast. Common Lisp is arguably even more dynamic than Python, and SBCL manages to generate code that rivals C in performance.

[PeCaN]

I don't consider Common Lisp “more dynamic” than Python; at least in that you modify code at runtime and such. Frequently Common Lisp code is not particularly dynamic, because you can get the same level of expressiveness without relying on mucking around with magic at runtime.

Also SBCL only generates really fast code if you use a lot of type hints and (optimize (speed 3) (safety 0)). That said, when you do, it's really fast.

[lispm]

Typically Common Lisp and its implementations provides a wide range of performance options. It's not limited to the model of some more primitive language runtimes, which provide only two modes (simplified): slow if implemented in the language, fast if it runs mostly in its runtime and library functions written in C. There are Common Lisp implementations which follow this model, too. But there are also many which have sophisticated runtimes with optimizing native code compilers.

To get to really fast code in Common Lisp one needs to write relatively low-level code with type declarations, optimization hints, low-level operators etc.

There is a part of Common Lisp which is as dynamic (more?) as Python: everything written in CLOS (multi-dispatch, multi-methods, method-combinations, ...) and expecially when using the CLOS MOP. Is it slower or faster than comparable Python code? I have no idea and I haven't seen any interesting benchmarks. The amount of CLOS use depends on the implementations. Some implementations have a lot of their library code and also much of the language itself (everything IO, error handling, ...) written using CLOS.

[lokedhs]

I have written plenty of heavily CLOS-based code that is still very fast. I doubt that Python could come close in performance.

I think it would be an interesting exercise to do some benchmarks to get some actual data behind both of our guesses.

As I am not a very experienced Python developer, would you be interested in writing some test code that is representative of typical Python code, and I'd be happy to port it over to CLOS and so that we can run some benchmarks?

I think such results would be of interest to the HN audience.

[SFJulie]

Well, whatever the problem is, setting up the processing, parsing input files, checking inputs might not need to be fast but much more secure and user friendly.

This -at my experience- often requires very «dynamic» structures in the form of intricated hash table/dict that requires to be correctly set, malloced, modified. JSON like stuff.

You may do it safely in python/perl/php/tcl way more than handling your memory in C/C++/ASM. It is easier, more error prone, and faster. And no real speed is required.

Sometimes what we search is the right tool for the right problem.

Setting up a software is often a big part of the code that consume a lot of lines of code, while often a small part of the execution time. And the priority is often on correctly handling/checking the input without buffer overflow/undefined behaviour much more than speed.

So I totally think that the idea of using the right tools for the jobs is a good idea. Imagining one language can do all, is pure religion.

I wouldn't even be surprised that one day we have a description language used only for setting up and distributing messages à la VHDL instead of trying to "integrate it" either in the OS with "dynamic buses" or with "runtimes".