Re: [ASNativos] Compilación de correos para asnativos@googlegroups.com - 11 actualizaciones en 1 tema

[Angel Ernesto Anton Yebra]

me apunto al bando del Swift más adaptado a los nuevos tiempos que C#. Alterno entre Swift y Kotlin y creo que mejoran a sus predecesores con diferencia (Objective C y Java). C# es verdad que hace esfuerzos para actualizarse pero es difícil competir con un lenguaje 20 años más nuevo y hecho para cubrir otras necesidades (menos OOP, mas functional, sin ";", etc).

Si multiplataforma o no, depende de la app, del equipo, etc. Hay de todo empezando por Toggl, a mí después de defender Xamarin me gusta más lo nativo.. por la combinación del lenguaje y las herramientas. Apretando un poco se pueden aplicar conceptos muy similares (MvvM, MvI o unidirectional data flow), eso y que los lenguajes se parecen bastante.. puedes alternar sin volverte loco.

El mié., 1 ago. 2018 a las 10:44, <asna...@googlegroups.com> escribió:

asna...@googlegroups.com

Grupos de Google

Resumen de temas
Ver todos los temas

• OT Oferta freelance - 11 actualizaciones

OT Oferta freelance

"Ricardo Sánchez Sotres" <odr...@gmail.com>: Jul 31 10:41PM +0200 Hombre, el nombre de las cosas importa, sobretodo si es algo que en todos los otros lenguajes se llama de otra forma. Es un detalle cuando ya llevas un tiempo programando en C#, pero al principio necesitas darle una vuelta.   En Swift cualquier tipo puede ser opcional o no. Tienes el tipo “String" pero también tienes “String?". Lo mejor de los opcionales es que te garantiza que cualquier variable que no sea de un tipo opcional tiene un valor sí o sí. En C# eso no pasa porque aunque un tipo no sea Nullable puede que sea null. (Por cierto que creo que eso va a cambiar en un futuro)   Un Task lo tienes que convertir en Observable para poder usar esa sintaxis, lo cuál no quiere decir que puedas usar la misma sintaxis con Observables que con Tasks. Eso es así por diseño, pero supongo que también por limitaciones en el sistema de tipos (que Swift también tiene), no tienes “higher kinged types” como en Haskell. Pero al menos Swift se preocupa de que haya cierta consistencia entre diferentes tipos que cumplen el interfaz que tendría una Mónada.   No es que haya nada que no puedas hacer en C# y en Swift sí. Hay pequeñas cosas que son diferentes de un lenguaje a otro. Para mi mejores en Swift, pero eso es probablemente mi opinión, aunque también algo tendrá que ver que Swift sea un lenguaje más moderno y que no han tenido miedo de romper compatibilidades hasta que han dado con la tecla.   Por citar alguna cosa más: en C# no puedes definir type alias genéricos (no puedes hacer “using MyType<TType> = AnotherType<TType>”). No puedes tener métodos estáticos ni constructores en interfaces. No puedes extender clases (solo métodos). Los enums y los structs son bastante limitados en comparación con los de Swift. No puede definir variables como inmutables (var vs let) y un largo etcétera.   En fin, que no es que haya algo que no se pueda hacer. Todo se puede hacer con cualquier lenguaje (mira Javascript), pero en mi opinión y tras haber trabajado con los dos (eso sí, más en Swift y durante más tiempo), Swift es un lenguaje mucho más amigable.

Ivan Gajate <ivang...@gmail.com>: Jul 31 10:53PM +0200 Jajajaja estaba pensando.... Mira, otro que piensa como Fede... :) No me esperaba que siguieses en esta lista....   En mi defensa, y por alusiones, tengo que decir que se puede conseguir ese feeling nativo con Phonegap, solo que aquí mi menda maqueta como para salir del paso pero... sé que se puede ;p   Y sí, de hacer algo para móviles, yo ahora seguiría tirando de tecnología híbrida. Un saludo.

"Diego Ponce de León" <mala...@gmail.com>: Jul 31 10:57PM +0200 Pues si que es potente el Swift. No conocía algunas cosas que cuentas. No entiendo bien lo de "No puedes extender clases (solo métodos)". ¿te refieres al multi-inheritance? Lo de que todas los tipos sean inmutables por defecto tiene buena pinta, pero ahora mismo me haría la picha un lío si C# fuera así. Variables inmutables: de toda la vida se usa "const" o "readonly" en las properties. Ej: const string algo = "no me puedes cambiar";   Siendo un lenguaje mucho más moderno han atajado problemas de base sin miedo a romper compatibilidades como dices tú. Supongo que pasará lo mismo con Kotlin. Pero yo considero muy importante el número de plataformas, entornos y dispositivos donde un lenguaje ha conseguido penetrar. Y de momento creo que C# es ganador.   Otro punto fuerte es .NET en general. No te gusta C#? pues usas F# y al compilar obtienes el mismo resultado, pudiendo mezclar código en un mismo proyecto. Supongo que puedes hacer algo parecido con ObjC y Swift...   El mar., 31 jul. 2018 a las 22:42, Ricardo Sánchez Sotres (<

