La verdad es que no estoy en contra de ninguno de los dos lenguajes. Pero voy a criticar ciertas cosas de ambos. C# ha copiado inteligentemente muchos de los conceptos que se idearon con Java en cuanto a una programación orientada a clases elegante pero también es verdad que han introducido nuevas cosas para hacer más agradable el trabajo del programador. Una de las cosas que más me han tocado las narices de Java son los casts (supongo que otros compartiran este sentimiento y se habrán facilitado las cosas con Java 1.5). Me refiero a cosas como esta (El código funciona compilando con Java y C#, que casualidad 😉 :
String cadena=»22″;
int numero=Integer.parseInt(cadena);
¿Para qué usar un método estático? No sería mejor algo más intuitivo que lo siguiente:
String cadena=»22″;
int numero=cadena.toInt();
Supongo que en Java 1.5 esto ya estará solucionado de la forma que comento. ¿Pero no sería incluso mejor poder hacer esto?:
String cadena=»22″;
int numero=cadena;
Y que el compilador se encargue de hacer el cast automáticamente si es que se puede. Esto que comento es la eterna discusión entre los lenguajes que te permiten un control total tipo C, a lenguajes restrictivos como Java. Yo pienso que un lenguaje muy restrictivo crea programadores malos porque no saben realmente lo que están haciendo. Por otra parte si el compilador «se lo traga todo» sin avisar haciendo casts a lo bestia puede dar lugar a bugs difíciles de detectar. Lo ideal creo que es poder el escoger el nivel de restricción. ¿Qué pensais que es mejor, que el compilador haga lo que tu quieras (C,C++ …) o hacer lo que te mande el compilador (Java, C# …)?
La última opción hay que desecharla (para eso se programa en PHP y ya está).
A Integer.parseInt(cadena) le veo poco sentido.
Creo que la segunda opción sería la mejor, o quizá int numero = (Integer)cadena;
Respondiendo a tu respuesta, creo que las cosas están bien como están: Poco tipado para códigos scripts, mucho tipado para aplicaciones grandes (varios desarrolladores).
Respondiendo a tu pregunta, claro, no a tu respuesta. jeje
Sin tener ni idea de programación (menos de Java o C#) veo más acertada la segunda de las opciones a la hora de hacer casting (creo que es tan intuitiva como suficiente, la primera parece un poco más enrevesada)
Respecto al nivel de restricción de los lenguajes de programación, creo que cuantas menos ambigüedades generen mucho mejor. Es decir, prefiero un lenguaje totalmente restrictivo a otro más flexible. Y otra razón es la propia «disciplina» del programador, que además tú comentas. Pienso que es mucho más positivo para el programador, aunque a simple vista parezca lo contrario, que se vea obligado a «no cometer ambigüedades» (debido a que el compilador se lo permite) que a que sí pueda cometerlas y, por consiguiente, se cree con el tiempo vicios y malos ábitos.
Otro apunte: creo que para un grupo de desarrolladores el factor de la flexibilidad del código puede influir. Si cada uno programa como le de la real gana, al final creo que será mucho más difícil el saber cómo y por qué el encargado de hacer X módulo ha hecho «esto» y no «lo otro» (no sé si me explico jeje…)
Se que suena un tanto cuadriculado. Pero es que la programación debe tener mucho de eso: de «cuadricidad»
Saludos
¡Ah! y en los comentarios se cita a PHP. Puff… estoy empezando a aprender este lenguaje (bueno, al menos intentar aprenderlo) y vamos… me está pareciendo un poco difícil precisamente por la gran flexibilidad que permite: por ejemplo no declarar las variables o el poderles asignar y reasignar el tipo de valor que te de la gana (joder, me parece una chapuza esto pero en fin…) y luego el poder trabajar con ficheros sin ni siquiera definir descriptores, abrir/cerrar el mismo fichero…
En serio, que prefiero algo como ANSI C que PHP, sinceramente… :\ (o quizás es que al no tener demasiada idea no consigo ver las verdaderas ventajas de la flexibilidad en un lenguaje)
Saludos!
Realmente en C se pueden hacer cosas mucho más burras que en php. En C podemos trabajar con punteros (puros y duros) y asignar lo que queramos donde queramos. (Otra cosa es que el lenguaje sea fuertemente tipado o no, son temas diferentes) Si que es verdad que php es un poco chapucero pero realmente está muy bien pensado para trabajar en internet, fijate en la gran potencia de php para trabajar con cadenas sin tener que preocuparnos de nada. Realmente para crear páginas webs lo que necesitamos es manejar cadenas con eficiencia (Para eso nada mejor que perl).
Por cierto vaya ambientazo que le estas dando al blog con tus comentarios. Gracias 😉
Java como lenguaje de programación de alto nivel la verdad es que está bastante bien pero como todo lenguaje tiene sus pros y sus contras, por no enrollarme:
Pros:
– Multiplataforma (todo lo que hagas en Java, una vez compilado, se va a poder ejecutar estés en linux, windows, mac, o donde sea)
-gestión automática de memoria (el famoso garbage collection)
– un completisimo API donde todos los objetos derivan de Object
Contras:
– Lento de cojones, tanto para compilar como para ejecutar (por suerte este año tengo un ordenador potente y me va bien)
– el recolector de basura (como empieces a crear objetos y objetos se te empieza a petar todo y al final va como el culo)
– tienes que hacer casts para todo, lo cual quita flexiblidad
Lo que los de Sun intentan hacer en la versión 1.5 es precisamente eliminar todos estos contras y alguno más y crear un producto más agradable 🙂
Respecto a C# me parece algo mejor que Java (al menos que Java 1.4, sobre el 1.5 no digo nada porque no lo he probado).
Y luego, sobre C y C++ decir que como todo lenguaje tienen sus pegas, sin embargo, a mi modo de ver son los mejores.
Para empezar, en C++ se compila directamente a código maquina, por lo que va a ser mas rápido. En segundo lugar, no hace falta hacer casts, se supone que el programador sabe lo que hace y si no tiene ni puta idea y dice que una pera es una manzana pues él sabrá lo que hace…
C++ es fuertemente tipado… algunos dirán, pues que putada, no puedo hacer cosas como:
Cadena cad = «123»;
int numero = cad;
Pues no, en principio uno piensa que no… pero imaginemos que ‘Cadena’ es una clase que hemos creado nosotros, pues bien C++ posee algo que creo que se llama funciones de conversión, que consisten basicamente en que podemos definir como transformar un tipo de la clase Cadena en enterno (int). Pongo algo de código…
#include
#include
class Cadena {
public:
Cadena(char *p) { s = p; };
~Cadena() { s = NULL};
int operator int() { return ((s==NULL) ? 0 : atoi(s)); };
char * operator char*() { return s; };
private:
char *s;
}
int main()
{
char *cadena = «127»;
Cadena c = cadena;
/* int entero = cadena; ==> esto petaría 😉 */
int entero = c; /** Esto no debe petar 🙂 */
printf(«la cadena es ‘%s’, el valor entero es %d\n», cadena, entero);
/** Si no se ponen los casts digo yo que el compilador daria error de ambiguedad de tipos **/
printf(«la cadena es ‘%s’, el valor entero es %d\n», (char *)c, (int)c);
return 0;
}
NOTA: el codigo lo he puesto a saco…osea que igual peta, pero la intencion era buena 😉 (probar a compilar con el g++)
Pues eso, que con C++ se pueden hacer muxas cosikas 🙂 y no hay cosa que joda más, que el compilador empiece a quejarse por tonterias…
así que C/C++ Power
Ya me direis que opinais de todo esto ;p
Por cierto, como curiosidad, a esos que les gusta el Java, que me digan como se hace en Java un swap genérico, que valga para cualquier tipo de datos.
En C++ es algo tan simple como:
template
void swap (T& a, T& b) {
T tmp = a;
a = b;
b = tmp;
}
Y este swap vale para enteros, para reales, para cadenas… y para lo que sea… 🙂
Ale, para los que querais ver como se hace en Java… bueno, pues eso, suerte en vuestra búsqueda!! pk no se puede hacer ;p
Como veis en C podemos hacer lo que queramos, el incoveniente es que nos lo tenemos que montar todo nosotros. Por cierto Amnio es la ostia programando así que aprended de sus consejos, gracias a él tenemos un 10 de nota final en Cálculo Numérico (Una optativa durilla que nos hemos cogido este año).
Estoy a favor del cast forzado. Porque soluciona un problema crucial: para alguien que lee el código que otro escribió es IMPOSIBLE saber si la persona quiso convertir a int o si es un bug. ESA es una razón crucial para que los lenguajes de alto nivel (no los usados para scripting) «sobre definan» cosas. Me ha pasado demasiadas veces estar revisando código durante HORAS para intentar deducir si el que lo escribió realmente QUISO hacer algo (y yo lo veo raro porque no entiendo su punto de vista o no entiendo del todo el problema a resolver) o si se distrajo al escribir el código.
uhm…pues la verdad es que me parece bte interesante la afirmación de Xtian, no lo habia pensado nunca, pero una vez leido creo que comparto su opinión.
Además ahora os planteo otra cuestión, no se si os pasará a vosotros, pero realmente cuando programo donde pierdo mucho tiempo es en ‘fallos tontos’.
Especialmente recuerdo un fallo tonto de hace un par de años que me llevó casi 2 dias solucionar, y que para colmo era simplemente por haber definido una variable como «long int» y debía haberla definido como «unsigned long int». Además, reflexionando sobre ésto, me doy cuenta que realmente tardé tanto en identificar el problema por no comprender bien todo lo que pasaba por detrás, no entendía porqué sacaba valores incorrectos y mirava y volvia a revisar el codigo y no lo veia, hacia trazas y no lo veia… no se, la verdad es que es importante comprender lo que uno está programando y cómo lo está programando 😉
No se, y también pienso que a veces, cuando me pongo a buscar un fallo y no lo encuentro, llega un punto que empiezo a emparanoyarme de tal forma que empiezo a imaginarme cosas tan raras que no tienen ningún sentido, pero aún así les doy validez y pruebo cosas absurdas a ver si se soluciona el problema. Luego al rato descubro que no, que era una cosa más simple que todo eso y me quedo con cara de gilipollas diciendo vale, porque he perdido tantas horas probando esta serie de cosas absurdas.
¿a alguien le pasa esto tb? ¿que opinais?
Bueno, un saludo!
Conociendo Java y C#, me parece bastante mejor pensado C#, y como prueba, solo hace ver que en la nueva version de Java aparecen bastantes cosas que ya tiene C# ( metadatos, eliminacion de casting, etc. ). Las propiedades de C# es una buenisima idea y que decir de los formularios de .NET. Con dos propiedades anchor y docking consigues lo que con Swing necesitarias un monton de código.
Falta por ver como serán los templates de C#, los de Java son distintos a los de C++.
A mi parecer ambos tiene sus filosofia, por lo menos Java fue pensado para q programadores novatos no pudieran meter la pata, y C/C++ siempre fue para programadores q supieran q es lo q estan haciendo (ie, gente + pro), en cuanto a los cast de Java yo no los veo del todo mal, eso garantiza codigo muy robusto.(ojo no estoy en contra de C/C++, es mas me parece mucho mas potente).
Si quisieramos diseñar un lenguaje de programacion que este mas ligado con el pensamiento o la idea del programador (como para evitar ciertos errores simples y que pasan desapercibidos), tendriamos que llegar al punto en que el lenguaje tuviera que analizar un algoritmo(por ejemplo…) de la misma forma en que lo hace el programador y bueno pues todos los programadores no piensan igual tendria que existir un lenguaje para cada programador y eso creo que no lo tienen ni los extraterrestres, es por eso que las restricciones en un programa deben existir para dar una idea logica (o al menos hasta que se pueda implementar un automata finito no deterministico para compilarlos y que sepa diferenciar ambiguedades), asi que como algo muy elemental mejor nos adecuamos a un lenguaje al cual programar teniendo en cuenta sus restricciones. ( claro que criterio de cada programador) Ojala Bordland desarrolle un compilador para Java (o creo que ya lo esta haciendo,…..disculpen si es asi, pero desconozco de esa situacion., jijiji, viva Java carajo…!…..pero debajo de C, jijiji)…
Que os parece una linea de codigo como:
‘\n’.join(lista)
Juas, a mi me mola mucho!
Pues es python. Despues de estar liado con el C# desde que salio la 1a beta del visual studio.net me pase al python y ya no hay vuelta atras, jeje
Saludos
PD: necesito una invitacion de orkut (se la he pedido a Hector – que se ofrecio en un post – pero aun no ha contestado)
Respondo a la pregunta sobre el método estático, ¿Que sucede si añadimos una nueva clase numérica MiInteger? ¿Tenemos que modificar String para que sepa transformar cadenas a MiInteger? De ser así ¿No parece un poco raro que sea String quien cree MiIntegers? En ese caso String se estaría metiendo en la tarea de MiIntegers y eso es un muy mal diseño.
Aún así reconozco que el método es algo incordioso de escribir, pero es el mas elegante y flexible en cuanto a diseño.
Un saludo, sigue con el blog que me encanta, a ver si algún día puedo viajar a Japón y comprobar lo que escribes por mi mismo.
Respecto a lo de «ya veremos como son los generics/tenplates en C# y en Java», te puedo decir que en Java no son generics reales, en realidad se siguen usando colecciones de Objects internamente, con lo que la eficiencia es muchísimo menor que en C#, donde sí puedes tener colecciones genéricas con valuetypes(además de restricciones en los tipos que puedes instanciar)
No confundamos. En C#, el método
ToString()convierte cualquier objeto a String, pero es deSystem.Object(y, por tanto, hereda todos los tipos y clases del sistema). Su función es la de tener un texto identificativo de cualquier cosa (si un objeto no lo tiene implementado, devuelve el nombre de la clase de dicho objeto).Es decir la función de
ToString()no es pasar el elemento a un tipostring, sino la de devolver un texto identificativo (evidente y circunstancialmente de tipostring) del valor de la instancia a la que se aplica. Lo que sucede es que los tiposint,short, etcétera, lo que devuelven en respuesta al método es su propio valor pasado a cadena.Carece de lógica implementar un
ToInt(),ToShort(), etcétera, para cada clase o tipo nuevo que se haga por dos razones: primero y como ya se ha dicho, si surge un tipo nuevo es necesario incluir el nuevo método de conversión en todas las clases de representación de tipos; segundo, resulta absurdo cargar las instancias con métodos que siempre funcionan igual y que, por tanto, son candidatos a ser estáticos para no ocupar tanta memoria.En cuanto a la carga de código por uso de casting explícito, es cierto que ocurre, pero también es cierto que, una vez que te acostumbras, es igual de inmediato escribir
i=int.Parse(s);quei=s;, siendo más peligroso lo segundo.Un saludo y enhorabuena por la página.