El hilo del ocaso de Unity

[zhorro]

C#. No tengo claro si lo diseñó M$ o si venía de antes, pero es una mezcla entre C++ y Java. Tampoco es lo más eficiente del mundo, pero poder usar listas con LinQ como si fueran BBDD (ordenar, obtener un rango de elementos, buscar en base a varios criterios...) es una bendición que no sabes la de tiempo que te ahorra.

Y ya puede ser bueno el tal Javo: fue el primer traductor oficial de Godot al español
Así aprendí yo DIV2, me leí entero el manual, casi función por función, por lo que cuando quise empezar, ya más o menos me conocía todas las funciones del lenguaje

El C# fue la respuesta de microsoft a Java y por mi parte se lo pueden meter por lo oscuro, solo teniamos una aplicación en windows y heredo todos los problemas de versionado de visual basic.

-----Actualizado-----

Han despedido al anormal que quiso instaurar la runtime fee, el mismo anormal que echaron de EA por ser un pesetero de mierda. A ver en que compañía acaba, espero que en ninguna.

En Capcom que fueron los que iniciaron esta epoca de micropagos y dlcs de pago

[Drumpi]

El C# fue la respuesta de microsoft a Java y por mi parte se lo pueden meter por lo oscuro, solo teniamos una aplicación en windows y heredo todos los problemas de versionado de visual basic.

Como desarrollador que ha trabajado con Java, que mantiene un proyecto en VB6, y que actualmente trabaja en C#.NET y con proyectos de compañeros en VB.NET te digo que, actualmente, C# me parece una forma muy cómoda de trabajar. Podemos discutir si es más o menos eficiente, pero la sintaxis, mucho más simple que C++, el sistema de clases y el no tener que estar peleándome con punteros (algo que manejaba día a día con BennuGD, y que aún tengo pesadillas de mis tiempos de C) creo que es el mejor compromiso que he visto entre facilidad, eficiencia y lenguaje estricto... por mucho que me duela en el alma admitirlo.

Ahora bien, si quieres, lo discutimos como personas civilizadas. Total, yo no me considero un "master race" de programación (mientras no digas nada malo de Fénix o BennuGD ).

[masteries]

C# me parece una forma muy cómoda de trabajar. Podemos discutir si es más o menos eficiente, pero la sintaxis, mucho más simple que C++, el sistema de clases y el no tener que estar peleándome con punteros (algo que manejaba día a día con BennuGD, y que aún tengo pesadillas de mis tiempos de C) creo que es el mejor compromiso que he visto entre facilidad, eficiencia y lenguaje estricto...

Jo, qué maravilla; los punteros son tu mejor amigo y el peor enemigo al mismo tiempo

Cuando te sales del mundo de los computadores de propósito general, ya sean PCs, Raspis... la cosa cambia mucho, y ya tienes suerte si existe compilador de C que funcione en condiciones;
hay entornos de compilación (comerciales) para determinadas arquitecturas que siguen usando compiladores del año 91 o 92, y para ello tienen una máquina virtual con DOS 5.0 por detrás...

no quieras saber lo mal que funciona todo eso, y la de problemas que dan esos compiladores, a veces intentan compilar los comentarios, y las muchas veces no reconocen bien determinadas estructuras de código (como un switch dentro de una claúsula else if) y generan código chungo cuando las encuentran xD

[swapd0]

A mi el C# con .NET me parece lentorro, donde trabajaba estabamos haciendo una aplicacion y al mostrar una ventana habia un delay como de medio segundo, mientras que en una aplicacion parecida que hice en C++ con wxWidgets era instantaneo.

Nunca entendi las quejas con los punteros, pero vamos, si trabajas en C++ usas los std::shared_ptr y std::unique_ptr y asunto resuelto en caso de que seas un desastre y pierdas memoria.

[Drumpi]

Jo, qué maravilla; los punteros son tu mejor amigo y el peor enemigo al mismo tiempo

Cuando te sales del mundo de los computadores de propósito general, ya sean PCs, Raspis... la cosa cambia mucho, y ya tienes suerte si existe compilador de C que funcione en condiciones;
hay entornos de compilación (comerciales) para determinadas arquitecturas que siguen usando compiladores del año 91 o 92, y para ello tienen una máquina virtual con DOS 5.0 por detrás...

