if they used static types it would be 100%

statically typed languages are to be seen as safer than their dynamic counterparts. While this might be true when comparing with many dynamic languages, Erlang begs to differ and certainly has a track record to prove it. The best example is the often reported nine nines (99.9999999%) of availability offered on the Ericsson AXD 301 ATM switches, consisting of over 1 million lines of Erlang code

Whom are you quoting?

Although we have completed only basic analysis, here are some of our first findings -- those so clear that they show up on even the most basic examination of the aggregate data.

- Satisfaction with the language, the compiler, and the community are high.
- Among non-students, 58% would recommend Haskell for a project at their workplace, but only 26% actually use it at work -- partly due to colleagues unfamiliar with Haskell who see it as requiring skills that are hard to obtain, or who need to see more success stories. Would improvement to colleagues' perceptions make a difference in the team's choice of Haskell for a project? 33% of respondents rated this "crucial" and another 26% said it would be "important", while only 16% said it would be a "slight help" or no help.
- Package management with cabal is the single worst aspect of using Haskell. Asked if improvements to package management would make a difference to their future choice of Haskell for a project, 38% said it would be "crucial" and a further 29% said it would be "important". Comments connected cabal with words like hell, pain, awful, sucks, frustrating, and hideous. Only this topic showed such grave dissatisfaction.
- Documentation improvements are a very high priority. For example, users need more concrete tutorials and templates showing them exactly what kinds of problems Haskell is good at solving, and exactly how to implement such programs completely. 65% of respondents said improvements to documentation and learning resources would be crucial or important, and a further 23% said they would be helpful. However, comments did not begin to approach the level of concern seen with cabal.
- Skills are a priority. Users need to see that people with Haskell skills are readily available, and that Haskell skills are quite feasible to learn. A majority of respondents said an improvement in availability of skilled personnel would make an important or crucial difference to them, and many also expressed concern about their or colleagues' abilities to learn the needed concepts and skills.

Source: https://www.fpcomplete.com/blog/2015/05/thousand-user-haskell-survey

i consider static typing cute, like scheme .. and totally useless for real world. kinda like walking barefoot. that should be what everyone does, it is healthier, but then you have people who are busy farming and what not to make you food, and put rocks on the road which sucks to walk on.
i'm the farmer, you're the person in the rocking chair complaining about blisters.

>>4
Static typing is absolutely indisposable in the real world, in fact that's the main reason to use it.

Statically typed systems can't grow or change.
Think about the classic OO examples like Person. A dynamically typed Person can learn how to play the piano. If it's statically typed, that's impossible.
This is the same reason why pure functional programming sucks.

>>3
I'd expect someone who jacks off to category theory at his job to have completed a little more than just basic analysis.

>>7
They haven't published yet because they're too busy wanking.

The only reason to use static typing is because manager force you, otherwise you'll lose your job. People using static types are the same people who sell their gay ass for money. In other words, static typing practicians are faggots.

>>6
If I want my person to play the piano, I'll teach that person to play the piano. I don't want my person to play the piano until I explicitly teach it.

NO.

Which is better for starting flamewars, strong vs weak, or static vs dynamic?

>>12
systemd or init or openrc or whatever have you

emacs vs vi