Python and Ruby are extremely malleable, like Smalltalk and lisp before them. You can inspect anything, you can override / replace / proxy anything. You can use a few built-in collection types for nearly anything.
This is by design. This is great for prototyping.
These languages are to programming what breadboards and wires are for electronics.
Of course, as your system grows, you start to want static checks, or having your schematics on a PCB. But at the very start, tweaking a piece of Python code, or a breadboard, is easiest. Then, of course, you may not want to afford a a rewrite to rust, or would put your breadboard in a box and ship it :)
>Of course, as your system grows, you start to want static checks
I've been working on large scale python systems for about 10 years. For me, the most cost effective checks as a system grew have been asserts.
They allow extremely sophisticated pre/post condition checking (partly helped by pythons flexibility), they're cheap to write, they don't take up much space, they catch a shit ton of bugs, they clearly highlight the source of the bug, they work together really well with higher level tests and I've almost never had them trigger in prod (so the fact that they technically could, as static type fans keep reminding me, doesn't really bother me).
For me, asserts and integration tests are what make large scale python systems a pleasure to write.
Funny; I'm a Lisp programmer, not to mention implementor, but whenever I do electronics, even something simple, I go straight to PCB. I can make those things at home with a quick turnaround time. I prefer manipulating traces in the PCB routing program than messing around with flaky wire connections on a breadboard. If it's worth doing, it's worth doing well. After I made my first PCB, there was no going back. I'm confident my circuits will work because I calculate and simulate; and in any case, usually even if the circuit won't work initially, the printed circuit topology will, modulo adjustment of component values. You can anticipate experimentation in a printed circuit, too.
My experience with writing prototypes in Python is that one week later I have difficulties understanding it and one year later (yeah "temporary, my ass" kind of thing) it's completely alien to me.
It's absolutely not the same with OCaml, F# and lately, TypeScript. And I don't think I write the prototype in more time in this languages (if we are talking about something that takes up days, not minutes, of course). But the experience some months down the road is completely different.
This is by design. This is great for prototyping.
These languages are to programming what breadboards and wires are for electronics.
Of course, as your system grows, you start to want static checks, or having your schematics on a PCB. But at the very start, tweaking a piece of Python code, or a breadboard, is easiest. Then, of course, you may not want to afford a a rewrite to rust, or would put your breadboard in a box and ship it :)