Funciones de primera clase

Comencé a mirar seriamente a Lisp este fin de semana (con lo que quiero decir que solo he estado aprendiendo Lisp y no volviendo a los proyectos en C #) y debo decir que me encanta. He incursionado en otros lenguajes funcionales (F #, Haskell, Erlang) pero no he sentido el atractivo que me ha dado Lisp.

Ahora, mientras continúo aprendiendo Lisp, comencé a preguntarme por qué los lenguajes no funcionales no admiten funciones de primera clase. Sé que lenguajes como C # pueden hacer cosas similares con los delegados y, en cierta medida, puede usar punteros para funciones en C / C ++, pero ¿hay alguna razón por la que esto nunca se convierta en una característica en esos idiomas? ¿Hay algún inconveniente en hacer que las funciones sean de primera clase? Para mí, es extremadamente útil, así que estoy perdido en cuanto a por qué más lenguajes (fuera del paradigma funcional) no lo implementan.

[Editar] Agradezco las respuestas hasta ahora. Como se me ha demostrado que muchos idiomas ahora admiten funciones de primera clase, volveré a formular la pregunta de por qué los idiomas tardarían tanto en implementarlos. [/Editar]

C #, VB.NET, Python, JavaScript, ahora incluso C ++ 0x proporciona funciones de primera clase.

Actualizar:

Una implementación de cierres requiere el levantamiento de lambda, una técnica originalmente bastante extraña para los programadores imperativos. Las funciones de primera clase adecuadas (que incluyen cierres) requieren al menos algo de soporte del tiempo de ejecución y VM. También tomó algún tiempo adoptar las viejas técnicas funcionales en el mundo imperativo.

Y, la parte más importante: las funciones de primera clase son apenas utilizables si no hay recolección de basura presente. Se introdujo en una programación masiva recientemente, con Java y, en consecuencia, .NET. Y el enfoque original de Java fue simplificar en exceso el lenguaje para que los codificadores promedio lo puedan comprender. .NET primero siguió, y solo recientemente se separó de esa dirección (en mi humilde opinión, bastante justificada y apropiada).

Todos estos conceptos tardan en ser digeridos por la industria.

Las funciones de primera clase son mucho menos interesantes sin cierres.

Los cierres no son realmente posibles sin algún tipo de gestión dinámica del alcance (recolección de basura). Una de las cosas que hace que C / C ++ tenga un alto rendimiento es el hecho de que es mucho más fácil compilar un lenguaje en el que administras la memoria manualmente, de modo que de alguna manera se elimina C / C ++ de la ecuación.

Y luego sí, está el asunto del impacto de la POO. Ya no tiene una separación de métodos y propiedades. Los métodos son en sí mismos propiedades que aceptan funciones como valores. En ese contexto, ¿qué significa realmente sobrecargar los métodos, ya que puede cambiar las cosas tontas en cualquier momento? ¿Puede realmente agregar eso a Java, por ejemplo, sin introducir un cambio de paradigma importante en todo el lenguaje? ¿Dónde está el contrato o esa sensación de seguridad (IMO falsa) que las personas obtienen al saber que la construcción garantiza que siempre funcionará de la misma manera cada vez? Puede tener sentido tratar las funciones vinculadas a los objetos como métodos como un organismo diferente en lenguajes que permiten que las funciones existan independientemente en primer lugar, pero en Java eso no es realmente una opción.

En JavaScript, OOP y funcional están muy entrelazados y personalmente me resultaría difícil ver los funcs de primera clase como algo más que atornillado en idiomas donde no lo estaban. Pero eso requiere una serie de otros cambios de cambio de paradigma, incluidos los altos niveles de mutabilidad en los objetos y sus propios métodos, así como la capacidad de invocar funciones como si fueran miembros de cualquier objeto sobre la marcha.

Los idiomas no son solo conjuntos de herramientas llenas de trucos para hacer las cosas en su mayor parte. Son paradigmas. Paquetes de ideas, estrategias y opiniones que todo tipo de cosas van juntas de una manera que está conectada (o parece estar conectada). En muchos casos, las funciones como sustantivo y verbo realmente no se ajustan al paradigma en absoluto o, en el mejor de los casos, son un ajuste imperfecto.

Dicho esto, siento que me falta un brazo cuando me veo obligado a codificar sin ellos.

No es realmente imposible. Pero es otra característica más, y el presupuesto de complejidad es limitado. El diseñador del lenguaje puede considerarlo innecesario (o incluso no se le ocurre): "¿por qué diablos necesitaríamos pasar funciones? ¡Este lenguaje es para programar un sistema operativo!". También puede tomar un esfuerzo significativo fusionarse con el resto del idioma. Por ejemplo, un tipo de función puede requerir adiciones serias al sistema de tipos (por ejemplo, en Java), aún más si tiene una sobrecarga (gracias @Renesis por señalarlo). También debe proporcionar un código de biblioteca para hacer uso de lo viable: nadie quiere definirse a mapsí mismo.

También podría hacer que otros objetivos del lenguaje sean más difíciles de lograr:

• Se vuelve "más difícil" optimizar (en realidad no es más difícil en muchos casos, pero requiere enfoques diferentes a los que está acostumbrado). Por ejemplo, si las funciones globales pueden reasignarse, debe probar que fnunca se reasignan antes de incluirlas.
• Del mismo modo, si crea objetos con funciones completas, necesita un compilador inteligente y JIT para eliminar la sobrecarga asociada a eso y hacer que las llamadas sean tan eficientes (en cuanto a velocidad y espacio) como enviar argumentos y dirección de retorno y saltar a alguna dirección
• Como ya se mencionó, es otra característica completa y los primeros pasos para admitir otro paradigma: si desea un lenguaje simple, tal vez no pueda permitirse agregar funciones de primera clase sin lanzar otras cosas (que puede considerar mucho más importantes) afuera.
• Quizás simplemente no se mezcla bien con el resto del lenguaje. Si diseña el lenguaje para, por ejemplo, ser la mejor encarnación de OOP desde Smalltalk, es posible que desee centrarse en eso en lugar de ofrecer otro paradigma muy diferente. Especialmente si es difícil integrar los dos (ver arriba). Los paradigmas N bien hechos son más agradables de programar que los paradigmas N + 1 mal hechos.

En la misma línea, uno puede preguntarse por qué cualquier lenguaje de programación L1 no tiene la función F del lenguaje muy diferente L2.

Creo que el primer problema es un malentendido de que Orientado a objetos y Funcional no se pueden mezclar. Una lista rápida de lenguajes descritos, al menos por Wikipedia, como ambos: JavaScript , ActionScript , Python , C # , F # .

El segundo problema parece ser una definición de funciones de primera clase : ¿por qué no considera que C # las tenga, por ejemplo?

No soy un experto en lenguaje funcional, así que corríjame en los comentarios si me equivoco, pero entiendo que la inclusión de funciones de primera clase en sí misma define más o menos si un lenguaje admite un paradigma funcional .

¿Cuál es la verdadera pregunta?

Entonces, entendiendo que los lenguajes orientados a objetos también pueden ser funcionales, y estos lenguajes contienen funciones de primera clase, parece que la pregunta que está buscando es ¿por qué algunos lenguajes orientados a objetos no contienen funciones de primera clase?

Función de sobrecarga

Una de las razones principales para esto es la dificultad de definir funciones de primera clase cuando el lenguaje también ha elegido soportar la sobrecarga de funciones (ejemplo en Java):

public int dispatchEvent(Event event);
public int dispatchEvent(String event, Object data);

¿A qué dispatchEventfunción se referiría una variable?

Programación basada en clase

La programación basada en clases no impide que un lenguaje admita objetos de primera clase, pero puede hacerlo más confuso o agregar preguntas para ser respondidas.

ActionScript, por ejemplo, como lenguaje ECMAScript comenzó en un paradigma mucho más funcional como JavaScript. Las funciones no estaban inherentemente vinculadas a los objetos, esencialmente podían llamarse con cualquier objeto, ya que su alcance en el momento de la ejecución.

Cuando agrega clases (no dinámicas), tiene funciones que están inherentemente vinculadas a una instancia, no solo a la clase en sí. Esto arroja algunas arrugas en la especificación de Function.applyque honestamente no he profundizado para descubrir cómo lo han tratado.

Me he preguntado lo mismo. Una vez que estoy en un idioma con lambdas, los uso MUCHO. Incluso PHP mejora cuando te das cuenta de que puedes hacer un cierre con php 5.3 (no es tan bueno como lisp, pero aún mejor)