pylkko wrote:For example, in pure python, without importing external libraries you can use dictionaries to store data when it suites that format.
Yes, it is much more efficient to use dictionaries. Using classes for storing data, however, is more flexible. Even more so with the recently added "data classes". As I have written above, I use classes the same way structs are used in c. What I don't use them for, is "Object Oriented Programming".
pylkko wrote:So, if you use a library which "hides" the technical detail from the user/coder... using such a thing is not "cheating" and being dumb, if you take the time to figure out what it is doing under the hood. The same thing also happens with the "pure" elements of your language. Many times looking up how the "basic elements" actually do stuff can also help you design your own software better.
I very much agree that using 3rd party libs is not cheating in any way. Python is designed to be modular, after all. Developers are even discussing stripping some modules from the stdlib, since almost everyone uses pip these days to install their favorite "do it all" library.
What I object to is the learning curve that is neaded to learn to be efficient with those 3rd party libs. In contrast, here are all of the standard library modules, together with the documentation:
https://docs.python.org/3/py-modindex.html
And this, too:
https://docs.python.org/3/library/
pylkko wrote: I think that if you asked why people use these paradigms in software design, they would cite a lot of reasons that have never been "empirically tested" to be true/not. For example, it is claimed that this kind of code is more safe (because things like encapsulation help design safe code) or that it is "more productive" (because it is intuitive of a way for people to think and maximizes code reuse).
Functions can also be reused. That's the major reason we write functions. Classes are intuitive because they represent real-life objects in a way. However, the functionality of those objects is often not applicable to software world, thus you throw that intuition in the air and confuse everyone. In Python, calling methods is slower than functions, which can ironically impact large-scale projects that classes are designed for.
pylkko wrote: I have always wondered a lot about how much superstition there appears to be amongst code developers.
A LOT. I am no expert in STEM or a scientist or anything such. I'm just a normal guy who liked software and computers ever since I was a kid.
pylkko wrote:In many respects julia is like python, but it has way better performance, at times better than c and fortran code. However, since it reached 1.0 last year, the ecosystem is not as developed as in Python, though I am really expecting it to grow. It is not object-oriented, although it does have some similar properties, like multiple-dispatch (that you can have multiple versions of the same function with identical name, so that when you call that function it does different things with different data or whatever). It is also not interpreted but just-in-time compiled, although you do have a shell like in Python for interactive use. Almost all of the source code is in julia itself, which is makes it a lot easier to modify on all levels.
I hope that it takes off, it sounds like julia is improved Python in every way. I guess it is now popular to write would be replacements to popular languages. We have Rust and Go for c++/c, now I hear about julia for Python. New ideas for the new generations of software developers.