no quieras saber lo mal que funciona todo eso, y la de problemas que dan esos compiladores, a veces intentan compilar los comentarios, y las muchas veces no reconocen bien determinadas estructuras de código (como un switch dentro de una claúsula else if) y generan código chungo cuando las encuentran xD

+1 a lo resaltado en negrita. El programador que no sabe trabajar con punteros, está condenado. Por eso, el trabajar con clases es una bendición, porque ya lleva los punteros de forma implícita: cuando pasas una clase por parámetro, no pasas una copia, sino un puntero a dicha instancia; lo mismo si pasas una List o un Dictionary.
Para un sistema de pocos recursos, estoy de acuerdo que los punteros son "el camino", pero para una aplicación de escritorio ¿Para qué hacer una cola con punteros, si te pueden dar ya hecha una implementación de una List de tipo <object> o del tipo que quieras, y puedes meter en ella lo que te de la gana? Máxime si usas LinQ, que parece que trata ese espacio de memoria como una tabla relacional ¿se llamaba así? Como si fuera una BBDD, cuyos accesos son aún más rápidos que andar recorriendo una lista buscando elementos. ¿Sabes el tiempo que me ahorra algo como esto?

listaFiltrada = miLista.Where(x => (x.quantity > 0) && (x.date >= DateTime.Today));

Ya, sobre compiladores cruzados y demás, en eso me llevas mucha ventaja. Yo sólo he usado algunos, y ya estaban preparados para el sistema. Podemos discutir si eran más o menos cómodos, porque la mayoría que he usado eran para Linux, y en Windows tenía que ponerme a hacer instalaciones del MINGW o como se llamara la ventana de comandos con el cmake y demás herramientas portadas a Windows.

A mi el C# con .NET me parece lentorro, donde trabajaba estabamos haciendo una aplicacion y al mostrar una ventana habia un delay como de medio segundo, mientras que en una aplicacion parecida que hice en C++ con wxWidgets era instantaneo.

Nunca entendi las quejas con los punteros, pero vamos, si trabajas en C++ usas los std::shared_ptr y std::unique_ptr y asunto resuelto en caso de que seas un desastre y pierdas memoria.

¡Oh! ¡Dios mío! Un delay de medio segundo en una aplicación de escritorio...
Primero, el tío que usa la APP le da igual, porque de ordenadores sabe lo justo para pasar el día. Segundo, que no tiene más remedio que usar esa aplicación porque le viene impuesta (no veas las atrocidades que se hacen en diseño en favor de la "funcionalidad", o de entregar lo antes posible). Y tercero, cambiad de equipos porque esos equipos van lentísimos, en medio segundo me carga una página web hecha en .NET Core, contanto con el delay de carga de datos en red

A ver, que soy el primero que dice que .NET no es óptimo, y el primero que odia el exceso de recursos consumidos... pero compensa lo que acorta los tiempos de desarrollo, la depuración y la ampliación (yo venía de programar BennuGD en Notepad++ sin debuger, y en cuanto aprendí a usar VS, era el rey cazador de bichos, y un rayo programando).
En ese compromiso, me parece buena herramienta, a falta por conocer alternativas mejores. Y ojo, que con Java, que era parecido, no opinaba lo mismo: el entorno era lentísimo, y los resultados aún más.

Las quejas con los punteros son muy simples: si no los conoces, puedes hacer burradas, provocar un error, y tardar horas en encontrarlo si no sabes depurar. Se te cae el programa y no sabes por qué, hasta que te das cuenta que al borrar elementos de la lista, la estás recorriendo de principio a fin, y se te está saliendo el índice al final de la lista, o puede que hayas puesto un <= en lugar de < en otra parte del programa.
Son muy peliagudos, y el segundo reto del novato, después de instalar el entorno de desarrollo y hacer que funcione el "hola mundo". Son algo demasiado abstractos para el común de los mortales.

Es lo mismo que con los hilos: .NET tiene una herramienta que los simplifica, el "async-await", y después de 3 años trabajando con ello, aún hoy estoy descubriendo los problemas que pueden dar. Ayer encontré uno muy curioso con las funciones que gestionan los datos de retorno, dentro de un bucle. Menos mal que, de nuevo, acostumbrado a BennuGD y a pensar en procesos, pude averiguar la razón en un par de segundos tras analizar los valores del debugger.


