131–140 of 152 posts
Earlier quoted context omitted.
Makes literally no sense. The c developer would simply use the same c/fortran library the python implementation is based on. You are creating a false dichotomy for the sake of it.
The c developer should use the same c/fortran library that the python implementation is based on. A good C developer would use that library. In my experience, mediocre C developers will not use that library and will implement their own, naive version.
Earlier quoted context omitted.
> but the complexity of C++ is troubling. It's a multipurpose, statically compiled and standardized language. I don't think its complexity is a problem. Simplicity in a industrial level language like C++ can't really be expected. I'd say C++ is a for a multitude of uses, it allows to do things precisely and well, but it has a cost, the one of learning how to use it. 1) There are many other alternatives than C++ that…
C++ isn't evolving; it's just accumulating features. That's a crucial difference. The amount of harmful patterns you can accidentally use just keep on strictly increasing.
Earlier quoted context omitted.
> but the complexity of C++ is troubling. It's a multipurpose, statically compiled and standardized language. I don't think its complexity is a problem. Simplicity in a industrial level language like C++ can't really be expected. I'd say C++ is a for a multitude of uses, it allows to do things precisely and well, but it has a cost, the one of learning how to use it. 1) There are many other alternatives than C++ that…
Maybe the language will be a little easier to use in the future. this is always double with C++. At one point, it most definitely is easier to use now already than pre-C++14 or 11. Lots of those additions really make me enjoy using it (even more:) and often lead to less code which does the same while still not being harder to understand (often even better to understand) and having the same performance. However, becau…
Earlier quoted context omitted.
Maybe the language will be a little easier to use in the future. this is always double with C++. At one point, it most definitely is easier to use now already than pre-C++14 or 11. Lots of those additions really make me enjoy using it (even more:) and often lead to less code which does the same while still not being harder to understand (often even better to understand) and having the same performance. However, becau…
Couldn't these things just be deprecated? As in, never removed because of compatibility, but when compiling you would get warnings about using features no longer 'best practices', and maybe there could be a switch for 'modern c++' that would turn use of these features in errors?
Earlier quoted context omitted.
I think the argument isn't that Python code out performs C code, it's that code written by mediocre Python programmers often outperforms code written by mediocre C programmers. C code is fast enough the mediocre programmers get used to letting the language bail them out. Python programmers know that their language is slow and that they have to work around it. I've encountered this several times in my own career. A co…
Makes literally no sense. The c developer would simply use the same c/fortran library the python implementation is based on. You are creating a false dichotomy for the sake of it.
Earlier quoted context omitted.
Everything else isn't too slow, though, especially if you hit any meaningful IO.
Or if you use clever algorithms. I don't have benchmarks at hand, but I suspect that an FFT in Python is faster than a naive Fourier transform in C.
Earlier quoted context omitted.
Everything else isn't too slow, though, especially if you hit any meaningful IO.
There are many applications that either aren't typically IO bound, or where the IO (eg. gpu memory) is fast enough that you'll likely need C++ to maximise performance. Writing software that pushes bleeding edge hardware is fun, which is why many people still want to learn C++.
Earlier quoted context omitted.
take your unfounded bias elsewhere
It's called "observation", not "bias".
I also enjoy using "double quotes"
Earlier quoted context omitted.
> `const` is only needed for the caller to ensure that the object won't get changed when passed to another function. But const cannot guarantee this, because it can be cast away so easily. This could be true just for your own code, but then it is you who is responsible for maintaining the immutability, not the compiler.
> because it can be cast away so easily By this logic, none of the static type checks in C++ is of any use, since they can be cast away easily as well.