programming languages - programacion - ¿Por qué smalltalk no es un lenguaje de programación funcional?

programacion funcional vs orientada a objetos

Question

Con el interés renovado en los lenguajes de programación funcionales, he visto algunas similitudes entre Smalltalk y FPL, a saber, cierres (BlockClosures en Smalltalk) Sin embargo, ¿Smalltalk no es un FPL?

¿Qué se necesitaría para considerarlo como tal?

Answer 1

¿Qué se necesitaría para considerarlo como tal?

• una forma de declarar funciones en lugar de una forma de declarar métodos en una clase

• una forma de estructurar un programa alrededor de funciones en lugar de alrededor de objetos

@Missing Faktor, ¿pero la función en este ejemplo no es una función con nombre?

|func v|
func := [:x | x + 1].
v := func value: 5.

Ninguna func es una variable local. Has enlazado una función anónima a la func variable local.

|func v|
func := [:x | x + 1].
func := 2.
v := func value: 5.

Para ver la diferencia, mira este ejemplo de Erlang que muestra una función anónima y una función con nombre.

Answer 2

He visto algunas similitudes entre Smalltalk y FPL, a saber, cierres

Hay una similitud más básica: cada mensaje de Smalltalk siempre devuelve un valor.

Pero ahora veamos los principios de diseño detrás de Smalltalk

[Smalltalk] envía el nombre de la operación deseada, junto con cualquier argumento, como un mensaje al número, con el entendimiento de que el receptor sabe mejor cómo llevar a cabo la operación deseada.

¿Eso describe lo que piensas como Programación Funcional?

@Frank Shearar - Eso también describe a Erlang. ¿Es Erlang ahora no funcional?

Erlang es una especie de quimera: la programación secuencial se basa en funciones, pero la programación concurrente se basa en el paso de mensajes entre procesos. Por lo tanto, Erlang no es un paradigma múltiple o híbrido en la forma en que otros idiomas permiten que se utilicen diferentes estilos para lograr el mismo propósito: utiliza diferentes estilos para diferentes propósitos.

Answer 3

Gracias a todos por todas las respuestas.

Agregaré el mío aquí, que básicamente es mi (probablemente falta) comprensión del tuyo.

Creo que el criterio para llamar a algo OO o FP es la manera en que las "cosas" se crean utilizando el lenguaje; No es lo fácil o difícil que es hacerlo, es decir, el paradigma mental utilizado.

Por ejemplo, como se muestra en los enlaces, puede ser más difícil escribir algo en Scala que en OCaml, pero eso no lo hace menos FPL (tal vez incompleto o impuro, pero definitivamente funcional); porque el objetivo de Scala es usar funciones como bloques de construcción primarios, en lugar de objetos.

Por otro lado, facilitar la escritura de una función en un lenguaje no lo hace funcional, si el estilo o el objetivo es utilizar otros artefactos. Smalltalk, por ejemplo, hace que sea muy fácil escribir un bloque anónimo o proporcionar un comparador de clasificación conectable, pero eso no lo hace NINGUNA Funcionalidad en absoluto, porque el objetivo es usar objetos y pasar mensajes. Los bloqueos son solo un mecanismo para codificar estos mensajes (no funciones) incluso si se ven como si fueran funciones.

La confusión viene, porque OO y FP son ortogonales (como dijo Rahul través de twitter), entonces, lo que parece un mensaje codificado en Smalltalk, se parece mucho a una función anónima en Scala. Pero hacer algo similar no convierte un lenguaje de un paradigma en otro.