Pero es lo que dice todo el mundo: la herramienta adecuada para cada problema (foto del Chuache).

[swapd0]

¡Oh! ¡Dios mío! Un delay de medio segundo en una aplicación de escritorio...

Si, apenas es nada, pero si coges una aplicacion que cada vez que se muestra un nuevo dialogo, lo hace de forma instantanea, se te hace menos incomodo. Parece una tonteria pero cuando llevas un buen rato, se agradece la agilidad.

-----Actualizado-----

PD: la aplicacion en .NET la solia correr en un ordenador mas moderno, con mejor CPU y mas memoria que el mio, y a pesar de eso iba peor.

[Drumpi]

No, si eso lo entiendo. Está claro que cuanto más ágil sea el programa mejor. Sólo intento mostrar el punto de vista que, a lo mejor, ese "medio segundo" no compensa que el desarrollo pase de durar una semana a dos, especialmente si después, encontrar un fallo se tarda 6 horas en lugar de 3, especialmente si el que tiene que arreglarlo no es el que escribió el código en primer lugar.

Sobre el PD, ni idea.

[zhorro]

Como desarrollador que ha trabajado con Java, que mantiene un proyecto en VB6, y que actualmente trabaja en C#.NET y con proyectos de compañeros en VB.NET te digo que, actualmente, C# me parece una forma muy cómoda de trabajar. Podemos discutir si es más o menos eficiente, pero la sintaxis, mucho más simple que C++, el sistema de clases y el no tener que estar peleándome con punteros (algo que manejaba día a día con BennuGD, y que aún tengo pesadillas de mis tiempos de C) creo que es el mejor compromiso que he visto entre facilidad, eficiencia y lenguaje estricto... por mucho que me duela en el alma admitirlo.

Ahora bien, si quieres, lo discutimos como personas civilizadas. Total, yo no me considero un "master race" de programación (mientras no digas nada malo de Fénix o BennuGD ).

He trabajado con C y C++ y no solia tener problemas con los punteros pero quiza sea que llevo muchos años con el, con java y muchos problemas con la memoria y la lentitud (come maquinas para desayunar), con C# en windows y muchos problemas de compatibilidad con las versiones de los runtimes/librerias igualito que en visual basic y desplegar la maldita aplicación en un monton de puestos era una loteria, al final hubo que ponerla en un servidor remoto para evitar esos problemas a costa de pagar un pastizal por las licencias. Por eso C# lo mas lejos posible (aparte de ser un lenguaje propietario de Microsoft)

[Drumpi]

¿C# problemas de compatibilidad? Será que yo no he tocado el entorno de desarrollo en años, pero hasta ahora, ninguna máquina ha tenido pegas con lo que he programado. Vale que el 45% eran programas Xamarin destinados a móviles Android, otro 45 eran las WebApis que dan servicio a dichas APPs (WebApis desplegadas en sistemas en el que nosotros hemos hecho la instalación del IIS y de lo que necesita para funcionar), y apenas dos o tres proyectos han sido aplicaciones de escritorio para alguna utilidad concreta. Mis compañeros sí que se dedican a hacer addons en vb.NET para el ERC, y tampoco han tenido problemas.
Será que todos los equipos tienen el .net 4.5 instalado por nosotros, y el Windows Update se encarga de tenerlo al día.

Ya digo que el que ha trabajado con punteros, sabe de qué va la cosa y los errores más habituales. Yo no los he usado desde hace más de 5 años, y no hace mucho estuve ayudando a un novato en el foro de BennuGD a manejarlos. Pero eso no quitan para que sigan siendo un peligro, y créeme, con la cantidad de código y de operaciones que tienen los proyectos que estoy manejando, lo último que quiero es andar de pelea con ellos.

Pero bueno, ya he descargado Godot con soporte para C#... aunque en realidad, el soporte que tiene es de Mono, por aquello de hacer que funcione en Linux y esas cosas

[chipan]

