C#vs F#para GUI programáticas de WPF

xaml (5)

Estoy tratando de decidir dónde trazar la línea sobre el uso de F # y C # en el desarrollo de software empresarial. F # para el código matemático es una obviedad. Me gusta F # para el trabajo de GUI aunque no tenga soporte de diseñador de GUI pero, por supuesto, hay más disponibilidad de recursos de la gente de GUI de C # en la industria. Sin embargo, no estoy muy familiarizado con el desarrollo de la interfaz gráfica de usuario C + + XAML, por lo que me preocupa introducir un sesgo.

En el caso de un cliente, tienen docenas de GUI similares que son bastante estáticas (se cambian cada año) y algunas otras GUI que son muy dinámicas (por ejemplo, motores de reglas de negocio). Ya tienen el código F # en vivo y ya están invirtiendo en entrenamiento F # para que la disponibilidad de habilidades no sea un problema. Mi impresión es que C # + XAML te permite construir GUI estáticas (algunos controles deslizantes, algunos cuadros de texto, etc.) fácilmente, pero no veo cómo el diseñador de GUI ayudaría con las GUI programáticas, como un motor de reglas de negocio. ¿Estoy en lo cierto al pensar que mantener una batería de GUI estáticamente estáticas (por ejemplo, agregar un nuevo campo a 100 GUI separadas) requerirá mano de obra? Además, ¿tengo razón al pensar que el diseñador de GUI es de poca utilidad en el contexto de GUIs fuertemente programáticas, por lo que algo como un motor de reglas de negocio se escribiría principalmente en C # + XAML con poco uso del diseñador de GUI?

Como ha señalado, F # es una habilidad mucho más escasa entre los programadores en la industria general de TI, mientras que cada hombre y su perro conocen C # (o, para el caso, Java, C / C ++ que se traducen fácilmente).

Por lo tanto, desde un punto de vista puramente gerencial, probablemente tenga más sentido ir con C # + XAML sobre F # debido a una serie de factores:

