Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
More about Haskell..
22 views
Skip to first unread message
amin...@gmail.com
Jan 24, 2020, 6:52:46 PM1/24/20
to
Hello,
More about Haskell..
I have just taken a look at Haskell, and i think
i am more capable and Haskell is easy for me to learn,
but to be more efficient, here is what i have just discovered:
take a look at the following about Mvars of Haskell:
http://neilmitchell.blogspot.com/2012/06/flavours-of-mvar_04.html
It is with this primitive of Haskell that we call Mvar that you construct
a higher level abstractions so that for example to make a FIFO queue that
is "energy" efficient, also it permits to use it to
be able to signal other processes or threads, but here again we have to talk
about the side-effects of it, because by using Mvar this way
you will be exposed to deadlocks or lost of signals. So i think that Haskell is not that good, so if you add the following weakness of Haskell, so this
tell me that i have not to waste my time with Haskell, read more:
Functional programming: A step backward
Unlike imperative code, functional code doesn’t map to simple language constructs. Rather, it maps to mathematical constructs.
We’ve gone from wiring to punch cards to assembler to macro assembler to C (a very fancy macro assembler) and on to higher-level languages that abstract away much of the old machine complexity. Each step has taken us a little closer to the scene in “Star Trek IV” where a baffled Mr. Scott tries to speak instructions into a mouse. After decades of progress in making programming languages easier for humans to read and understand, functional programming syntax turns back the clock.
Functional programming addresses the concurrency problem of state but often at a cost of human readability. Functional programmming may be entirely appropriate for many circumstances. Ironically, it might even help bring computer and human languages closer together indirectly through defining domain-specific languages. But its difficult syntax makes it an extremely poor fit for general-purpose application programming. Don’t jump on this bandwagon just yet — especially for risk-averse projects.
Read more here:
https://www.javaworld.com/article/2078610/functional-programming--a-step-backward.html
Thank you,
Amine Moulay Ramdane.
More about Haskell..
I have just taken a look at Haskell, and i think
i am more capable and Haskell is easy for me to learn,
but to be more efficient, here is what i have just discovered:
take a look at the following about Mvars of Haskell:
http://neilmitchell.blogspot.com/2012/06/flavours-of-mvar_04.html
It is with this primitive of Haskell that we call Mvar that you construct
a higher level abstractions so that for example to make a FIFO queue that
is "energy" efficient, also it permits to use it to
be able to signal other processes or threads, but here again we have to talk
about the side-effects of it, because by using Mvar this way
you will be exposed to deadlocks or lost of signals. So i think that Haskell is not that good, so if you add the following weakness of Haskell, so this
tell me that i have not to waste my time with Haskell, read more:
Functional programming: A step backward
Unlike imperative code, functional code doesn’t map to simple language constructs. Rather, it maps to mathematical constructs.
We’ve gone from wiring to punch cards to assembler to macro assembler to C (a very fancy macro assembler) and on to higher-level languages that abstract away much of the old machine complexity. Each step has taken us a little closer to the scene in “Star Trek IV” where a baffled Mr. Scott tries to speak instructions into a mouse. After decades of progress in making programming languages easier for humans to read and understand, functional programming syntax turns back the clock.
Functional programming addresses the concurrency problem of state but often at a cost of human readability. Functional programmming may be entirely appropriate for many circumstances. Ironically, it might even help bring computer and human languages closer together indirectly through defining domain-specific languages. But its difficult syntax makes it an extremely poor fit for general-purpose application programming. Don’t jump on this bandwagon just yet — especially for risk-averse projects.
Read more here:
https://www.javaworld.com/article/2078610/functional-programming--a-step-backward.html
Thank you,
Amine Moulay Ramdane.
0 new messages