Entender las aplicaciones orientadas a Objetos

Juan Diego Bueno Prieto schreef:

untiosinnombre: Se puede o no estar de acuerdo con el polémico punto de
vista de Alfredo, pero recurrir al insulto hace que tus argumentos pierdan
toda credibilidad.

Alfredo es muy categórico en sus afirmaciones, las cuales pueden denotar un
punto de soberbia o de prepotencia, pero simplemente defiende su punto de
vista y yo todavía no he visto ningún insulto por su parte a nadie. En todo
caso el problema es de quien se ofende cuando otra persona propone un punto
de vista diferente al de otra gente que está en este grupo.

tiosinnombre, si estás seguro de que tu forma de ver las cosas es la
correcta, simplemente no tienes más que seguir utilizandola, pero si te
dedicas a defenderla tomándotelo casi como algo personal... lo único que
aparentas es inseguridad en tus planteamientos, con lo cual, das más la
razón a Alfredo en los suyos.

He de reconocer que me encantan estas discusiones en las que Novoa se ve
envuelto, primero porque me divierten, y segundo porque SIEMPRE se aprende
algo, tanto de él como del resto de personas que le rebaten.

Y por favor, deja de ver amiguitos, "chacales", etc... en fin, términos
impropios de quien quiere defender un criterio de forma creible

Pero bueno, allá cada cual, que ya somos todos mayorcitos

Saluti

Hola a tuti,

Bueno... parece ser que aun hay gente con sentido común. A
mi me parecía una aportación que no era digna de respuesta
y Alfredo me sigue sorperdiendo con su perseverancia. Eso
en cuanto a las formas.

En cuanto al contenido no puedo creer que no haya gente que
entienda de que va esto y quisiera invitarles a dejarse ver.
Yo creo que el motivo del desentendimiento reside en que
tenemos una formación y/o expeciencia que estan totalmente
basadas en pensar en lenguares imperativos. Entonces solo
somos capaces de ver soluciones en esos términos. Sí sabemos
lo que es programación declarativa (o pensamos saberlo) y
hemos visto algo de sistemas axiomáticos pero no tenemos
experiencia con esta forma de pensar. Eso nos hace creer que
solo se trata de experimentos académicos que no son prácticos.
Claro, no son prácticos debido a nuestro rechazo, no a las
teorías en si mismas. La experiencia es la que de verdad hace
enterder. El resultado es que entonces aquello que no se
entiende, o no se experimenta, se rechaza y si ademas uno se
siente apollado por la gran mayoría ya se convence a si
mismo de su razón y no hay motivo para dedicarle mas atención.
Desentendimiento, confusión y rechazo.

Por otro lado esta el pensar solo en términos de productos.
El producto es como es y a casi nadie parece interesarle
por qué es asi o como 'debería ser'.
Por poner un ejemplo sencillo de esta forma de aceptar todo
lo que se nos viene encima:
Yo defino en una base de datos que tengo clientes y que
estos tienen un nombre que en un CHAR(30). Luego en las
aplicaciones en algún sitio (o varios) tengo que declarar que
una variable 'nombre' es del tipo String y además controlar
que valores que pueda adquirir esta variable no excedan los
30 carácteres. ¿A nadie se le ocurre llegado este punto que
ya se le ha dicho al sistema que es lo que queremos decir
con 'nombre de un cliente'? ¿A nadie le intriga esta pregunta?
Es simplemente un ejemplo. Pero el tratar de responder
este tipo de preguntas lleva a uno a analizar qué es lo que
en realidad estamos haciendo. Si encontramos respuesta
tendremos también algo que exirle a los que nos venden
productos y métodos.

Otra actitutud que veo es que tratamos de aprender teorías
sin ponerlas en un contexto histórico. Para enterderlas hay
que enterder antes cuales son los problemas que un método
o teoría trata de solucionar y por qué esos problemas son
problemas. Es de suponer que metodología y theoría tratan
de solucionar algo. Esto parece no ser tan evidente. No
profundizar en ese contexto es lo que nos lleva a inventar
una y otra vez la rueda cuadrada.

Saludos,
Carlos

Hola Carlos,

On 5 Dec 2006 04:39:44 -0800, "CMCC" wrote:

En cuanto al contenido no puedo creer que no haya gente que
entienda de que va esto y quisiera invitarles a dejarse ver.
Yo creo que el motivo del desentendimiento reside en que
tenemos una formación y/o expeciencia que estan totalmente
basadas en pensar en lenguares imperativos.

