Un programador me dijo que no le gustaba Apple Swift. ¿Qué aspectos de Swift podrían hacerle decir eso?

La oposición que he visto a Swift normalmente se divide en dos campos:

1. Programadores experimentados de Objective C que parecen tener miedo de algo nuevo . O al menos temeroso de perder productividad mientras se acelera en el nuevo idioma.

Como ejemplo, un amigo mío era escéptico de Swift, porque “no tiene enmascaramiento de bits, por lo que debe ser más lento / no está listo para la producción / inexpresivo”. En realidad, los creadores de Swift han ideado una forma más concisa y legible pero igualmente eficaz de tratar este problema en forma de OptionSets . En caso de que te lo estés preguntando, también puedes enmascarar bits si realmente quieres (o tienes que hacerlo, cuando usas una API más antigua).

2. Los programadores de idiomas que Swift ha tomado prestados de quienes están seguros de que su camino es mejor que la reinvención de Swift

A menudo veo comentarios sobre las mónadas “rotas” de Swift (en la forma de los opcionales muy útiles e intuitivos de Swift), o sobre su sistema genérico “roto” (generalmente de personas que quieren hacer algunos trucos serios de programación funcional pura). No puedo comentar aquí directamente porque no tengo experiencia con Haskell o Scala u otros lenguajes de programación funcional.

Lo que puedo comentar es que Swift ciertamente no es un lenguaje de programación roto o malo de ninguna manera. Todo lo contrario: he descubierto que es una alegría escribir, una alegría aún mayor para leer, es eficaz, potente y versátil.

Para aquellos en el campo 1 , dudo mucho que quede mucho para obligar a alguien a usar el objetivo C para la gran mayoría de las tareas. Creo que es sobre todo el miedo a lo desconocido y una leve pereza que obliga a la mayoría, si no a todos, a seguir disgustando a Swift por este motivo. Dicho esto, hay algunas razones para seguir usando el Objetivo C, al que volveré en breve.

Para aquellos en el campo 2 , estoy convencido de que muchas de las razones y argumentos presentados aquí son válidos. Swift no es un lenguaje puramente funcional. Es un lenguaje para hacer una muy amplia gama de tareas muy bien. En ese sentido, es un lenguaje “convencional”, no un lenguaje indie, hipster o académico (leí un buen artículo sobre esto una vez y lo publicaré aquí si puedo encontrarlo nuevamente).

Por lo tanto, Swift no es tan innovador como algunos otros idiomas, pero lo compensa con la familiaridad (lo que ciertamente no es un gran argumento en sí mismo, aunque sí reduce la barra de entrada en comparación con los idiomas con construcciones de sintaxis completamente diferentes, y mucho menos arquitecturas de programa) y, lo que es más importante, en versatilidad. Usted puede:

realice algunas composiciones funcionales extremadamente concisas y potentes y una combinación de números, con un soporte bastante decente para los tipos genéricos (que mejorará nuevamente en el próximo Swift 3.0).
escriba una interfaz de usuario basada en programación orientada a objetos de manera cómoda y mucho más concisa que en el objetivo C. ¿Hay marcos de interfaz de usuario decentes en Haskell de uso común? Esto muestra mi ignorancia pero me resulta difícil de imaginar (por favor, escríbame en los comentarios si este es el caso)
use las técnicas que Apple llama Programación Orientada a Protocolo para hacer un gran uso de la inmutabilidad y los tipos de valor mientras programa de una manera que maximice la reutilización del código. Sí, la idea de los Protocolos (también conocidos como Interfaces) no es nueva, pero Apple ha hecho un gran trabajo al expandir lo que puede hacer con ellos y mantenerlos en funcionamiento sin hacer que las cosas sean incómodas para el lector (aparte de algunas idiosincrasias en el modelo de enlace, que tomar un tiempo para acostumbrarse)
Use un REPL y / o parques infantiles para probar ideas de forma rápida y gráfica. Para algunos esto es ENORME. Al igual que muchos de estos puntos, si no todos, individualmente, no es exclusivo de Swift, pero es otra parte que hace que el valor de Swift sea mayor que la suma de sus partes.

La lista continúa, el punto es este: Swift hace muchas cosas, y las hace más que suficientemente bien como para que en la gran mayoría de los casos probablemente no te veas obligado a usar nada más.

Además de esas áreas ya mencionadas en comparación con algunos idiomas más especializados, todavía hay algunos puntos en los que Swift podría (algunos podrían decir desesperadamente) mejorar algo:

Soporte de C ++. Actualmente no hay forma de interactuar con clases u objetos C ++ desde Swift. Este es un problema solo si está tratando de usar bibliotecas de C ++ heredadas, lo que probablemente terminará haciendo si desea escribir código multiplataforma (es decir, para iOS, OSX y Linux / Android, en el futuro tal vez también Windows ) Esta es una cosa que Objective C hace mejor, en forma de Objective C ++. Por otro lado, el Objetivo C, aunque de código abierto, nunca tuvo mucho tiempo del día más allá del ecosistema de Apple (Swift, por otro lado, ya está explotando).
Para el caso, soporte C. Actualmente es posible (y a menudo bastante sencillo) usar el código C de Swift, e incluso viceversa. Pero necesita trabajo.
Enlace estático a la biblioteca estándar. En la mayoría de los casos, el enlace dinámico está bien, pero hay ciertos casos (como compilar el código Swift para el navegador web a través de Emscripten) donde la compilación estática sería un gran salto adelante.
Las mejoras genéricas y de extensiones serían excelentes, el ejemplo clásico es una matriz de cierto tipo genérico o protocolo que también puede realizar funciones del tipo contenido.

Al final del día, si usa Swift depende de los requisitos de su proyecto, la familiaridad con otras herramientas y (triste pero inevitablemente) las preferencias personales. Si ha pospuesto aprender Swift simplemente por los comentarios de que es “malo”, ¡puedo asegurarle que no se arrepentirá!