¿Cuáles son algunos ejemplos de elegir Haskell para un proyecto que resulta ser una muy mala decisión?

No se de ninguno. Todos los que he preguntado sobre esto han dicho que Haskell fue una gran decisión. Mi tamaño de muestra es de aproximadamente 15. Obviamente, todo es anecdótico, y a menudo es un esfuerzo tan grande presentar a Haskell en una compañía que solo las personas que ya aman el idioma lo tomarán. Entonces, la tasa de satisfacción del 100%, aunque significativa, no proviene de nada parecido a un estudio controlado.

Una gran cosa que diré para los programadores de Haskell (a diferencia de ciertas otras comunidades lingüísticas) es que tienen un sentido maduro de las debilidades del lenguaje, que son pocas pero existen, y lo impiden en ciertos espacios problemáticos (p. Ej. comercio de baja latencia, donde no puede permitirse la recolección de basura). Es poco probable que usen Haskell cuando es inapropiado. Las partes que realmente necesitan estar en otro idioma, se escribirán en ese otro idioma, pero Haskell será su herramienta predeterminada para el 99% de los problemas en los que funcionará cualquier lenguaje razonablemente eficaz.

Sé de una compañía que se mudó de Haskell, que estaba usando en producción ya en 2006 (cuando Haskell estaba mucho menos “preparada para la producción” de lo que está ahora, y tuvieron que escribir muchas bibliotecas internas) . Fue una confluencia de dos factores. Una es que un par de sus ingenieros superiores de Haskell se fueron. El otro es que Microsoft fue uno de sus grandes clientes y usó su poder como cliente para presionarlos a usar F # (que no es un mal lenguaje) para que pudieran afirmar que los productos de Microsoft estaban en uso en . Cuando las empresas que usan Haskell se alejan de él, generalmente no es porque el lenguaje “falló”. Es el resultado de perder el talento de alto nivel antes de que el idioma esté bien establecido, o un factor extraño fuera de banda que no tiene nada que ver con Haskell.

Solo hay un puñado (literalmente) de empresas en el mundo que han diseñado sistemas industriales a gran escala en Haskell. La mayoría solo hace componentes pequeños como parte de un sistema más grande. Esto significa que muy pocos fallaron al intentarlo.

De los pocos que fallaron, es poco probable que alguno de ellos haya alcanzado la escala para poder culpar a Haskell. Por lo tanto, es muy poco probable que encuentre algún ejemplo.

Scrive, la compañía que fundé, es uno de los pocos que construyó todo nuestro sistema en Haskell. Llevamos 4.5 años y todavía no hay signos de fracaso debido a Haskell. En realidad, hemos encontrado todo lo contrario, percibimos a Haskell como nuestra arma secreta porque:

• La demanda de trabajo es mucho mayor que la oferta, por lo tanto, tenemos un flujo constante de desarrolladores altamente competentes que solicitan un trabajo y también podemos mantener los salarios a niveles más razonables porque podemos ofrecer algo único a cambio: experiencia de desarrollo Haskell a escala industrial
• Haskell es difícil de lograr y tiene una curva de aprendizaje empinada, alguien que sabe que Haskell está seguro de estar más interesado en la programación y más inteligente que el desarrollador promedio, esto elimina los peores casos de nuestro proceso de reclutamiento
• El hecho de que hagamos Haskell nos permite ganar grandes desarrolladores en competencia con los competidores más publicitados.

En realidad, me gustaría afirmar que Scrive es exactamente lo contrario de lo que estás buscando. Somos un ejemplo de una empresa que lo hizo gracias a Haskell. Fue Haskell quien nos consiguió nuestros primeros desarrolladores que querían ayudar a pesar de que no teníamos dinero para pagar. Sin Haskell no habría habido ningún producto para vender y nada que presumir para recaudar dinero y atraer clientes.

Le debo mucho a Haskell. Fue una decisión loca en el momento en que comenzamos, pero en retrospectiva, fue uno de los mejores movimientos que hemos hecho.

Pusher implementó su bus de mensajes en Haskell y luego tuvo que reescribir en Go porque el GC de Haskell causó demasiada latencia.

Hay una excelente redacción que se puede encontrar aquí:

Baja latencia, gran conjunto de trabajo y recolector de basura de GHC: elija dos de tres

GC en tiempo real de Golang en teoría y práctica

Lo importante de esto no es que Haskell sea malo en lugar de que no sea adecuado para aplicaciones donde la latencia muy baja es esencial. Me imagino que lo mismo sería cierto para el GC de Java también.

En CUFP 2013, GREE habló sobre su experiencia en la construcción de algunos servicios utilizando Haskell [1]. Presentaron los problemas que encontraron, incluida una pérdida de memoria que resultó de una evaluación diferida que dificultaba predecir el comportamiento en tiempo de ejecución. He visto informes similares de otros usuarios comerciales de Haskell y me ha llevado a la conclusión de que personalmente preferiría implementar servicios de producción escritos en lenguajes funcionales con escritura estática que usen una evaluación estricta por defecto.

[1] http://cufp.org/2013/yasuaki-tak

Han pasado años desde que estaba en un campus universitario, pero no puedo pensar en una buena razón para usar Haskell …
Fuera de los entornos de aplicaciones especializadas donde es más adecuado, Haskell (GCH) requiere una buena capacitación y educación para dominarlo, lo que hace que su mantenimiento sea costoso. La portabilidad sería una preocupación para cualquier aplicación destinada para uso comercial. Siempre me pareció más un ejercicio académico que un producto del mundo real.
Descargo de responsabilidad: todo lo que he hecho es tocar el violín; Tengo una serie estándar de tareas que uso por defecto cuando intento algo nuevo: mi propia versión pequeña de Hello World.