Las trampas del mundo real de introducir F # en una gran base de código y equipo de ingeniería [cerrado]

Soy CTO de una empresa de software con una gran base de código existente (todo C #) y un equipo de ingeniería considerable. Puedo ver cómo ciertas partes del código serían mucho más fáciles de escribir en F #, lo que resultaría en un tiempo de desarrollo más rápido, menos errores, implementaciones paralelas más fáciles, etc., básicamente ganancias de productividad general para mi equipo. Sin embargo, también puedo ver varias dificultades de productividad al introducir F #, a saber:

1) Todos tienen que aprender F #, y no es tan trivial como cambiar de, por ejemplo, Java a C #. Los miembros del equipo que no hayan aprendido F # no podrán trabajar en partes F # de la base de código.

2) El grupo de programadores F # contratables, a partir de ahora (diciembre de 2010) no existe. Busque en varias bases de datos de currículums de ingenieros de software para "F #", mucho menos del 1% de los currículums contienen la palabra clave.

3) El apoyo comunitario a partir de ahora (diciembre de 2010) está menos disponible. Puede buscar en Google casi cualquier problema en C # y encontrar a alguien que ya lo haya tratado, no así con F #. El soporte de herramientas de terceros (NUnit, Resharper, etc.) también es incompleto.

Me doy cuenta de que esto es un poco Catch-22, es decir, si las personas como yo no usan F #, la comunidad y las herramientas nunca se materializarán, etc. Pero tengo una empresa que dirigir y puedo ser innovador, pero sin borde sangrante.

¿Alguna otra trampa que no esté considerando? ¿O alguien quiere refutar las trampas que he mencionado? Creo que esta es una discusión importante y me encantaría escuchar sus contraargumentos en este foro público que pueden hacer mucho para aumentar la adopción de F # por parte de la industria.

La búsqueda reanuda para otros lenguajes funcionales como Scheme, Lisp o Haskell. Mucha gente aprende esto en la escuela y los tiene en sus hojas de vida; Estoy seguro de que a muchos de ellos no les importaría aprender F #. Tengo Scheme en mi currículum aunque nunca lo usé después de la escuela y un trabajo que involucra F # probablemente también llamaría mi atención.

¿Alguna otra trampa que no esté considerando?

En la práctica, el principal error que veo que la gente comete es tratar de forzar el uso de F # para problemas en los que es la herramienta incorrecta para el trabajo.

¿O alguien quiere refutar las trampas que he mencionado?

Todas son preocupaciones obviamente válidas hasta cierto punto, pero me preguntaría en qué medida.

Por ejemplo, usted dice que todos tendrían que aprender F # para trabajar en el código F #. Aunque es cierto, esto no es un gran problema en la práctica. Aprender F # no es más significativo que aprender WPF, Silverlight o TPL. Estoy enseñando a unos 30 desarrolladores cómo usar F # para un cliente en Londres en este momento y alrededor de una docena estaban trabajando a tiempo completo en el código F # después de solo unas pocas semanas y simplemente enviaron su primer producto (¡a tiempo y dentro del presupuesto! ) escrito casi por completo en F # después de solo unos pocos meses. De hecho, tuvieron más dificultades técnicas con Silverlight que F # y encontraron que el soporte técnico para Silverlight era mucho peor que para F #.

Se refiere al grupo relativamente pequeño de programadores de F # disponibles, pero, una vez más, dado lo fácil que es elegir F #, no creo que sea una preocupación importante. Dudo que deba contratar a muchos, si es que los tiene. Mi cliente tiene dos chicos F # para más de 100 programadores y nuestro trabajo es sembrar y supervisar el uso de F #.