Salarios del programador: contratar a un gurú de F # aumenta bastante el presupuesto salarial
Tiempo de desarrollo: esto podría argumentarse de cualquier manera, ver 1 para una buena comparación
Riesgo corporativo: el uso de F # aumenta en gran medida el factor de riesgo en cada una de las categorías:
- Programador deja la empresa y lleva la propiedad intelectual con ellos
- El programador deja la compañía y la empresa no puede contratar un reemplazo => el proyecto falta el plazo
- La empresa no cuenta con métricas adecuadas para medir el tiempo requerido para el proyecto
- El lenguaje se depraca y el código tiene que ser portado (no es una gran preocupación, pero aún más riesgoso que C #)
- Etcétera etcétera.

Sin embargo, desde una perspectiva de ingeniería, F # (quizás con una biblioteca complementaria para visualizaciones) puede simplemente generar una poderosa GUI. C #, sin embargo, también tiene esta capacidad: puede generar toda su GUI sin usar XAML programáticamente.

En cuanto a agregar un nuevo elemento a más de 100 GUI, aquí no veo cómo XAML es una desventaja en absoluto. Si entiendo su pregunta correctamente, puede usar una plantilla de datos que puede actualizar una vez en XAML y hacer que el cambio se propague a través de todas sus GUI.

En conclusión, le sugiero que, a menos que tenga una buena razón para usar F #, quédese con C #, ya que reducirá el riesgo para su empresa a largo plazo.

Hace poco construí una aplicación de visualización de gráficos dirigidos usando puramente F # y WPF.

Para las partes de la GUI ''programática'', esencialmente construí controles personalizados de WPF que podía operar con enlace de datos y MVVM.

Para las partes estáticas utilicé XAML con controles de WPF listos para usar y personalizados.

Usé el FSharpX WPF Type Provider extensivamente para el enlace MVVM.

Y este ''libro'' me ayudó bastante para comenzar. http://wpffsharp.codeplex.com/

Algunas cosas no son naturales con F # y WPF, pero en casi todos los casos se encontró una solución razonablemente elegante. Algunas cadenas de enlace de datos de WPF se volvieron grandes y difíciles de manejar.

He realizado una buena cantidad de programación GUI y no GUI en C # y F #, en trabajo y juego, programática y estática ... y creo que su impresión es precisa y práctica. (Tenga en cuenta que estoy más familiarizado con WinForms que con WPF, pero no creo que las diferencias importen aquí).

Mi impresión es que C # + XAML te permite construir GUI estáticas (algunos controles deslizantes, algunos cuadros de texto, etc.) fácilmente, pero no veo cómo el diseñador de GUI ayudaría con las GUI programáticas, como un motor de reglas de negocio.

Esta es absolutamente mi experiencia. Para GUI principalmente estáticos, prefiero usar el diseñador de WinForms con C #. El combo de herramientas es ideal para estos escenarios y es más productivo que codificar manualmente la GUI con F # y sin diseñador (ahora, si hubiera compatibilidad con F # con el diseñador, no dudaría en preferir eso). I''m Only Resting es un ejemplo en el que he preferido C # con el diseñador de WinForms sobre el F # puro.

Y para las GUI programáticas pesadas, creo que es mejor evitar al diseñador por completo, en lugar de intentar ir medio diseñador medio programático (se vuelve realmente desordenado, muy rápido). Entonces, en estos casos, definitivamente prefiero codificar manualmente las GUI en F #, ya que todos saben que F # es el lenguaje más expresivo;) FsEye es un ejemplo en el que he preferido el F puro sobre C # con el diseñador de WinForms.

¿Estoy en lo cierto al pensar que mantener una batería de GUI estáticamente estáticas (por ejemplo, agregar un nuevo campo a 100 GUI separadas) requerirá mano de obra?

Probablemente. No creo que haya realmente ninguna solución preparada para este problema, ya que es bastante grande. Pero podría haber algunas mejores prácticas para construir una solución personalizada adecuada para su suite de software.

Además, ¿tengo razón al pensar que el diseñador de GUI es de poca utilidad en el contexto de GUIs fuertemente programáticas, por lo que algo como un motor de reglas de negocio se escribiría principalmente en C # + XAML con poco uso del diseñador de GUI?

Sí, como dije antes, creo que no debe intentar mezclar el diseñador de la GUI con la programación programática pesada de la GUI.

No sé exactamente cómo responder la pregunta, ya que es algo difícil de controlar, así que solo te doy mi 0.05 $:

Si haces WPF con un MVVM bueno (incluso hay Rx-Versions que están influenciados por FP-land) no escribirás código-detrás (o casi ninguno) - y con proveedores de tipo WPF y todas las otras cosas geniales que son a su alrededor ya puede escribir aplicaciones WPF-F # sin ningún problema (incluso el soporte del diseñador no es problema, simplemente use BLEND si puede), si no, puede separar la GUI en una tonta C # -lib).

Entonces, ¿por qué no escribo la mayoría de las GUI en 100% F #?

Bueno, para ser sincero ... es la falta de refactorización y herramientas como ReSharper; es frustrante que no pueda buscar símbolos o tipos F # porque no hay soporte maldito en VS / R # er en este momento.

Es extraño pero escribir código MVVM donde tiene que crear código mucho más trivial para sus Viewmodels parece ser más fácil de hacer en C # con las herramientas correctas en este momento (por ejemplo: puedo configurar R # er para insertarme todo el código para probertys públicas) con setters privados / públicos e INotifyPropertyChanged basados en campos internos simplemente pulsando - y eligiendo la opción correcta - esto generará muchos códigos muy tontos pero es mucho más rápido que lo que podrías hacer en F #)

Veo muchas respuestas confusas y soluciones aquí. F # y C # se pueden combinar en solución. Deje que C # administre paquetes de administración de GUI y F #. Además, XAML vs WinForms es pan comido. Con XAML, hay espacio más que suficiente para el código detrás para hacer cualquier y todo lo que necesita. Si usa WinForms, creo que debe retirarse inmediatamente. WPF, por ejemplo, es mucho más flexible y extremadamente potente con opciones de GUI muy por encima de las de WinForms. Por no mencionar el poder de enlace de XAML. XAML es estático, pero se comunica muy bien con el código y puede comunicarse con todos los lenguajes .NET. Use F #, use C # juntos y definitivamente deje el mundo de WinForms para siempre. Aquí hay un pequeño proyecto que hice. Utiliza solo una combinación de WPF, Silverlight, WCF, F #, C # y VB.NET. WinForms no fue tocado y si miras de cerca verás que lograr esto con WinForms hubiera llevado años. Pude haber completado esto con un solo idioma, pero el intercambio me ayudó a ahorrar tiempo dependiendo de la situación, pero solo avancé, nunca al revés. WinForms, así como todas las demás opciones heredadas, se ignoraron y nunca se usaron.