Horst H. von Brand escribió: > >>> OOP es para problemas >>> /muy/ grandes, en otras cosas es un perfecto desperdicio. Y como el mechon >>> promedio escribe programas de una a dos docenas de lineas, no uno o dos >>> centenares de miles de lineas, ... > >> El problema posterior es exorcisarlo para que pueda aplicar OOP y sea >> capaz de abordar aplicaciones reales. > > Y? Acaso con hacerlo escribir una funcion en una clase que lee 3 numeros y > escribe la suma sabe OOP? >
Lo que muchos se la creen... >> Tengo una opinion muy humilde >> y personal y es que la cantidad de desastres que se ven en OOP son porque >> a la hora de tener que usarlo, el personaje en cuestion tiene poca >> experiencia en OOP > > "No tiene la menor idea de que se trata" suele ser mas cercano a la > verdad... > >> debido a su "deformacion profesional" y no es capaz de >> reconocer cuando esta cayendo en cosas como over-design/engineering. > > En eso cae todo mal profesional. Y, lamentablemente, la inmensa mayoria de > los "programadores" debieran dedicarse a plantar papas, asi resultarian mas > productivos para la sociedad. > Triste pero cierto... >> Si >> los niños aprendieran desde mechones que la mejor solución no es >> necesariamente la que se le ocurrió, y que existen patrones de diseño >> requetecontraprobados las cosas serían muy distintas. > > Metele en la cabezota a un mechon (o no tanto...) que lo que intenta hacer > esta requete-recontra-hecho... metele en la cabeza al profe correspondiente > que la gente no /escribe/ programas, /modifica/ programas, o debe trabajar > /en el estilo/ o /con lo que trae/ el ambiente en que trabaja... > Ese es una de las discusiones que siempre encuentro .... En realidad la enseñanza de la programacion deberia aplicarse en ese sentido, uno en realidad haciendo un software a medida se toma mucho tiempo en I+D y la reusabilidad tiende a cero. ademas de las enormes pifias que puede contener ese codigo... IMHO creo que el enfoque deberia ir por motivar a los alumnos a integrarse a un proyecto y ahi "IN SITU" aprender como es una buena programacion, y como es mas beneficioso tanto en conocimiento, seguridad y productividad el utilizar lo que otros (muchos muchos) han probado y archiprobado que es efectivo y eficiente y de ahi recien empezar los efuerzos para Ampliar o Reutilizar parte del codigo conocido para algun fin especifico. .... El Kernighan y Ritchie "The C Programming Language" es un > clasico, con merecida razon. Libros como el "Software Tools" de Kerighan y > Plaugher (no la version en Pascal!) son escenciales para aprender a > programar bien. Y en <http://www.lysator.liu.se/c> hay harto sobre la > cultura C. Muy interesante referencia, gracias. -- .:: Pedro:G:M ::. Linux User #397462 From [EMAIL PROTECTED] Tue Dec 4 15:35:20 2007 From: [EMAIL PROTECTED] (Leonardo Soto M.) Date: Tue Dec 4 15:38:17 2007 Subject: Benchmarking en distintos lenguajes In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Dec 4, 2007 2:30 PM, Franco Catrin L. <[EMAIL PROTECTED]> wrote: [...] > He visto aplicaciones grandes escritas en C (en empresas), y el > problema con dejar eso en manos de la voluntad del programador es que > se pueden perder horas o dias porque algun pastel olvido poner un "*". > > En el caso de C# y Java no puedes mezclar tipos con y sin referencia, > por lo tanto no existe tal mezcolanza. Pero tuvieron la mala idea de permitir referencias nulas por todos lados, por lo que en la práctica igual se da una mezcolanza de referencias buenas y referencias nulas. Y se pierden horas por que algún pastel devolvió un null donde no debía... > O es o no es, y el programador > tiene que ser muy explicito cuando quiera que eso que es, deje de > serlo. (boxing/unboxing). Los amigos de Sun no encontraron tan cool esta parte, y ahora (Java 1.5+) el boxing/unboxing lo hace el compilador de forma implícita, por lo que todas estas cosas son válidas int i = new Integer(8); Integer i = 8; map.put("foo", 8); int j = map.get("foo"); -- Leo Soto M. http://blog.leosoto.com