Su tercera y última preocupación se refiere a menos soporte de la comunidad, Google para soluciones de C # frente a F # y soporte de herramientas de terceros. Nuevamente, no he encontrado que estos sean problemáticos en la práctica. Envié un correo electrónico a fsbugs con un comentario sobre las unidades de medida en F # y recibí una respuesta en 24 horas del investigador que lo inventó con una explicación detallada de por qué mi interpretación era incorrecta y por qué funciona de la manera en que funciona. Nunca recibí eso de Anders Hejlsberg ;-). Busco soluciones todo el tiempo en Google y las encuentro escritas en C #, VB o incluso IronPython, pero, en 3 años de uso de la industria F #, solo recuerdo una sola instancia en la que traducir la solución a F # no era trivial. De hecho, recientemente convertí la muestra C # del serializador de datos de MSDN a F # y fue 5 veces más corta. Finalmente, mencionaste el soporte de F # en herramientas como NUnit cuando ' He estado usando NUnit desde F # sin problemas durante algún tiempo. Estas son herramientas .NET, no herramientas de C #.

Estudio de caso : mi cliente actual no solo está usando NUnit para pruebas unitarias, sino que también construyeron TickSpec en F # sobre NUnit como una alternativa técnicamente superior a SpecFlow para BDD. El autor se propuso mostrarme que TickSpec es una pequeña fracción del tamaño de SpecFlow y proporciona más funciones. Además, varios de los desarrolladores en el trabajo sin experiencia previa en F # (y, creo, sin experiencia previa en programación funcional) lo han recogido y comenzaron a usarlo en proyectos no relacionados sin problemas precisamente porque F # + TickSpec hace que sea más fácil resolver sus problemas. problemas.

FWIW, le di a mi cliente una suscripción gratuita al sitio para nuestro F # .NET Journal que funcionó bien con muchos de los desarrolladores que aprendieron F #.

HTH!

Como reconoce en su primer punto, sus programadores que no conocen F # no pueden trabajar en la parte F # de su base de código. Sin embargo, no necesita reescribir toda su base de código en F # para obtener ventajas al usarla, solo reescriba las partes donde verá el mayor beneficio. El hecho de que F # interopera realmente bien con C # debería hacer que sea relativamente fácil tallar ciertas partes y crear conjuntos de F # a partir de ellas.

Si tuviera a sus ingenieros trabajando en una aplicación tradicional de 3 niveles, probablemente no insistiría en que todos necesitan tener un conocimiento profundo de SQL, HTML, Javascript, CSS, etc. En cambio, naturalmente tendría algunos especialistas trabajando en diferentes partes de la aplicación. Por lo tanto, no creo que agregar un nuevo idioma para una parte de su aplicación sea un obstáculo demasiado grande. Además, puede usar estándares de codificación y otras prácticas para intentar asegurarse de que su código F # sea legible incluso por ingenieros sin un fondo profundo de F #.

Las dificultades de agregar F # a los idiomas que usa incluyen las dificultades de introducir cualquier tecnología nueva. Independientemente de los beneficios, si algunos de su equipo no quieren o no son lo suficientemente flexibles para aprender, no podrán trabajar en proyectos de F #. Sin embargo, si deja que los dinosaurios de su equipo eviten la adopción de nuevas tecnologías, su empresa está condenada.

Los únicos escollos que he experimentado personalmente son:

1. Dificultades al depurar. Seguir el flujo de ejecución de un programa basado en expresiones en un depurador diseñado para lenguajes basados ​​en sentencias puede ser complicado.

2. Inteligente frustrante. La finalización automática deja de funcionar exactamente cuando la necesita. Microsoft debe trabajar para que el analizador en segundo plano sea más tolerante a fallas.

3. La sintaxis sensible a la sangría hace que sea difícil copiar, pegar o reformatear el código.

4. Falta de refactorización.

5. Algunas de las extensiones VS convenientes existentes para F # (plegado de código, color de profundidad) son un poco lentas, lo que hace que la experiencia de escritura sea un poco frustrante.

En mi opinión, ninguno de estos problemas es un obstáculo, y puedo vivir con ellos por el momento. Las herramientas son más fáciles de mejorar y corregir que los idiomas.

Sus temores de que contratar nuevos programadores capaces de escribir en F # sea difícil son bastante comunes, pero en mi opinión no están justificados. Si escribiera pautas de codificación, ¿desaconsejaría o prohibiría alguna de las siguientes características en C #:, yield returnLINQ to objects, lambdas, the coming async?

