This article did not inform me a lot. Sadly for the first time in this course it did not bring about something that I did not already feel familiar with. It did make me reflect in the following way: Reminding me of how we call the programs that are not made in a functional style: imperative programming. This was like the times in which you ask a question as it's opposite, it's complement, and in doing that you get insights about the original question you were trying to answer.
Today I'd place programming languages on a spectrum that'd go from "closer to hardware but very fast" to "more abstract and powerful but harder to optimize". And that makes sense to me. I'd say that it makes sense to me that languages that are not as abstract and kind of force programmers to work more directly with the machine naturally produce faster programs that are closer to machine operations. We still have to express what we want to do very much in terms of the things that the machine does. On the contrary, more abstract and powerful programming wrap around the specific problems we're trying to solve much better, but the work of translating every possible abstraction into machine operations is hard. I'd agree in saying that functional programming is on the latter side. This article describes this situation. Even after listing all the promises of functional programming it mentions the optimization issues within the promises of concurrency and parallelism.
It was a very broad article compared to the previous blog materials we've had but I would say that I suffer that spectrum a lot. Just last week with all of the competitive programming I had to re-upload several problem solutions using C/C++ after Python programs using the same algorithm went over the execution time limits.
Today I'd place programming languages on a spectrum that'd go from "closer to hardware but very fast" to "more abstract and powerful but harder to optimize". And that makes sense to me. I'd say that it makes sense to me that languages that are not as abstract and kind of force programmers to work more directly with the machine naturally produce faster programs that are closer to machine operations. We still have to express what we want to do very much in terms of the things that the machine does. On the contrary, more abstract and powerful programming wrap around the specific problems we're trying to solve much better, but the work of translating every possible abstraction into machine operations is hard. I'd agree in saying that functional programming is on the latter side. This article describes this situation. Even after listing all the promises of functional programming it mentions the optimization issues within the promises of concurrency and parallelism.
It was a very broad article compared to the previous blog materials we've had but I would say that I suffer that spectrum a lot. Just last week with all of the competitive programming I had to re-upload several problem solutions using C/C++ after Python programs using the same algorithm went over the execution time limits.