Para empeorar las cosas, Scala también usa el paradigma OO, para facilitar que los programadores convencionales (Java, C ++, C #) den el salto, y si lo ves, ha tenido mucho más éxito que cualquiera de los otros FPL. Y, por supuesto, esto fue gracias a Java (en mi humilde opinión, si Clojure tiene algún éxito, será exactamente por el mismo motivo, la JVM)

En conclusión : un lenguaje de programación puede ser clasificado por el paradigma que usa para construir "cosas". Hay idiomas que son puros como [Smalltalk: OO, Haskell: Functional, C: Procedural], o híbridos, como Scala o paradigma múltiple, como C ++, Ruby, Python.

El hecho de que pueda escribir un estilo con el otro idioma, no lo convierte en ese lenguaje de ese estilo. Al igual que simular objetos con Lisp, no es OO, ni usar funciones con Java lo hace Funcional.

Para responder a la pregunta, para ser considerado funcional, Smalltalk necesitaría usar funciones como bloques de construcción, lo cual no es así porque usa objetos.

Answer 4

La programación con el paradigma Orientado a Objetos es crear un programa al identificar y modelar las Entidades de Dominio del Problema como objetos, y luego hacer que colaboren entre sí para resolver cada instancia de problema. La programación con el paradigma funcional es modelar el problema como un problema matemático y crear una función matemática (al componer otras funciones) que para cada instancia de problema, calcula la solución del problema.

En mi opinión, un lenguaje de programación funcional es un lenguaje que, dada una solución para un problema resuelto con el paradigma de programación funcional, el lenguaje puede expresar esa solución exactamente como se pensó. Si necesita "transformar" alguna parte de su solución para que se ajuste a lo que el lenguaje puede expresar, entonces no es totalmente compatible con el paradigma que utilizó para pensar la solución.

Smalltalk puede expresar en la mayoría de los casos todas las soluciones creadas usando el paradigma de Programación Orientada a Objetos, pero no puede expresar primitivamente muchas soluciones creadas usando el paradigma de Programación Funcional. Por eso no lo considero un FPL. A pesar de no ser primitivamente capaz de expresar todas las soluciones que puede lograr un FPL, Smalltalk es extremadamente extensible, y usted puede extenderlo para poder expresar todas las soluciones que un FPL puede.

Answer 5

Los lenguajes puramente funcionales suelen tener variables inmutables, lo que las hace más parecidas a las variables en un sentido matemático.

Answer 6

No hay una definición aceptada de lenguaje de programación funcional.

Si define el lenguaje funcional como el idioma que admite funciones de primera clase, entonces sí, Smalltalk * es * un lenguaje funcional.

Si también considera factores como la compatibilidad con la inmutabilidad, los tipos de datos algebraicos, la coincidencia de patrones, la aplicación parcial, etc., entonces Smalltalk * no es un lenguaje funcional.

Le animo a leer las siguientes publicaciones de blog relacionadas (y también los comentarios debajo de ellas):

• Scala no es un lenguaje funcional.

• Erlang no es funcional

• Discusión de Reddit sobre "Erlang no es funcional".

Answer 7

Smalltalk es un lenguaje puramente orientado a objetos, donde casi todo el código es básicamente objetos que intercambian mensajes. La programación funcional está orientada a llamadas de función, y las composiciones entre funciones para crear un comportamiento más complejo (evitando el estado de los datos, a diferencia de los estados internos que tienen los objetos en cualquier lenguaje orientado a objetos).

Answer 8

Smalltalk podría no ser un "lenguaje funcional puro" (sea lo que sea). Sin embargo, el uso natural de Smalltalk a menudo resulta en un código funcional. (Lo que supongo que la gente de Scala llamaría "objeto-funcional".)

Por ejemplo, la clase de puntos de Squeak tiene una API funcional: métodos como 1@1 translateBy: 1@1 devuelve nuevos puntos con el nuevo estado, en lugar de mutar el estado interno. (Esto hace que Point sea prácticamente inmutable, ya que la única forma de cambiar el estado interno del objeto es a través de mecanismos de reflexión como #instVarAt :.)

Es bastante normal usar funciones de orden superior en Smalltalk como mapas, filtros, pliegues y similares. Dado que estos están incorporados en la API de colecciones, a menudo es más fácil escribir código que usa colecciones de una manera funcional que no.

Tanta gente tiene tantas definiciones de "lenguaje de programación funcional" que la pregunta "es Foo un FPL" es una pregunta tan inútil como "Foo es un lenguaje orientado a objetos".

Dicho esto, he aquí mis dos centavos: un lenguaje de programación funcional es un lenguaje en el que es natural e idiomático emplear técnicas funcionales: funciones de primera clase, evitar el estado mutable, funciones libres de efectos secundarios, funciones de orden superior.

Por esa descripción, Smalltalk es un lenguaje de programación funcional. Llama a las funciones de primer orden "métodos" o "bloques" dependiendo de si son nombrados o son anónimos. Los objetos almacenan el estado en variables de instancia. Las funciones de orden superior son simplemente métodos que toman bloques como parámetros.

Dicho esto, sí, puede escribir Smalltalk de una manera no funcional. Permite un estado mutable. ¿Eso evita que Smalltalk sea llamado un lenguaje funcional? Si es así, ninguno de estos idiomas es funcional: Common Lisp, Erlang (estado compartido a través del diccionario de procesos, ets / dets).

Entonces, en resumen, Smalltalk es un FPL porque:

• Las funciones son entidades de primera clase (objetos, en Smalltalk - CompiledMethods o BlockClosures, para ser precisos).
• Smalltalk soporta cierres (los llama bloques).
• Smalltalk permite escribir funcionalmente de una manera natural e idiomática.

y Smalltalk no es un FPL porque:

• Usted como programador debe asegurarse de que sus estructuras de datos (objetos) sean inmutables (al hacer que los creadores / mutadores devuelvan copias del objeto con el estado mutado).
• Usted como programador debe asegurarse de que sus métodos (funciones) estén libres de efectos secundarios.

(Al parecer, algunos Smalltalks admiten objetos inmutables. Mi experiencia se limita a Squeak, que no admite la inmutabilidad a nivel de máquina virtual).

Edición: No entiendo la necesidad de igouy de tener definiciones de funciones con nombre más que a través de la definición de métodos en un objeto. Pero de todos modos, aquí vamos:

Smalltalk at: #func put: [:x | x + 1].
func value: 1.

Answer 9

Un lenguaje no se convierte en un lenguaje funcional al tener funciones nombradas. ¡Según esa definición, C sería funcional! Más importante es la semántica funcional en el sentido matemático, que el resultado depende solo de los argumentos (en particular: sin efectos secundarios). Según esta definición, los objetos que pueden ser modificados por los configuradores son contrarios a un estilo de programación funcional. Sin embargo, como ya se señaló, incluso los objetos pueden usarse en un estilo funcional (ejemplo de rectángulo) si prohíbe los efectos secundarios. Y, por cierto. existe una dualidad entre los objetos con métodos y un conjunto de funciones que se definen en un cierre sobre un estado privado (consulte el SICP para obtener más información). Pueden simularse mutuamente:

(def (make_foo initVal1 ... initValN)
   (let ((instVar1 initVal1) ... (instVarN initValN))
      (define (method1 args) ...)
      ...
      (define (methodN args) ...)
      (define (lookup selector)
          (cond ((eq? selector ''method1) method1)
             ...
             ((eq? selector ''methodN) methodN)
             (true doesNotUnderstandCode)))
      lookup)) ; returns the lookup function (provides "access into the closure") !

(defMacro (method1 receiver.args)
    ((receiver selector) args))

(define foo (make_foo 1 2 ...))
(method1 foo ...)

¡Lo anterior es una simulación de objetos funcionales "puros", y semánticamente lo mismo que una gran cantidad de código Smalltalk! Sin embargo, para implementar un método setter, debe agregar un método que haga un (set! InstVar newValue). Y, porque se establece! No es funcional, rompe la "funcionalidad" del esquema.

Resumen: mira la semántica, no la fuente, ¡luke!