Si cree que estas características ayudan a escribir un mejor código, entonces no hay razón para abstenerse de F #. El lenguaje admite estas características de una manera suave y bien pensada, lo que C # realmente no puede hacer debido a su legado.

Si su equipo es lo suficientemente inteligente como para comprender los conceptos detrás de las características que mencioné, tienen todo lo que necesitan para ser excelentes programadores en F #. Lo mismo ocurre con los futuros reclutas: ¿Contrataría a alguien que no pueda o no quiera usar las funciones introducidas después de C # 1.0?

He contemplado esta situación exacta.

Esto es lo que planeo para mi equipo:

• Mezcle C # con F #, esto se puede hacer usando C # para la mayoría de la base de código. Cuando se requiera un procesamiento de datos pesado , escriba las funciones asociadas en F # y colóquelo dentro de un dll, o haga referencia a él. Ejemplo aquí

• Lentamente vuelva a factorizar su base de código existente de la manera anterior.

• No todo el código tiene que ser funcional.

• Haga que su equipo aprenda los conceptos básicos de Haskell, LISP durante los fines de semana .

• Haz que aprendan F #, tratando de resolver los acertijos del Proyecto Euler (eso me ayudó mucho cuando estaba aprendiendo F #). Una vez más, esto debería ser algo que se diga durante el fin de semana, o durante el tiempo de trabajo si desea reservar un día para "capacitación".

1) Aprender un lenguaje funcional aumentará la capacidad general de alguien como programador, sin embargo, esto solo se aplica a aquellos que desean aprender y mejorar. No todos los programadores quieren mejorar ni quieren un cambio en su entorno de trabajo (conozca a su equipo).

2) No puedo discutir con esto. Tendrá que pagar la curva de aprendizaje de 6 meses de cualquier idioma nuevo, sin embargo, saber las bibliotecas .net elimina los años adicionales necesarios para aprender nuevas bibliotecas.

3) El soporte de la comunidad, aunque es más pequeño que C #, tiene bastantes desarrolladores F # activos altamente calificados que publican en la web. No olvide que la mayoría del soporte de idiomas es el soporte de la biblioteca y hay un gran soporte para .NET.

El gorila de las mil libras aquí es la gestión de riesgos. "Puedo ser vanguardista pero no sangrante". Yo diría que F # no es un borde sangriento. Se lanzó con VS2010 y es directamente compatible con Microsoft. Bleeding Edge es "beta" y un descargo de responsabilidad de Microsoft que dice algo acerca de no ser responsable de nada.

Como cuestión práctica, el soporte de IntelliSense es bastante escaso, hasta el punto en que las ganancias de productividad de la inferencia de tipos son superadas por el autocompletado menos sofisticado disponible en C #.

Los mensajes de error causados ​​por inferencias de tipo erróneas también tardan más en solucionarse para principiantes (y a menudo para usuarios intermedios como yo), simplemente porque está menos inclinado a proporcionar anotaciones de tipo que en un lenguaje como C #.

OOP también carece de formas sorprendentes en F #; por ejemplo, no hay soporte para tipos / clases anidados. Debe tener cuidado al portar código, porque lamentablemente hay algunas cosas que puede hacer en C # que no puede hacer en F #.

Por último, pero no menos importante, tanto el tamaño como la calidad de la comunidad F # son algo decepcionantes. Gran parte de la información de F # que hay en la web es para versiones antiguas o simplemente no es muy buena, ya sea poco idiomática, bajo rendimiento o completamente incorrecta. Luego, hay personas que cobran mucho dinero por boletines informativos que son en gran parte solo de resúmenes de información existentes.

Yo mismo uso C # para proyectos de trabajo y F # para mis propias cosas. Por mucho que ame F #, desafortunadamente, es un poco difícil predecir cómo / cuándo las cosas podrían desmoronarse.

El principal problema es siempre la mantenibilidad.

Me encantaría codificar en Scheme, pero el próximo responsable probablemente querría perseguirme y torturarme.

Diría que lo primero que debe hacer es preguntar a los miembros de su equipo cómo se sienten al presentar F #. Si les gusta la idea, todo irá mucho mejor si no les gusta.