More precision about the Haskell programming language..

[amin...@gmail.com]

Hello,


More precision about the Haskell programming language..


As you have noticed in my previous post i have just talked of the importance
of knowing the advantages and disadvantages of this or that programming language, for example Haskell has disadvantages, for example the only way to
implement fairness in Haskell is to abondon "composability", and
we know that for example fairness is an important characteristic that is needed by realtime Safety-critical systems, read more carefully here to notice it:

https://books.google.ca/books?id=wSkRAAAAQBAJ&pg=PA192&lpg=PA192&dq=fairness+and+haskell+and+stm&source=bl&ots=ow4i3rBcTG&sig=ACfU3U22X6q3zLmEeKOWHA3oHBMWBzqoQg&hl=en&sa=X&ved=2ahUKEwjHkKWC8OrnAhUplXIEHV9LACEQ6AEwBHoECAoQAQ#v=onepage&q=fairness%20and%20haskell%20and%20stm&f=false


And here is another disadvantage of Haskell:

Also 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 also 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 compose synchronization objects that use signals to signal the other processes or threads, but as you have noticed in my previous post that this can introduce circular dependencies among tasks waiting on this kind of synchronization objects
that use signals etc. and this can cause deadlocks, so then
Haskell is not immune to deadlocks.

Also there is another disadvantage in Haskell, read the following

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.