Bueno, más precisamente en lenguajes procedimentales. SQL sigue siendo
imperativo.

Si alguien no tiene totalmente claras las diferencias entre
procedimental, imperativo y declarativo aquí están bastante bien
explicadas:

http://foldoc.org/?procedural+language
http://foldoc.org/?imperative+language
http://foldoc.org/?declarative+languages

Entonces solo
somos capaces de ver soluciones en esos términos.

Y las universidades tienen bastante culpa de esto. Recuerdo que los
ejemplos de las asignaturas de programación de primero estaban llenos
de ejemplos de programación de mini sistemas de gestión hechos con
lenguajes procedimentales a pelo. Nadie te avisaba de que en el mundo
real las cosas no se deben de hacer así.

Sí sabemos
lo que es programación declarativa (o pensamos saberlo) y
hemos visto algo de sistemas axiomáticos pero no tenemos
experiencia con esta forma de pensar. Eso nos hace creer que
solo se trata de experimentos académicos que no son prácticos.

Y otro factor es que la gente tiende consciente e inconscientemente a
defender su trabajo. El cerebro humano no acepta fácilmente que lleva
años haciendo las cosas mal. No puede ser que la tierra sea redonda si
llevo toda la vida pensando que era plana.

Por otro lado esta el pensar solo en términos de productos.
El producto es como es y a casi nadie parece interesarle
por qué es asi o como 'debería ser'.

Cierto, la mayoría solo quieren recetas para seguirlas sin tener que
pensar.

Por poner un ejemplo sencillo de esta forma de aceptar todo
lo que se nos viene encima:
Yo defino en una base de datos que tengo clientes y que
estos tienen un nombre que en un CHAR(30). Luego en las
aplicaciones en algún sitio (o varios) tengo que declarar que
una variable 'nombre' es del tipo String y además controlar
que valores que pueda adquirir esta variable no excedan los
30 carácteres. ¿A nadie se le ocurre llegado este punto que
ya se le ha dicho al sistema que es lo que queremos decir
con 'nombre de un cliente'? ¿A nadie le intriga esta pregunta?

Yo también me pregunto por que gastar tiempo en ponerle un límite al
tamaño del nombre del cliente.

Otra actitutud que veo es que tratamos de aprender teorías
sin ponerlas en un contexto histórico. Para enterderlas hay
que enterder antes cuales son los problemas que un método
o teoría trata de solucionar y por qué esos problemas son
problemas. Es de suponer que metodología y theoría tratan
de solucionar algo. Esto parece no ser tan evidente. No
profundizar en ese contexto es lo que nos lleva a inventar
una y otra vez la rueda cuadrada.

Conocer la historia y los problemas por los que se han creado las
soluciones es algo muy importante, y aquí vuelven a fallar
estrepitosamente las universidades.

Cualquiera que conozca un poco la historia de los sistemas de bases de
datos verá muy claramente que estas modas de los objetos de negocio
reintroducen graves problemas que fueron solucionados hace décadas y
que fueron la motivación principal para el desarrollo de los SGBD.


Saludos
Alfredo

Hola Alfredo,

Alfredo Novoa schreef:

Hola Carlos,

On 5 Dec 2006 04:39:44 -0800, "CMCC" wrote:

>Yo creo que el motivo del desentendimiento reside en que
>tenemos una formación y/o expeciencia que estan totalmente
>basadas en pensar en lenguares imperativos.

Bueno, más precisamente en lenguajes procedimentales. SQL sigue siendo
imperativo.

Correcto!

>Por poner un ejemplo sencillo de esta forma de aceptar todo
>lo que se nos viene encima:
>Yo defino en una base de datos que tengo clientes y que
>estos tienen un nombre que en un CHAR(30). Luego en las
>aplicaciones en algún sitio (o varios) tengo que declarar que
>una variable 'nombre' es del tipo String y además controlar
>que valores que pueda adquirir esta variable no excedan los
>30 carácteres. ¿A nadie se le ocurre llegado este punto que
>ya se le ha dicho al sistema que es lo que queremos decir
>con 'nombre de un cliente'? ¿A nadie le intriga esta pregunta?

Yo también me pregunto por que gastar tiempo en ponerle un límite al
tamaño del nombre del cliente.

También.

