Map, filter, and fold are higher order functions, functions which take functions as parameters.
You are misusing the word callback. A callback is a function passed to another thread that will maybe be invoked later as a response (like it calls you back).
In contrast, Lodash goes out of its way not to use the term "callback", presumably to avoid confusion since it's a place where many functions-that-take-a-function-argument do not call the provided function, e.g. https://lodash.com/docs/#curry
Regulation doesn’t mean it would be safer, just more bureaucratic. There are plenty of examples in the US of regulators failing to properly regulate like in Flint. Adding these regulations often benefits the capitalists more, as it raises the barrier of entry for smaller competitors and makes the market less competitive in the long run.
They don’t have to be glorified for loops, even if they usually are. Map and Filter should be capable of running in parallel or asynchronously, and some languages provide this.
And many languages, have parallel for constructs. The openmp #pragma parallel extensions in C/C++ for example. Of course its possible to create constructs which provide the messages passing for clustered environments too.
And maybe that is part of the problem with a generic 'map' your not really sure the underlying implementation, is it parallel, clustered, serial, etc? So you end up with map(), parallel_map(), mpi_map(), etc, and how to you control the parallelism. Do you just let it default or do you have levers to control the batch & interleave. Pretty soon, its not such a simple construct anymore.
C++ is not a narrow niche. We do see it pretty much everywhere and it continues to be the most used language for systems programming, games, embedded systems, and pretty much anything else where performance is critical.
That is a niche, because most applications are IO bound and not compute bound. What even qualifies as “systems programming” is ill defined. Far more critical business systems run on Java and C# servers than C++. If there are C++ components they tend to be small parts along the critical path and not the primary implementation language.
"most applications are IO bound" - there is a whole world of not IO bound software running on cars, toasters, airplanes, desktops, hospital equipment etc etc. I do not think it is any smaller then that niche of web spaghetti being churned out by undergrads
I disagree with the notion that most applications are IO bound only. This is something people often say uncritically, but in my experience is false. Just using a non-native Electron or even Java application feels very sluggish and when you look at the Waterfall on slow web pages, what's slowing it down is very often unrelated to "I/O".
Secondly, C/C++ is like the third or fourth most commonly listed programming language in job listings. If you think all but 2 or 3 languages are niche, that is not what the word means.
C/C++ is not a language. I am also someone who has use C and C++ for years as part of my work and have mostly moved on to TypeScript because there isn’t much reason to use C or C++ anymore unless you are in one of those niches where you need to still program at that level.
Most software problems are not about solving them faster, it’s about combining existing components in new ways and figuring out to orchestrate it all.
I don’t care about copy elision, heap fragmentation, perfect forwarding, when my performance is being lost in the communication between services. What I need is a better architecture and more scaling, not concerning myself with if this loop is being vectorized, or that object is being moved instead of copied, and other minutia which inevitably ends up wasting your time when writing C++.
I don't necessarily disagree that not everything needs to be optimized for performance, but I would just argue that the use cases for Typescript are far more niche than the use cases for C++. There's more to software than just web stuff
Most stuff is web stuff now. And I’m not talking about front end, we do a lot of back end work in TypeScript because node is lighter than the JVM which makes it a better choice for lambdas. I’d say it also has more sophisticated static typing than Java or C++, while also allowing dynamic typing in the few cases where it is convenient. Having the front and back end written in the same language also reduces impedance between teams. A lot of our tooling is even written in it now, deprecating many Ruby scripts.
Most stuff is not web now. There is software in everything everywhere not just web sites.
Niche does not mean "stuff I don't personally use at my job", but that is the only definition under which Typecript is not niche and c++ is. C++ in 2019 had the 4th most job listings according to Indeed. Calling that a niche is absurd especially in comparison to Typescript.
The thing about C++ is that you need to recruit specifically for C++ programmers in a way that you don’t need to recruit for programmers in many other languages. The barrier of entry for C++ is high enough that you can’t just take your typical developer and ask them to write good C++, it’s a language which requires far more effort to become competent in.
There are also many places which just ask for Java/C++ experience for no apparent reason. Amazon is like this, all of their job listings mention C++ but only a very small percentage of the code base is in C++. There is at least 10 times as much Ruby code and it is part of systems that most engineers will have to work with, but no job application mentions that.
Java killed it for general purpose use in the 90s. It’s never your first option unless you are in areas like games, graphics, some embedded work, or quantitative trading.
"All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?"
Python has become less functional over time. It’s also not a particularly good OO language either. It’s really a more descriptive sort of bash that became ubiquitous despite its short comings.
Nesting functions like this can have a bad performance impact because functions in Python are objects. Normally, all of those function objects are instantiated once when you load the module. However nested functions will be instantiated at runtime every time their parent is called, even if they aren’t used. This cost is perceptible in hot paths.
Optimizing compilers are good at optimizing obvious code, so this usually isn’t a trade off. Many of the clever hacks you can find in books from the 80s are irrelevant now because the compiler can figure out what your naive code is doing and emit something optimized.
Modern processors don’t even operate sequentially and will execute multiple lines in parallel when there are no data dependencies.
For most code, the performance killer is when you try to be too clever or have too many pointer indirections. The compiler has a harder time with this, and is also precluded from applying other optimizations like auto vectorization, because it cannot figure out if it would change the meaning of your code.
For true performance, you need to enter the land of intrinsics, manual vectorization, and cache-aware algorithms. Domains which very few engineers are qualified to work on.
So just keep it simple and trust the compiler. This also applies to algorithms, complicated ones with lots of branching will often perform far far worse in practice than the naive one, you can’t trust the big-O alone. So profile when in doubt.
> So just keep it simple and trust the compiler. This also applies to algorithms, complicated ones with lots of branching will often perform far far worse in practice than the naive one, you can’t trust the big-O alone. So profile when in doubt.
I've found that optimizing for cache is usually the biggest gain when trying to be clever with algorithms.
Eliminating branches and being naive in the algorithm itself is usually a better idea than trying to be clever with special cases.
This is false. Integer division by zero is undefined, but floating point division is perfectly fine. Many languages have different operators to distinguish floating point and integer division, like pythons / for floats and // for integers.
Yeah it's an interesting case. It appears that Inf is in floating point to AVOID a trapped error.
This answer has an interesting way of looking at it. If you go on the theory that floating points are supposed to represent reals, then in floating point, you can't tell if a value is actually zero or just indistinguishably close to zero.
In the case of "indistinguishably close to zero", you're getting the wrong answer, and the program doesn't halt. It keeps on chugging doing bad math. So that's an untrapped error, and it's UNSAFE by Cardelli's definition.
Floats aren’t reals, at best they are an approximation for certain calculations. +0 and -0 are defined and distinct floating point numbers. Floating point math is known to be problematic and does not evenly distribute numbers on the real line either. There are numerical methods used for reducing error on floating point operations when it is acceptable. Otherwise fixed point or intervals may be used.
You are misusing the word callback. A callback is a function passed to another thread that will maybe be invoked later as a response (like it calls you back).