Los punteros eran un mal necesario cuando los ordenadores no tenían apenas recursos y había que usarlos para acceder directamente a las posiciones de memoria en lugar de (por ejemplo) reservar más memoria para trabajar con un duplicado de esos datos. Pero a día de hoy son un **** atraso en el 99% de los casos.

[masteries]

Los punteros eran un mal necesario cuando los ordenadores no tenían apenas recursos y había que usarlos para acceder directamente a las posiciones de memoria en lugar de (por ejemplo) reservar más memoria para trabajar con un duplicado de esos datos. Pero a día de hoy son un **** atraso en el 99% de los casos.

Creo que esa es la razón por la que sólo haya compiladores de C para las arquitecturas embebidas, al final, casi todo lo que escribes o son drivers para hardware; que viene a ser mucho acceder a posiciones de memoria que son registros, o son operaciones intensivas sobre arrays o matrices, donde tomar punteros si presenta una ventaja a nivel de ahorrar ciclos de reloj.

Pero para pasar un único dato o un par de datos como argumento a una función, pues no notas diferencia ni aún midiendo el tiempo en ciclos de reloj.


Como se nota los que programáis para PCs o computadores de propósito general; podéis reservar memoria; en mi mundo usar un "malloc" es algo prohibido, aunque la función existe y está implementada, como no garantiza un retorno con éxito, no puedes utilizarla; y suerte tienes cuando dispones de 1 MB de RAM

Y los compiladores de C++ para esas arquitecturas, al final no acaban de estar plenamente soportados, tienen soporte parcial,
o las normas de codificación que tienes que seguir se pegan de frente con las características de C++


Para PC, lo más reciente que programé (y hace más de un año), fué un driver para un dispositivo USB personalizado;
y eso iba directo junto al kernel de Windows y cómo accedes al hardware del chipset USB del PC; pues C y punteros xD

[swapd0]

¿Retraso? Si paso una imagen a una funcion que aplica un blur, lo normal es que le pase un puntero a la imagen y la funcion realice el blur sin hacer ningun tipo de copia. La solucion que propones es hacer una copia y pasarla a la funcion, despues si quiero machacar la imagen original con el resultado tengo que hacer otra copia... Muy lento.

En muchas arquitecturas el hardware esta mapeado a unas direcciones de memoria, si tienes que hacer un driver, ¿como voy a decirle a la tarjeta grafica, a la controladora del disco duro, o tarjeta de sonido que quiero activar a un determinado modo si no tengo un puntero que apunte a ese registro?

El problema de los punteros es que no se enseña a programacion de forma correcta, te dan un curso de python o java sin explicarte como funciona un ordenador, que las variables u objetos que creas parece que estan en el limbo y no importa si creas miles de ellos. He visto codigo para manejar matrices para graficos 3D (o sea matrices de 4x4 nada de matrices de cualquier tamaño) y crear los valores en el heap (usando new) en vez de crearlos en la pila.

[fbustamante]

Yo me crié con punteros y trabajar de otra forma me parece lo mismo que tirar comida porque tenemos mucha.
Así tenemos actualizaciones de 100 Gb y programas que no sabes dónde correrlos porque no van finos en ningún lado.

[futu-block]

ese es el problema, el de los transistores que aumentaba de tamaño cada dos año (o algo de eso)...
total, que cada vez tenemos mas memoria, mas capacidad de almacenaje, mas velocidad a la hora de hacer cálculos, mas etceteras que hacen que nuestro proyecto sea un almacén de 500 mil metros cuadrado con maquinarias de todas clases posibles y recursos ilimitados...

ya no optimizamos, aunque sea un poquito, las cosas las hacemos al pimponazo, da igual...

[zhorro]

Los punteros eran un mal necesario cuando los ordenadores no tenían apenas recursos y había que usarlos para acceder directamente a las posiciones de memoria en lugar de (por ejemplo) reservar más memoria para trabajar con un duplicado de esos datos. Pero a día de hoy son un **** atraso en el 99% de los casos.

Y que te impide en C pedir memoria dinamica para duplicar los datos, aunque me parece que es una perdida de recursos duplicar los datos y no trabajar directamente con ellos. Atraso para mi es utilizar un lenguaje como python que es lo mas ineficiente que pueda existir o java para un backend o batch. Aunque a dia de hoy es raro utilizar C puro, es mas normal utilizar C++.