La eficacia de pegarse a poco el paradigma funcional en Scala

Question

Hace poco compró Programación Scala , y han estado leyendo a través de él. El lenguaje definitivamente no es lo que esperaba! En concreto, parece poner en práctica casi todas las ideas lenguaje de programación Soy consciente de, fuera de macros Lisp y la segregación a nivel de tipo de efecto secundario de Haskell.

Francamente, me ha abrumado un poco. Aunque supongo que es bueno tener tantas herramientas a mi disposición, que estaba realmente en busca de un lenguaje funcional establecimiento inflexible en la JVM. Me imagino que probablemente podría utilizar Scala de esa manera, pero me imagino que si interactúan con ninguna biblioteca o pasar por el código de otra persona, voy a estar corriendo en una gran cantidad de este material avanzado programación orientada a objetos (para mí) - rasgos y "jerarquía de objetos linealización," todo este resumen y de la anulación de negocios, Singleton, objetos de paquete, y la compañía, las conversiones implícitas ... por no hablar de los diversos atajos sintácticos y azúcares.

La gente a menudo se lamentan de los programadores que tratan de meter con calzador el estilo de un idioma a otro, por un montón de buenas razones. Pero no todos los idiomas son tan múltiples como paradigma Scala, por lo que tal vez su comunidad tiene un punto de vista diferente? En F #, por ejemplo, parece que hay un margen de maniobra en la programación de estilos y la cantidad de programación orientada a objetos que utiliza. Pero sólo de lectura No estoy seguro si esto es una buena filosofía de Scala también.

Puede más experimentados programadores Scala me ayudan a cabo aquí? Editar para mayor claridad: Básicamente, puedo usar con seguridad solo (o la mayoría) de la FP cuenta de Scala sin preocuparse por su lado avanzada programación orientada a objetos?

Lo siento por la pregunta incoherente!

Answer 1

Creo que hay sin duda un punto sólido en esta pregunta. Está iluminada por buscando la forma de cualquier biblioteca puede manejar excepciones .

