¿Por qué se prefiere la programación imperativa a la programación funcional? [cerrado]

13

Antecedentes: soy un defensor de la programación funcional que trabaja en una tienda VB.NET donde el modelo mental prevaleciente es la programación imperativa. Siendo que la base de nuestro sistema es WinForms, puedo entender que no vamos a alejarnos por completo de la programación imperativa, pero aún así trato de usar FP (principalmente a través de Linq) siempre que sea posible porque creo en sus méritos.

Argumentos & contra-argumentos contra FP

  1. Uno podría notar que Linq fluido es menos eficiente que su contraparte imperativa en que este estilo procesa una secuencia hasta otra secuencia y la repite. En general, tomará algunos pases más que el enfoque imperativo que puede optimizarse mejor para evitar pases repetidos en una secuencia. Por esta razón, el líder no pudo entender por qué elegiría un enfoque funcional que sea claramente "menos eficiente".

    • Contra-argumento : argumenté que aunque a veces es menos eficiente en términos de ciclos de CPU, sentí que es más inteligible desde el punto de vista humano y fácil de seguir, ya que cada línea hace solo una cosa en su paso sobre el secuencia. Para mí, esto se siente como tener una línea de ensamblaje donde cada persona en su estación tiene solo un trabajo que hacer. Siento que el comercio insignificante de la eficiencia es recompensado por un código cuyas preocupaciones están claramente separadas.
  2. El siguiente argumento en contra de FP que escucho en mi tienda es que es más difícil de depurar, lo cual es cierto. No es fácil pasar por encima del código Linq. Y a veces tengo que desentrañar una cadena de métodos para poder seguir y analizar mejor los problemas que no puedo detectar inmediatamente.

    • _Counter-argument: En su mayor parte, no tengo ningún problema con esto porque creo que el estilo funcional es más declarativo en la forma en que se lee y cuando se produce un error dentro de una cadena funcional, generalmente puedo detectar el problema. inmediatamente.

Mi pregunta

He estado tratando de promover el estilo funcional en nuestra tienda y no siento que estoy avanzando. He hecho ambos estilos de programación y solo he incursionado recientemente en Haskell. A pesar de los años de experiencia imperativa, ahora que estoy haciendo un uso rutinario de FP en JavaScript, ha crecido en mí. Suena una nota de rectitud en mi núcleo cuando lo comparo con lo que podría haber hecho si hubiera seguido un estilo imperativo. He reentrenado mi cerebro hacia el pensamiento funcional, hacia la composición funcional.

Lo que no puedo entender es lo difícil que es convencer a otros de los méritos de FP.

Por ejemplo, los desarrolladores de mi tienda usan Linq, pero creo que generalmente lo usan en el contexto de tratar con datos de dominio. Lo uso en un sentido más general y lo prefiero cada vez que trato con secuencias / listas o estructuras de datos persistentes. No he podido convencer a mis compañeros de equipo para que expandan el uso de Linq.

Lo que estoy tratando de entender es lo que hace que a un desarrollador no le guste FP.

Me gustaría ver una respuesta de alguien que tenga mucha experiencia en FP pero que haya decidido a favor del estilo imperativo. ¿Qué motivó la decisión de quedarse con imperativo en lugar de usar funcional?

Aquí hay un ejemplo adicional que resalta las diferencias entre imperativo y amp; Programación funcional.

Escribí el método SelectedRows de nuestra cuadrícula en Linq como tal:

Public Property SelectedRows() As DataRow() Implements IDataSourceControl.SelectedRows
    Get
        Return Me.ugrBase.Selected.Rows.
            OfType(Of Infragistics.Win.UltraWinGrid.UltraGridRow)().
            Select(Function(ugr) ugr.ListObject).
            OfType(Of DataRowView)().
            Select(Function(drv) drv.Row).
            ToArray
    End Get

Sin embargo, este estilo de código hace que algunos de nuestros desarrolladores se sientan incómodos, por lo que nuestro liderazgo lo reescribió a los más familiares:

Public Property SelectedRows() As DataRow() Implements IDataSourceControl.SelectedRows
    Get
        Dim plstRows As New List(Of DataRow)
        For Each bugrLoop As Infragistics.Win.UltraWinGrid.UltraGridRow In Me.ugrBase.Selected.Rows
            If bugrLoop.ListObject IsNot Nothing Then
                plstRows.Add(CType(bugrLoop.ListObject, DataRowView).Row)
            End If
        Next
        Return plstRows.ToArray()
    End Get
    
pregunta Mario T. Lanza 26.08.2013 - 16:11

1 respuesta

11

La programación funcional es simplemente demasiado complicada para los programadores inexpertos . Una de las ilustraciones es esta , donde los estudiantes declararon que el desorden 30-LOC era más fácil y más intuitivo de entender en comparación a las cuatro líneas de análogo FP.

(Esta es la versión original del ejemplo de FP, ya que la respuesta en el enlace se ha editado más recientemente para que sea un poco más fácil de leer).

return this.Data.Products
    .Where(c => c.IsEnabled)
    .GroupBy(c => c.Category)
    .Select(c => new PricesPerCategory(category: c.Key, minimum: c.Min(d => d.Price), maximum: c.Max(d => d.Price)));

La programación funcional requiere una forma diferente de pensar acerca de la forma en que codificamos y la forma en que se ejecuta este código. Esto rara vez es la forma en que se les dice a los estudiantes en la universidad, y una vez que se toman malos hábitos, es difícil cambiarlos.

La programación funcional también tiene sus propias características específicas que pueden parecer peligrosas para los principiantes . Una de ellas es la evaluación perezosa, y pueden pasar meses antes de que uno empiece a comprender por qué la evaluación perezosa es una característica excelente y no una molestia.

Es también por eso que muchos principiantes comienzan a programar con lenguajes como PHP y no lenguajes como Haskell.

    
respondido por el Arseni Mourzenko 26.08.2013 - 16:25

Lea otras preguntas en las etiquetas