Orcas y la compatibilidad hacia atras

Cuando el constructor ya va por la planta 10, el cliente le dice al
arquitecto que tienen que ser 3 sótanos y 25 plantas. El arquitecto
rechaza eso y le dá al cliente dos opciones: tirar lo hecho abajo y
empezar con un nuevo diseño o aceptarlo como se había acordado. Y
todo el mundo entiende eso. En sistemas informáticos se aceptaría el
cambio como lo mas normal del mundo, porque 'es solo questión de
(re)programar' sobre lo que ya se tiene.
Y la moraleja no era 'mira que listos y flexibles somos' sino que
nuestra profesión todavía tiene que madurar mucho.

Yo no pienso que en informática sea lo "normal" aceptar cambios radicales de
diseño durante el desarrollo de un software. Peor aún yo creo que es malo
por ser muy caro para el desarrollador trabajar bajo esos esquemas de
flexibilidad forzada. Un carro es un carro y un camión es un camión.
Es la diferencia clásica de análisis respecto al diseño. El "qué" versus el
"cómo".
La meta debe ser tratar de invertir mayor tiempo en definir y hasta
"descubrir" las verdaderas necesidades del usuario antes de siquiera pensar
en empezar el diseño y mucho menos la programación. Y luego de empezado,
aplicar patrones para hacerlo flexible a futuro en cuanto a cambios de
FORMA.
Lo dice en los libros, la vuelta a atrás en las etapas del desarrollo es
mucho más traumática y costosa mientras más lejos estamos de la etapa
inicial.
Sí... y en cierta forma lo mismo aplica a MicroSoft con sus "nuevos y
revolucionarios" productos diseñados teóricamente para nosotros, sus
clientes.


Rafael

Hola, Carlos!

Supongo que la condición del join es implícita.

No, en C# 3.0 no va a ser implícita. No sé si tenga algo que ver con esto el
hecho de que LINQ está pensado para atacar a cualquier colección de objetos
y no necesariamte datos relacionales.

Aquí volvemos a caer en el tema q ya hemos hablado otras veces de la
diferencia de puntos de vista entre los que se acercan al problema desde los
lenguajes OO y los que provienen del mundo relacional. Me pensaba escudar en
la especialización estrecha que generalmte impera en los EEUU, pero me he
dado cuenta de que varios de los líderes de ese proyecto son europeos :-)

Saludos - Octavio

En Mon, 25 Jun 2007 20:11:17 +0200, Carlos M. Calvelo
escribió:

Hola RFOG,

On 25 jun, 19:16, RFOG wrote:

Desde mi punto de vista estamos en la época pre-galileo/newton de la
informática. Falta algo, falta una teoría coherente de todo esto...

Me refería claramente a otras tecnologías, ingenierías (ingeniería
civil,
electrónica, arquitectura, mecánica, robótica, etc.), no a la ciencia
en si porque la informática tampoco lo es.

En ese caso sí. Ahí todo es medible y calculable sin problemas (es un
decir). Si algo se cae o falla es porque ha habido un error en el cálculo
o lo que lo ha producido ha excedido los parámetros límite con los que se
diseñó/construyó.

Pero... muy bien dicho!!! Si señor... estamos en la era Euclides :-)
(con mil perdones a Euclides, que no se merece esta comparación)

Je je. Triste pero cierto. Llevamos ciento cincuenta años de informática,
desde la máquina analítica de babbage y las cosas de la señorita Ada de
Lovelace. Y de informática moderna unos cincuenta o así.

Saludos,
Carlos

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programación: http://geeks.ms/blogs/rfog
Libros, ciencia ficción y programación
El futuro pertenece a los que se preparan para él.

Hola Octavio,

On 25 jun, 20:51, "Octavio Hernandez"
wrote:

Hola, Carlos!

>Supongo que la condición del join es implícita.

No, en C# 3.0 no va a ser implícita.

No me refería a 3.0 sino a este ejemplo de Alfredo, representando
como el quería que fuera:

grid.DataSource = (customers join orders) { Name, Date, Total };

Del que tu has dicho que le faltaba la condición. Vamos... he
deducido que te referías a ese ejemplo. A ver si he metido ahí
la pata? Y mi interpretación es que Alfredo se refiere al join
natural (con condición implícita, atributos comunes).

(Solo para evitar desentendidos.)

No sé si tenga algo que ver con esto el
hecho de que LINQ está pensado para atacar a cualquier colección de objetos
y no necesariamte datos relacionales.

Buen punto. Ni idea!

Aquí volvemos a caer en el tema q ya hemos hablado otras veces de la
diferencia de puntos de vista entre los que se acercan al problema desde los
lenguajes OO y los que provienen del mundo relacional.

Me tientas a explicar... pero no lo hago :-)

Me pensaba escudar en
la especialización estrecha que generalmte impera en los EEUU, pero me he
dado cuenta de que varios de los líderes de ese proyecto son europeos :-)

:-)

Saludos,
Carlos

Yo no pienso que en informática sea lo "normal" aceptar cambios radicales
de diseño durante el desarrollo de un software. Peor aún yo creo que es
malo por ser muy caro para el desarrollador trabajar bajo esos esquemas de
flexibilidad forzada.

Buen criterio y yo agrego que quien hace sistemas al vuelo sin saber lo que
quiere el usuario y sin un diseño claro no tiene los conocimientos
necesarios o no es buen ingeniero de software o es un desorganizado. Y no
le echemos la culpa al usuario o al cliente.
Por algo le llaman ingenieria de software, otros le llaman arquitectura de
software , en ambos casos esta la preeminencia una buena definicion de
requerimientos y de un buen diseño. Claro, como dices, el punto es hacer un
diseno flexible a los cambios (patrones).

Un profesor nos decia siempre que hacer las cosas correctamente a la larga
sale mucho mas barato aunque de inicio no lo parezca.

Pedro.