Joseba Alonso <7days...@gmail.com>: Jul 31 03:39PM -0700 hey! que a mi me encanta c# :)   On Tuesday, July 31, 2018 at 7:05:18 PM UTC+2, xleon wrote:

Alejandro Can <canale...@gmail.com>: Jul 31 09:29PM -0300 ami mi tambien me va C# pero no tengo mas puntos de comparación   El mar., 31 jul. 2018 a las 19:39, Joseba Alonso (<7days...@gmail.com>) escribió:

Alejandro Cid <ja...@mundoplano.com>: Aug 01 07:52AM +0200 Y a mi :), parece que todos estamos bastante metidos en tema de desarrollo móvil, a mi Xamarin me parece la leche aunque por aquí están de moda las aplicaciones híbridas, ¿conocéis ionic?   Https://ionicframework.com   Saludos.   Alex

"Ricardo Sánchez Sotres" <odr...@gmail.com>: Aug 01 08:16AM +0200 Para extender una clase en C# tienes que crear un método estático. En Swift creas una extensión con la que puedes añadir varios métodos a una clase o protocol (interfaz)   No es que todos los tipos sean inmutables, no es así en Swift. Depende de cómo definas las variables.   var int; // es una variable let int; // es una constante (una vez que le asignes un valor no puede cambiar)   Si te acostumbras a usar let por defecto te darás cuenta de la cantidad de veces que no es necesario que tus variables sean realmente variables. Garantizar que no pueden cambiar añade seguridad a tu código.   Luego está el tema de los opcionales. Puede tener un método que reciba uno:   func greet(name: String?) -> String { guard let name = name else { return “Hello no one”; } return “Hello \(name)" }   En el segundo return tenemos la garantía de que name tiene un valor, por el “guard” de la línea anterior. Pero si en lugar de “String?" hubiéramos pasado “String” sabríamos sí o sí que tiene un valor y no tendríamos que hacer el “guard” (bueno, en el caso de Strings pueden tener un valor y que sea el string vacío, pero eso es otro tema)   Para mi los opcionales son la mejor característica de Swift sin duda. Algo así parece que viene para C# 8, pero eso sí, solo para reference types, es decir no funcionaría con structs o enums. https://blog.cdemi.io/whats-coming-in-c-8-0-nullable-reference-types/   F# Sí que me llama la atención. Espero poder usarlo un día y espero no llevarme la decepción que me he llevado con C#. Que no es el peor lenguaje del mundo, eh? Hay cosas peores, como, por ejemplo, Objective-C, pero en fin…

"Diego Ponce de León" <mala...@gmail.com>: Aug 01 09:51AM +0200 Me hice lío con lo de "extender una clase". En .NET eso se llaman extensiones de método. Extender una clase lo entendí como herencia. Y vale, "obligando" a que un tipo no pueda tener el valor null (sin usar "?") te evitarías tropecientos NullReferenceException y otros tantos null checking por toda la app, cosa que en C# es muy común. Así que te lo compro. Lo acabo de ver como algo necesario. De todas formas, si quieres asegurarte de que un objeto no sea null hoy mismo, puedes usar un struct. Por cierto, creo que esto te va a gustar: https://github.com/louthy/language-ext   El mié., 1 ago. 2018 a las 8:16, Ricardo Sánchez Sotres (<odr...@gmail.com>) escribió:

"Diego Ponce de León" <mala...@gmail.com>: Aug 01 10:04AM +0200 En mi humide opinión, con todas las herramientas existentes hoy en día que producen performance igual o muy cercana a la nativa, usar un wrapper de un webview me parece un despropósito total. No hay excusa para no aprender algo nuevo.   El mié., 1 ago. 2018 a las 7:52, Alejandro Cid (<ja...@mundoplano.com>) escribió:

Joseba Alonso <7days...@gmail.com>: Aug 01 01:11AM -0700 Joder, que gusto leeros a todos :) ¿Nos echamos un herencia vs composición por los viejos tienpos? xD   On Wednesday, August 1, 2018 at 10:04:56 AM UTC+2, xleon wrote:

Pixerama <in...@pixerama.com>: Aug 01 10:41AM +0200 Totalmente de acuerdo Diego. Añado que hicimos hace pocos meses un intento para un proyecto un poco raro de un cliente con Electron y por poco nos cortamos las venas, de hecho terminamos teniendo que desistir. Muy resumidamente, se supone que es crossplatform, y lo que corria en 1 ordenador no lo hacia en otro … Nunca entendí que si estamos embebiendo en la app tirara a trozos del browser que tuviera instalado el cliente...   Por otra parte y siempre lo he dicho, para hacer cualquier cosa medianamente grande y sostenible en lo ultimo que pensaria es en JS.

Volver al inicio

Has recibido este resumen porque estás suscrito a las actualizaciones de este grupo. Puedes modificar la configuración en la página de pertenencia al grupo. Para cancelar la suscripción a este grupo y dejar de recibir correos electrónicos, envía un correo electrónico a asnativos+...@googlegroups.com.