A corto plazo suele servir pegar componentes e incluso no programar nada y hacer una planilla Excel, pero Smalltalk es rentable a largo plazo. (contesto mas abajo)
>On Nov 11, 4:30 am, Giuseppe Luigi Punzi <[email protected]> wrote: > Si, está claro, > > Pero veo un error en algunos casos, implementar algo nuevo, cuando con algo > existente, sobra. Pensemos, que no todos los proyectos son grandes y en los > que sale rentable tener que programarnos todo. Si tengo un proyecto en el que > los informes los uso para dos o tres cosas nada más, resulta más rentable y > eficiente usar una solución existente, sobre todo, si ésta está bien hecha y > es > potente, antes que tener que desarrollar la mía propia (y además desarrollar > mi propio driver para la impresora que también sería más eficiente que usar el > existente), o si lo extrapolamos, desarrollar también mi propio sistema > operativo ya puestos. Podés moverte de forma gradual, podés empezar por un tool de reportes, luego encargarte de escribir manualmente el contenido y dejarle el formato e interacción con el entorno a tools menos rígidos como procesadores de texto o formatos estándar, luego podés hacerte cargo de esa parte también y dejar solo el sistema operativo (y no tenés que escribir drivers de impresión porque son temas del OS). Y si finalmente se te ocurre hacerte un sistema operativo no te reprimas, lo propuso Dan Ingallas hace unos 30 años y conozco a varios smalltalkers de esta lista que lo han encarado, con mayor o menor éxito. > Cuando yo me compro un coche, le compro ruedas, no me las fabrico yo, porque > no sería rentable ni tengo los medios/conocimientos. Algo que tienen los smalltalkers es una soberbia sana, una sensación de que se puede hacer todo y una falta de respeto por todo. No hablo de fanatismo ni de criticar desde la tribuna (que también existe), sino de proyectos reales hechos en Smalltalk en donde se resuelven cosas que cualqueir programador no se atrevería ni a meterse. Y esto no es porque los smalltalkers sean gente inteligente ni mejor preparada, yo creo que es porque la exposición a un ambiente que puede lidiar con ciertos grados de complejidad lo acostumbra a no ver complejas a cosas que encaradas desde otras tecnologías lo son. Cuantos sistemas administrativos de facturación hechos en VB/PB/JS/ Java/PHP/C/C++/C#/.NET/etc viste que se hayan hecho sus propios sistemas de reportes, o su propio esquema de persistenacia, o sus propios protocolos, servidores, engines gráficos o hasta compiladores, parsers y maquinas virtuales??? yo diría que menos del 1%, sin embargo en Smalltalk es muy natural verlos y no es porque seamos ciegos o no podamos conectarnos a componentes, o nos sobre el tiempo o no nos interese la rentabilidad, es porque el tiempo nos demuestra que es mejor, mas rentable y porque nos sentimos con los medios y conocimientos para hacerlo. > Es muy bonito y educativo que en smalltalk se pueda hacer de todo (y me > encanta saber que tengo todo el sistema a mi merced para hacer cambios), pero > realmente, al menos para aplicaciones de gestión (estándar), dudo mucho que > tenga que llegar al punto de tener que modificar la VM, u objetos internos del > sistema, o tener que implementar un motor de reportes de cero, para un > propósito tan general, como hacer 25 pedidos, 30 albaranes, y 20 facturas. > > Quiero decir, que quizás, para mis propósitos, o por aprender, me embarcaría > en alguna manera de creación de reportes que fueran serializados a disco para > poder modificar desde otra herramienta, que supiera interpretar esos reportes, > y el cliente final pudiera modificarlos fácilmente a placer, pero no sé hasta > qué punto, sería rentable existiendo soluciones para ello (pongamos iReport o > CrystalReports como ejemplo), que ya llevan años de desarrollo especializado > exclusivamente en este tema. Durante unos 5 o 6 años usé Crystal Reports (desde la 2 a la 6), hace unos 10/15 años. Una vez, habia hecho un sistema bastante grande para el BID y Ministerio de Economía, hacía reportes de todo tipo y muy lindos. En un listado de facturas que tenía varias páginas y ciertos formatos, me pidieron que abajo de cada página les pusiera el total por página y el pedido era muy lógico, ya que los contadores firman esos reportes y deben verificar manualmente lo que están firmando. Crystal no tenía tal funcionalidad y era muy dificil cocinar una solución alternativa, porque el tamaño de la página era impredecible, porque meter subtotales era impracticable, y por muchas otras razones. Todo lo que me ahorre por usar Crystal lo perdí ahi, en ese 1% de funcionalidad que no pude resolver. Ese tipo de anécdotas me llevaron hoy a tener mis propias soluciones, si querés te paso alguna receta. > Un saludo, conversación interesante. Otro, Diego Coronel > On Thursday 11 November 2010 02:40:14 [email protected] wrote: > > > > > > > Hola, > > Esto lo escuché muchas veces... > > > On Nov 9, 12:06 pm, Giuseppe Luigi Punzi <[email protected]> > > > wrote: > > > Ahora que tengo un poco más de tiempo puedo explayarme :P > > > > Hace tiempo, me digeron una vez...para qué reinventar la rueda, si ya > > > existe algo que está muy bien hecho? > > > De los miles de modelos de autos que se inventaron (y de cualquier > > cosa que tenga ruedas), casi ninguno usa ruedas iguales. Las ruedas > > son redondas y sabemos cómo funcionan, pero en muchas oportunidades > > (casi todas) es bueno volver a construirlas. Con Smalltalk sobra poder > > para hacer practicamente cualquier cosa, a veces meter un componente > > puede ser una solución de corto plazo, pero a largo plazo conviene > > programar mas y pegotear menos. > > -- > -- > Giuseppe Luigihttp://www.lordzealon.com- Hide quoted text - > > - Show quoted text - -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