Si usted interactúa con una biblioteca de Java, cualquier método puede lanzar una excepción. Esto podría ser o bien de forma explícita, a través de un comprobado excepción - o transparente (desde la perspectiva de API), a través de un runtime excepción. Lo que se supone que debes hacer al respecto, como un programador que podría estar tratando de utilizar el tipo de Either más funcional para indicar el fracaso (o scalaz 's Validation)?

No es en absoluto claro cómo va a jugar esto en Scala (es decir, enfocar el problema y elegir el enfoque puramente funcional). Es cierto que es probable que produzca muchos estilos diferentes de la codificación. Dicho esto, hay mucho que es rica y útil a lo largo de la parte funcional de la Scala, que se puede recoger a partir; y sin duda es posible tener esta mezcla de código funcional e imperativo en su programa de trabajo al lado de otra. Aunque un funcional purista puede, por supuesto, estar en desacuerdo acerca de si esta una situación óptima.

Por lo que vale, he encontrado que la aplicación de paradigmas funcionales dentro de mis programas ha mejorado mi código no tiene fin. Como no he probado ninguno Haskell o F # No te podría decir si el resultado neto es mejor o peor.

Pero limpia el piso con Java; y para conseguir que el en la JVM (con la ventaja práctica de coexistir con todas nuestras bibliotecas de Java) es una aplicación asesina, desde mi punto de vista.

---

En los bordes, a medida que comience a utilizar el lado funcional de Scala más, hay una serie de cuestiones que se ejecutará en. Estos son más obvio:

• la falta de función implícita currificación (es decir, la equivalencia de A => B => C y (A, B) => C)
• la falta de función implícita tupling (es decir, la equivalencia entre una función de n-aria y una función de 1-ary que toma un n-tupla como un parámetro)
• la falta de inferencia para constructores de tipos parcialmente aplicada (es decir, la equivalencia de M[A] con, por ejemplo, Either[Int, A])

Estas dos cuestiones hacen lo que debe ser bastante clara y el código funcional, feo y oscuro.

Answer 2

Una de las cosas que estamos viendo es que Scala es, sobre todo, un lenguaje funcional inflexible de tipos en la JVM

Scala no es solo un lenguaje funcional. Se comenzó fuera como una (Embudo: http://lamp.epfl.ch/funnel/ ), pero esto se extiende entonces para que sea un lenguaje orientado a objetos, con el objetivo explícito de lo que es fuertemente interoperable con las clases de Java.

abstracción y anulando y los paquetes son ejemplos de esta interoperabilidad en acción.

---

El resto podría ser considerado no como nuevas características, sino simplemente como la eliminación de las restricciones de Java. Tomarlos uno a la vez:

rasgos y objeto de la jerarquía de linealización

Elimina la restricción de que las interfaces de Java sólo pueden contener métodos abstractos. Linealización es cómo Scala resuelve los problemas de diamante de herencia que esto sería de otro modo causar.

únicos

métodos estáticos de Java son una resaca de ella de C ++ patrimonio de sintaxis, que a su vez les añadió para apoyar mejor las necesidades de estilo de procedimiento para la interoperabilidad con los métodos C. estáticas son mucho NO orientado a objetos (véase la siguiente pregunta: Why son objetos simples más? orientado a objetos)

compañero de objetos

Permitir singletons para ser utilizados en lugar de los métodos estáticos, con sus derechos de acceso privilegiado.

conversiones implícitas

Java ya hace esto, pero está restringida sólo a la conversión implícita objetos primitivos y en cadenas, como en el "" + 3 expresión. Scala simplemente amplía esta idea y permite que el programador pueda usarlo para otras conversiones.

Answer 3

Permítanme añadir algunas observaciones a la respuesta de Kevin.

Rasgos se utilizan principalmente como abstracciones (hablando sin apretar, de la misma manera que las clases de tipos de Haskell definen abstracciones) y mixins. Por lo tanto, mi código podría utilizar la característica del mapa, pero en realidad el uso de una instancia del tipo como HashMap. Por el contrario, si quiero que mi tipo de "servicio" para tener la funcionalidad de registro, podría mezclar en un rasgo de registro reutilizable.

Afortunadamente, rara vez tienen que pensar en el algoritmo de linealización más allá de los casos sencillos, por ejemplo, que se puede mezclar en un rasgo que intercepta (envolturas) una llamada a un método para registrar el hecho de que el método se invoca. Las necesidades de algoritmo para manejar los casos más complicados de linealización (como los ejemplos que mostramos en el libro), pero en realidad estos tipos complicados son un diseño pobre, en mi humilde opinión.

Singleton, incluyendo los objetos especiales subconjunto de compañía, están diseñados para que todo sea un objeto, sino que también podría simplemente los ven como espacios de nombres integrar funciones y posiblemente algún estado.

Las conversiones implícitas son muy útiles, aunque un poco "mágica". Puede que le resulte útil para ver la forma en que se utilizan para simular Haskell Tipo-clases. Aquí está un gran mensaje por Debasish Ghosh: http: / /debasishg.blogspot.com/2010/06/scala-implicits-type-classes-here-i.html

Answer 4

A pesar de que he empezado la programación en Scala, definitivamente no soy un miembro más experimentado de la comunidad Scala. Pero he trabajado por mucho tiempo con otra lengua - pitón, que en menor medida tiene una situación similar. Es compatible con los procedimientos, orientado a objetos y estilos funcionales. He descubierto que mientras que algunas personas tienden a pegarse a un extremo, muchos combinan construcciones de diferentes estilos. Por lo tanto pitón idiomática constará de un uso intensivo de listas por comprensión, primera clase, de orden superior y funciones parciales, así como los datos de estas funciones trabajan en son objetos. Sin embargo, es de notar que en los últimos años, la tendencia ha sido cambiar ligeramente hacia funcional.

Creo que dada la inclusión de estilos que soportes Scala sólo es probable que no habrá una única manera de resolver un problema. Pero no me sorprendería ver que una mayor proporción de los programadores tienden lentamente hacia un estilo que hace un uso juicioso de los dos, aun cuando se mantengan tolerante con los programadores que deseen seguir uno de los extremos.