>Otra actitutud que veo es que tratamos de aprender teorías
>sin ponerlas en un contexto histórico. Para enterderlas hay
>que enterder antes cuales son los problemas que un método
>o teoría trata de solucionar y por qué esos problemas son
>problemas. Es de suponer que metodología y theoría tratan
>de solucionar algo. Esto parece no ser tan evidente. No
>profundizar en ese contexto es lo que nos lleva a inventar
>una y otra vez la rueda cuadrada.

Conocer la historia y los problemas por los que se han creado las
soluciones es algo muy importante, y aquí vuelven a fallar
estrepitosamente las universidades.

Cualquiera que conozca un poco la historia de los sistemas de bases de
datos verá muy claramente que estas modas de los objetos de negocio
reintroducen graves problemas que fueron solucionados hace décadas y
que fueron la motivación principal para el desarrollo de los SGBD.

Que era por donde iban los tiros; yo traté de generalizarlo porque se
ve
el mismo problema en todo tipo de discusiones.

En todo caso trato de analizar por que se discute como se discute.
La gente cuando no entiende trata de defender, no se sabe qué, cuando
lo lógico sería preguntar mas hasta entender o hasta tener bastante
información para deshechar lo propuesto. Un poco raro, pero asi somos.

Saludos,
Carlos

Hola Alfredo,

Alfredo Novoa schreef:

Hola Carlos,

On 5 Dec 2006 04:39:44 -0800, "CMCC" wrote:

>Yo creo que el motivo del desentendimiento reside en que
>tenemos una formación y/o expeciencia que estan totalmente
>basadas en pensar en lenguares imperativos.

Bueno, más precisamente en lenguajes procedimentales. SQL sigue siendo
imperativo.

Correcto!

>Por poner un ejemplo sencillo de esta forma de aceptar todo
>lo que se nos viene encima:
>Yo defino en una base de datos que tengo clientes y que
>estos tienen un nombre que en un CHAR(30). Luego en las
>aplicaciones en algún sitio (o varios) tengo que declarar que
>una variable 'nombre' es del tipo String y además controlar
>que valores que pueda adquirir esta variable no excedan los
>30 carácteres. ¿A nadie se le ocurre llegado este punto que
>ya se le ha dicho al sistema que es lo que queremos decir
>con 'nombre de un cliente'? ¿A nadie le intriga esta pregunta?

Yo también me pregunto por que gastar tiempo en ponerle un límite al
tamaño del nombre del cliente.

También.

>Otra actitutud que veo es que tratamos de aprender teorías
>sin ponerlas en un contexto histórico. Para enterderlas hay
>que enterder antes cuales son los problemas que un método
>o teoría trata de solucionar y por qué esos problemas son
>problemas. Es de suponer que metodología y theoría tratan
>de solucionar algo. Esto parece no ser tan evidente. No
>profundizar en ese contexto es lo que nos lleva a inventar
>una y otra vez la rueda cuadrada.

Conocer la historia y los problemas por los que se han creado las
soluciones es algo muy importante, y aquí vuelven a fallar
estrepitosamente las universidades.

Cualquiera que conozca un poco la historia de los sistemas de bases de
datos verá muy claramente que estas modas de los objetos de negocio
reintroducen graves problemas que fueron solucionados hace décadas y
que fueron la motivación principal para el desarrollo de los SGBD.

Que era por donde iban los tiros; yo traté de generalizarlo porque se
ve
el mismo problema en todo tipo de discusiones.

En todo caso trato de analizar por que se discute como se discute.
La gente cuando no entiende trata de defender, no se sabe qué, cuando
lo lógico sería preguntar mas hasta entender o hasta tener bastante
información para deshechar lo propuesto. Un poco raro, pero asi somos.

Saludos,
Carlos

Carlos y Alfredo.vosotros dos a complacerlos mutuamente.

Aflredo, decir que Fowler no sabe y su trabajo es una basura, puede ser
cierto, pero es una de las personas que más éxito tiene actualmente a
nivel de consultoria y su empresa es muy respetado (siendo él en ese
empresa arquitecto jefe). Bien puede ser que el tio no tenga ni idea y
haga creer lo contrario, si puede ser cierto. Ahora lo que no me
explico es porque clientes hablan bien tanto de él como la empresa, y
les sigue llegando más clientes. Algo estarán haciendo bien no? Al
final del día es proporcionar soluciones a clientes verdad, tal como tu
lo haces? O es que sus clientes también sin ignorantes?

Es que te basas siempre en los mismos argumentos. CMCC, tu que dices
eh? :)


Juanque insultos? Mira los posts de Alfredo, se harta de insultar!