Herencia en VB6?
Leonardo Azpurua
Debug.Print a + b
End Sub
ParentClass1.UnaSub a, b
End Sub
ParentClass1.s = RHS
End Property
Class1_s = ParentClass1.s
End Property
Debug.Print a * b
End Sub
ParentClass1.s = v
End Property
s = ParentClass1.s
End Property
Dim c1 As Class1
Set c1 = c2
Debug.Print "Calling Class1.UnaSub:"
c1.UnaSub 3, 2
Debug.Print "Calling Class2.UnaSub:"
c2.UnaSub 3, 2
5
Calling Class2.UnaSub:
6
Harvey Triana
La discusión es banal. Se hizo hace 10 años. En realidad nunca se debe mirar
a VB.NET como un sucesor de VB6 porque no lo es, - ya lo sabemos -. Mi
percepción es que va a desaparecer, aunque no me interesa. Respecto a lo
demás, la tecnología .NET se justifica en ASP.NET respaldado en AJAX, en
lenguaje C#. No se puede pretender alcanzar el mismo nivel de una aplicación
Web usando solo VB6.
Claro que se pude lograr herencia con VB6, manipulando delegación. Un
artificio algo costoso e innecesario, en el paradigma COM ¿Para qué? - Los
programadores VB6 son pragmáticos, usan delegación directa o herencia
múltiple por interfaces - .
Saludos –
- No se responda.
--
<Harvey Triana />
http://vexpert.mvps.org
"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje de noticias
news:%23hiWlTs...@TK2MSFTNGP03.phx.gbl...
Leonardo Azpurua
"Harvey Triana" <harvey...@hotmail.com> escribió en el mensaje
news:uZrPxAtu...@TK2MSFTNGP02.phx.gbl...
> Estimado colega.
>
> La discusión es banal. Se hizo hace 10 años. En realidad nunca se debe
> mirar a VB.NET como un sucesor de VB6 porque no lo es, - ya lo sabemos -.
> Mi percepción es que va a desaparecer, aunque no me interesa. Respecto a
> lo demás, la tecnología .NET se justifica en ASP.NET respaldado en AJAX,
> en lenguaje C#. No se puede pretender alcanzar el mismo nivel de una
> aplicación Web usando solo VB6.
>
> Claro que se pude lograr herencia con VB6, manipulando delegación. Un
> artificio algo costoso e innecesario, en el paradigma COM ¿Para qué? - Los
> programadores VB6 son pragmáticos, usan delegación directa o herencia
> múltiple por interfaces - .
>
> Saludos –
> - No se responda.
¿No se responda? ¿Por qué? ¿"Palabra de Dios"? ¡No me jodas, Harvey!
Claro que la delegación es menos eficiente que la herencia implementada
directamente como mecanismo a nivel del compilador (es decir, si B extiende
A, entonces B declarará físicamente TODAS las variables declaradas en A y
las VTables de B apuntarán a las mismas funciones que las VTables de A - a
menos que sean métodos sobrecargados o exclusivos de la clase derivada).
Pero la delegación es una manera eficiente de implementar la herencia "sin
tocar" la infraestructura.
Justamente porque somos pragmáticos es por lo que deberíamos poder heredar,
de manera limpia y transparente, en nuestro lenguaje.
No estoy buscando demostrar que VB6 es mejor que VB.Not. No lo es.
Lo que estoy tratando es de demostrar que TODOS los argumentos que en su
tiempo se expusieron para hacer aparecer la descontinuación de VB Clásico
como un paso necesario para la evolución de nuestra práctica son falaces.
No era necesario descontinuar VB Clásico.
La decisión obedece exclusivamente a los planes estratégicos a largo plazo
de MS y a necesidades inmediatas de mercadeo para realizar tales planes.
Para tomar dicha decisión deben haber evaluado todos los riesgos, incluso el
de la pérdida de confianza en MSFT por parte de los desarrolladores
afectados por ella.
Lo que estoy haciendo es oponiendo una resistencia militante a esa decisión:
espero que se hayan equivocado en la evaluación de ese riesgo en particular,
espero que se hayan equivocado, y voy a hacer cuanto esté a mi alcance para
convertir esa decisión en un error.
Si tuviera la más lejana posibilidad de éxito, buscaría presentar un caso
ante una corte para obligarlos a resarcir las eventuales pérdidas que
experimentaría en caso de que mis programas no resultaran ya compatibles con
sus SSOO. A fin de cuentas, adopté VB a consecuencia de anuncios
publicitarios donde expresaban su compromiso a largo plazo con la
estabilidad del lenguaje. Si luego no cumplen con dicho compromiso, la culpa
es de ellos, no mía. Pero no la tengo.
Por otra parte, el esfuerzo de migrar mis aplicaciones a Java sería
muchísimo menor que el de meterme en una disputa legal con MSFT (que además
de ser la mayor empresa productora de software del mundo, tambien tiene el
mayor despacho de abogados del planeta).
Para trabajar con AJAX, lo único que necesitas es un browser que soporte
JavaScript y HTML y un lenguaje de scripting del lado del servidor, y lo
mismo da que uses ASP, JSP, PHP o cualquier otra cosa, incluyendo CGI. C# es
una *opcion*, no es mejor que nada.
Lo mejor es siempre lo que uno ya conoce. Y MSFT parece empeñado en quitarme
lo que conozco a cambio de algo que puede ser un poco mejor, pero que no
necesito.
Eso es lo único que quiero impedir.
Salud!
Bruno A. Pestoni
Mas claro imposible... No se, finalmente, querrán que utilicemos otras
plataformas. Las cuales vienen desarrollándose de manera muy interesante
y como contrapartida MS nos pone entre la espada y la pared. Cuando uno
volcó muchas horas de trabajo en un lenguaje no es tan fácil poder salir
de ahí, aunque hablemos dos o tres idiomas si preferimos hablar en que
que mas cómodos nos sentimos...
Saludos.
Armin Saez
"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje
news:%23zkD0ct...@TK2MSFTNGP05.phx.gbl...
> Lo que estoy haciendo es oponiendo una resistencia militante a esa
> decisión: espero que se hayan equivocado en la evaluación de ese riesgo en
> particular, espero que se hayan equivocado, y voy a hacer cuanto esté a mi
> alcance para convertir esa decisión en un error.
>
> Si tuviera la más lejana posibilidad de éxito, buscaría presentar un caso
> ante una corte para obligarlos a resarcir las eventuales pérdidas que
> experimentaría en caso de que mis programas no resultaran ya compatibles
> con sus SSOO. A fin de cuentas, adopté VB a consecuencia de anuncios
> publicitarios donde expresaban su compromiso a largo plazo con la
> estabilidad del lenguaje. Si luego no cumplen con dicho compromiso, la
> culpa es de ellos, no mía. Pero no la tengo.
>
> Por otra parte, el esfuerzo de migrar mis aplicaciones a Java sería
> muchísimo menor que el de meterme en una disputa legal con MSFT (que
> además de ser la mayor empresa productora de software del mundo, tambien
> tiene el mayor despacho de abogados del planeta).
>
Ni siquiera el sequito de abogados, logro impedir que MS tubiera que pagar
una millonaria indemnizacion, por usar un programa antipirateria, que
pertenecia a otra empresa menor. lo que en la prensa se presento como:
Microsoft piratea un sistema antipirateria hecho por Uniloc.
Fuente: http://mouse.tercera.cl/detail.asp?story=1999/04/09/13/00/22
Referente al tema en cuestion, por mas que me lo planteo, no logro
impregnarme con la voragine que significo la migracion a VB.Net. Y estoy en
completo acuerdo con Leonardo. Mal que mal, si Jesus, flaco y pobre, logro
conmover al planeta, tan solo con la palabra, porque no habria de hacerlo
Leonardo, contra Bill Gates y Cia???
No solo basta criticar algo que se considera abusivo y arbitrario, si no que
tambien hay que exponer los argumentos de porque se considera una mala
desicion de dejar a primeras lo que uno hacia con tanta comodidad, por algo
que no solo no te garantiza estabilidad, ni mucho menos continuidad en el
tiempo. Sobre todo considerando las desiciones radicales que se da el lujo
de tomar la maquinaria de marketing de MS.
Creo que Leo esta haciendo lo correcto, importe o no mi humilde comentario
X-DY porque no decirlo, le importe o no a Microsoft, los comentario emitidos
por los integrantes de este grupo.
Saludos y Suerte!!!
______________
Armin Saez
PD: Los tildes se han suprimido intencionalmente.
Leonardo Azpurua
"Armin Saez" <astranc...@gmail.cl> escribió en el mensaje
news:uJCsRHEv...@TK2MSFTNGP03.phx.gbl...
> Referente al tema en cuestion, por mas que me lo planteo, no logro
> impregnarme con la voragine que significo la migracion a VB.Net. Y estoy
> en completo acuerdo con Leonardo. Mal que mal, si Jesus, flaco y pobre,
> logro conmover al planeta, tan solo con la palabra, porque no habria de
> hacerlo Leonardo, contra Bill Gates y Cia???
>
> No solo basta criticar algo que se considera abusivo y arbitrario, si no
> que tambien hay que exponer los argumentos de porque se considera una mala
> desicion de dejar a primeras lo que uno hacia con tanta comodidad, por
> algo que no solo no te garantiza estabilidad, ni mucho menos continuidad
> en el tiempo. Sobre todo considerando las desiciones radicales que se da
> el lujo de tomar la maquinaria de marketing de MS.
Hola, Armin:
Le he estado dando vueltas al tema, incluso he consultado con algunos
abogados el asunto de la demanda.
En la medida en que mis aplicaciones siguen corriendo sobre nuevas versiones
del SO, no he sido hasta ahora dañado por la descontinuación de VB6.
Y la aplicación corre sobre Windows 7 y sobre Windows Server 2008. Mientras
MS no deje de soportar el runtime de VB6, no me habrá causado daño nigún
daño.
Por eso, la demanda seguramente no prosperaría. Y si en alguna versión
futura del SO no corriere, habría tenido tiempo suficiente para migrar la
aplicación a otra plataforma. Como he tenido tiempo suficiente para
actualizar o migrar mis aplicaciones, la responsabilidad de una eventual
catástrofe comercial seguirá siendo exclusivamente mía.
Una demanda, entonces, sería un arma de doble filo, con muchas
probabilidades de que sea yo mismo quien resulte herido.
Por eso, el "trabajo" es más bien político.
Estoy convencido de que mientras haya gente usando VB6 y produciendo
aplicaciones usadas por mucha más gente, a MS no le resultará conveniente
dejar de soportar el runtime.
Y no me cabe ninguna duda de que VB6 es la mejor herramienta para hacer lo
que hoy en día se hace con él.
De manera que tampoco encuentro muchos motivos de preocupación. VB6 va a
seguir usándose muchísimo por muchos años más.
Pero no quiero que se olvide lo que fue la actitud de Microsoft hacia
nosotros. Cuando opté por VB5 sobre Delphi, lo hice basado en el compromiso
a largo plazo con la evolución y estabilidad del lenguaje anunciado en la
publicidad de Microsoft. Y dicha publicidad resultó ser un engaño.
Por eso, si alguien cree que le conviene abandonar VB6, le advierto el
peligro que corre al adoptar VB.Net o cualquier otra herramienta de MS:
"cuando veas las barbas de tu vecino arder"... Lo mas sensato, en este caso,
sería adoptar una herramienta de dominio público (y Java con Eclipse o
NetBeans, se ve de lo mejor).
Pero de momento no veo ninguna razón para abandonar VB6. De hecho, una vez
que entendí la ausencia de peligro a mediano plazo, comencé a rediseñar mi
aplicación *en VB6*.
¡Y voy adelantando a un ritmo que da gusto!
Salud!
Armin Saez
"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje
news:uhMcDZEv...@TK2MSFTNGP03.phx.gbl...
> Por eso, la demanda seguramente no prosperaría. Y si en alguna versión
> futura del SO no corriere, habría tenido tiempo suficiente para migrar la
> aplicación a otra plataforma. Como he tenido tiempo suficiente para
> actualizar o migrar mis aplicaciones, la responsabilidad de una eventual
> catástrofe comercial seguirá siendo exclusivamente mía.
>
> Una demanda, entonces, sería un arma de doble filo, con muchas
> probabilidades de que sea yo mismo quien resulte herido.
>
> Por eso, el "trabajo" es más bien político.
>
El hecho que tus aplicaciones "funcionen" en Windows 7 o en Windows server
2008, simplemente me dice que MS sabe muy bien que existen mas de 6 millones
de usuarios "profesionales" de VB clasico ( sin considerar a los "no
profesionales"), y que es muy arriesgado para ellos abandonar todo, ya que
corren el riesgo que los usuarios se unan y le llenen los buzones con
demandas por su publicidad engañosa y por dejarlos arbitrariamente sin su
herramienta de trabajo.
No creo que MS se tome a la ligera o no considere VB 6 en sus futuros
proyectos. En este punto se me viene a la memoria al MS-DOS, MS nunca ha
podido dejar de lado esta base de sus SO, aunque le haya cambiado de nombre
y lo haya escondido, sigue estando presente y sigue siendo muy utilizada, a
pesar que MS anunciaba con bombos y platillos, que dejaria de lado MS-DOS,
por alla por el lanzamiento de Windows XP.
Cosas que se me vienen a la mente ;-)
Armin Saez
"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje
news:uhMcDZEv...@TK2MSFTNGP03.phx.gbl...
Sin duda Leo, pero insisto en el tema de la continuidad en el tiempo de la
misma herramienta, VB.Net ha sido rediseñado o cuenta con al menos 4?
versiones muy diferentes (tanto en diseño, como en estabilidad y velocidad
de ejecucion) unas de otras desde su salida al mercado, ya vamos en la
version 2008, y no creo equivocarme tanto al decir que esta version es muy
diferente a la version 2003 de la misma herramienta. VB Clasico o el VB 6
fue una herramienta que al cabo de muchos años ha tenido una estabilidad que
creo es envidiable. MS Sabe que VB 6 fue uno de sus mejores trabajos (al
igual, segun mi opinion que W98 y WXP, ademas de WNT). VB 6 solo necesito de
dos SP, que corrigieron algunos bugs, y que ademas trajeron muchas mejoras a
los componentes ya usados por los programadores.
Quien nos garantiza que habra continuidad, cuando MS se de cuenta que VB.Net
no dio los resultados esperados, y pongan a su maquinaria a trabajar por
otra herramienta de desarrollo completamente diferente de la actual???
En mi humilde opinion, pienso que apoyaria (y esperaria) mas una version de
VB 7.0, que hacerme la idea de migrar a una tecnologia, que, siendo buena,
no te da garantias de continuidad.
Pero como dice el dicho, "... es mas facil que un camello quepa por el ojo
de una aguja a que..." X-D
Saludos y Suerte!!!
_______________
Jhonny Vargas P.
"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje de noticias:%23hiWlTs...@TK2MSFTNGP03.phx.gbl...
Leonardo Azpurua
> Sin duda Leo, pero insisto en el tema de la continuidad en el tiempo de la
> misma herramienta, VB.Net ha sido rediseñado o cuenta con al menos 4?
> versiones muy diferentes (tanto en diseño, como en estabilidad y velocidad
> de ejecucion) unas de otras desde su salida al mercado, ya vamos en la
> version 2008, y no creo equivocarme tanto al decir que esta version es muy
> diferente a la version 2003 de la misma herramienta. VB Clasico o el VB 6
> fue una herramienta que al cabo de muchos años ha tenido una estabilidad
> que creo es envidiable. MS Sabe que VB 6 fue uno de sus mejores trabajos
> (al igual, segun mi opinion que W98 y WXP, ademas de WNT). VB 6 solo
> necesito de dos SP, que corrigieron algunos bugs, y que ademas trajeron
> muchas mejoras a los componentes ya usados por los programadores.
En la historia de VB Clásico hubo al menos dos puntos de ruptura.
Al pasar de VB3 a VB4 se redefinió la estructura de las cadenas. En VB, una
variable tipo String apunta a un descriptor, que contiene la longitud de la
cadena y un apuntador a la cadena en sí (lo que obtienes mediante la función
StrPtr).
Hasta VB3, las cadenas estaban implementadas como texto ANSI. A partir de
VB4, con soporte para SSOO de 23 bits, las cadenas se implementaron en
UNICODE. Todos los programas que utilizaban StrPtr para recorrer las cadenas
como matrices lineales de caracteres de 8 bits resultaron afectados por este
cambio.
Luego, al pasar de VB4 a VB5, basado en COM, todos los viejos componentes
.VBX quedaron sin soporte, y debieron ser reemplazados por componentes OCX.
Para VB5 se publicaron 3 service packs. Y para VB6, seis (sólo me actualicé
hasta el 5, y todo me funciona bien).
> Quien nos garantiza que habra continuidad, cuando MS se de cuenta que
> VB.Net no dio los resultados esperados, y pongan a su maquinaria a
> trabajar por otra herramienta de desarrollo completamente diferente de la
> actual???
Creo que los días de B# están contados.
Por otra parte, la evolución del lenguaje sigue llevándolo hacia la
"paridad" con C#, algo que aunque pueda resultar deseable para alguien, no
tiene nada que ver con lo que son mis verdaderas necesidades como
programador de VB6 (lo que necesitaría sería que me devolvieran la
simplicidad y la inmediatez actuales de mi herramienta).
Las ventas de libros sobre VB.Net han caido por debajo de la venta de libros
sobre VB6, al punto de que las grandes casas editoriales han cancelado todos
sus proyectos de publicación de libos relacionados con el lenguaje.
> En mi humilde opinion, pienso que apoyaria (y esperaria) mas una version
> de VB 7.0, que hacerme la idea de migrar a una tecnologia, que, siendo
> buena, no te da garantias de continuidad.
En Microsoft parecen estar obsesionados con la Web. La idea de .Net era
plantearle la competencia a Java (pero como a fin de cuentas su línea
principal de negocios son los SSOO, decidieron no soportar la maquina
virtual de Net en otros SSOO como los OS de Apple o Linux). Lo único que
podrían haber logrado era sacar la VM de Java -y con ella a Sun- de los
equipos con Windows, pero igual la máquina de Java resulta necesaria para
una cantidad de aplicaciones (Open Office, por ejemplo, o ArgoUML). El
resultado fue que molestaron a una cantidad de gente (no solo a los
programadores de VB6) y siguen por detras de Java en cuanto a número de
usuarios.
Por otra parte, tenemos a VBA.
En 2004, MS publicó una versión de Mac Office sin VBA. Vendieron poquísimas,
y de las pocas que vendieron les devolvieron casi todas: NADIE quiere un
Office sin VBA. Y los usuarios de Office no quieren aprender otro lenguaje
de programación: VBA les sirve para todo lo que necesitan. El runtime de VBA
y el runtime de VB6 son el mismo. Y *TODOS* los desarrolladores
profesionales de Office usan VBA. Casi nadie usa las VSTO, que son la
alternativa .Net.
De manera que tenemos VB6 para rato.
Aunque un poco de militancia para que ese rato sea cada vez más largo
tampoco está de más.
Salud!
Jhonny Vargas P.
"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje de
noticias:#ATq0XGv...@TK2MSFTNGP04.phx.gbl...
>
> Los problemas no fueron tanto con el lenguaje como con los controles de
> WindowsForms (incluyendo los de DevExpress, que tienen una pinta excelente
> pero severas deficiencias funcionales) y con el soporte obtenido tanto de
> MS como de "las comunidades". La frecuencia de respuestas del tipo "no se
> puede" resultó descorazonadora.
>
> Luego está el asunto de la estabilidad. Hay signos que apuntan a una
> significa decaída en la rata de adopción de VB.Net: su aceptación entre
> los usuarios típicos de VB6 ha sido practicamente nula, y la mayoría de
> los usuarios profesionales han migrado hacia otros lenguajes (C#, Java o
> Delphi).
>
> Dedicarse a desarrollar aplicaciones de escritorio con VB.Net, con todo el
> trabajo que ello implica, sería un disparate.
>
> Y en mi caso, puesto a migrar, por ningun motivo volvería a decidirme por
> una herramienta "propietaria". Y si lo hiciera, el último proveedor de
> herramientas de desarrollo en quien confiaría sería MS: "si me jodes una
> vez, la culpa es tuya, pero si me jodes dos veces, la culpa es mía".
>
Eso me he dado cuenta... cada vez más usuarios vb migran a C# o Java...
Delphi, aún no he visto mucho...
Difícil de defender lo indefendible... pero el mundo gira, las tecnologías
crecen, los sistemas operativos cambian, las personas abren su mente a otras
partes, ante eso hay que evolucionar también... espero que no sea el fin de
VB 6.0 (por lo menos en un buen tiempo), pero ¿hasta que punto se podrá
estirar?.. te pongo un caso específico: desarrollé muchas aplicaciones en el
viejo y querido Clipper (querido para mi jejejeje)... varios años bajo DOS y
me funcionaban espectacular, aún hay varias versiones funcionando en una
empresa que trabajé hasta como el 2000 en este ambiente... de ahí migré a VB
3.0, hasta el 6.0 donde conocí los ActiveX y el salto a ASP tradicional.
Ahora completamente en ASP.NET, he pensado en cambiarme a JAVA... pero...
confiabilidad?... hasta el momento la confianza me la entrega M$, por el
lado web.. en temas de seguridad, implementación, desarrollo, facilidad,
etc...
>> Independiente de esto, he trabajado mucho con VB.NET en ASP.NET
>> y he tenido muy buenos resultados (las diferencias son notables entre ASP
>> Clásico y ASP NET)... pero bueno, experiencia en WinForm no la tengo
>> y sé perfectamente el conocimiento que tú tienes y por ende la molestia
>> en este asunto.
>
> La idea del CodeBehind es buena.
>
> No entendí para nada el asunto de la "master page". Y para la interacción
> entre la pagina y el servidor no hay nada como DHTML y Ajax (que lo mismo
> lo implementas en PHP que en JSP que en ASP). Sigo prefiriendo PHP, si no
> por otra razón, porque está en todas partes, aunque sólo lo uso para cosas
> muy simples.
>
El asunto de MasterPage imagina un gran Control de Usuario Web en donde
tienes un encabezado y un menú (o lo que sea)... y se lo incrustas en una
página aspx. La idea es lo mismo pero a nivel de plantillas, en donde al
crear una plantilla, defines áreas de trabajo, por ejemplo:
<Encabezado>
<Menu>< Mi Contenido de las páginas>
<Pie de pagina>
Todas las páginas o la mayoría tienen esta estructura, si creas un
MasterPage de Plantilla, en donde colcas el "<Encabezado>", el "<Menu>" y el
"<Pie de pagina>"; y asignas un área de Contenido "<mi Contenido de las
Páginas>" para todas las páginas que requieren este tipo de plantillas.
Todas estás páginas asumirán dicha información por defecto (encabezado,
menu, pie de pagina) y no necesitas "programar" o colocar html o controles
web.
Es una forma más "limpia" de crear tu proyecto, ya que solo desarrollas el
área de contenido y no todo lo demás.
Puedes tener varios MasterPage y puede o no tener una página un MasterPage
asociado.
Antiguamente se creaban Includes en las páginas ASP tradicional...
ups... creo que me expandí un poco... jejejeje
> De todas maneras, cada vez tengo más confianza en el futuro a largo plazo
> de VB6.
De todas maneras amigo mío... imagina que hace un par de semanas tuve que
crear un componente ActiveX para solucionar un par de temas de seguridad a
unos recursos que el usuario que entra a Windows no tiene directamente..
Saludos desde Chile,
Jhonny Vargas P.
Leonardo Azpurua
> Una lástima que hayas tenido malos momento con VB.NET
> y tengas que llegar al extremo de desinstalar VS 2003 o superior...
Los problemas no fueron tanto con el lenguaje como con los controles de
WindowsForms (incluyendo los de DevExpress, que tienen una pinta excelente
pero severas deficiencias funcionales) y con el soporte obtenido tanto de MS
como de "las comunidades". La frecuencia de respuestas del tipo "no se
puede" resultó descorazonadora.
Luego está el asunto de la estabilidad. Hay signos que apuntan a una
significa decaída en la rata de adopción de VB.Net: su aceptación entre los
usuarios típicos de VB6 ha sido practicamente nula, y la mayoría de los
usuarios profesionales han migrado hacia otros lenguajes (C#, Java o
Delphi).
Dedicarse a desarrollar aplicaciones de escritorio con VB.Net, con todo el
trabajo que ello implica, sería un disparate.
Y en mi caso, puesto a migrar, por ningun motivo volvería a decidirme por
una herramienta "propietaria". Y si lo hiciera, el último proveedor de
herramientas de desarrollo en quien confiaría sería MS: "si me jodes una
vez, la culpa es tuya, pero si me jodes dos veces, la culpa es mía".
> Independiente de esto, he trabajado mucho con VB.NET en ASP.NET
> y he tenido muy buenos resultados (las diferencias son notables entre ASP
> Clásico y ASP NET)... pero bueno, experiencia en WinForm no la tengo
> y sé perfectamente el conocimiento que tú tienes y por ende la molestia
> en este asunto.
La idea del CodeBehind es buena.
No entendí para nada el asunto de la "master page". Y para la interacción
entre la pagina y el servidor no hay nada como DHTML y Ajax (que lo mismo lo
implementas en PHP que en JSP que en ASP). Sigo prefiriendo PHP, si no por
otra razón, porque está en todas partes, aunque sólo lo uso para cosas muy
simples.
De todas maneras, cada vez tengo más confianza en el futuro a largo plazo de
VB6.
Salud!
Yuri Aponte
"Jhonny Vargas P." <c_h_a_n_g...@hotmail.com> escribió en el mensaje de noticias:umGIVxGv...@TK2MSFTNGP05.phx.gbl...
Armin Saez
Como siempre, agradecido por tus comentarios que de verdad son muy acertados
Leo (y muy didacticos).
___________
Armin Saez
"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje
news:%235zIwvF...@TK2MSFTNGP05.phx.gbl...
Juan Marcial
Hoy en día las guerras y los escenarios de los programadores son mas
complejas, por lo tanto sugieren mejores armas. Me perece imprescindible
estar actualizándose, por otra parte ¿vos crees que les importa a los
clientes tus preferencias? Ellos quieren resultados no suspiros. Yo empecé
con Fox-Pro para DOS (mejor que Clipper), luego VB clásico (es el único VB) y
ahora C#. Es la ley de Darwin.
--
Juan Marcial
Ingeniero de Software
Jhonny Vargas P.
utilizar, ya que escucharon tal y tal cosa..... :S
Pero bueno... :D
--
Saludos,
Jhonny Vargas P.
Santiago de Chile
"Juan Marcial" <eslend...@hotmail.com> escribió en el mensaje de
noticias:1F8099D7-F363-4573...@microsoft.com...
Jhonny Vargas P.
"Yuri Aponte" <yuri.apo...@ESTOapocal.com.pe> escribió en el mensaje de noticias:O71wX9Rv...@TK2MSFTNGP02.phx.gbl...
Leonardo Azpurua
> Hola
>
> Hoy en día las guerras y los escenarios de los programadores son mas
> complejas, por lo tanto sugieren mejores armas. Me perece imprescindible
> estar actualizándose, por otra parte ¿vos crees que les importa a los
> clientes tus preferencias? Ellos quieren resultados no suspiros. Yo empecé
> con Fox-Pro para DOS (mejor que Clipper), luego VB clásico (es el único
> VB) y
> ahora C#. Es la ley de Darwin.
¿De que hablas?
Si tienes una solución bien diseñada hace diez años, y bien construída en
VB6, y te has ocupado continuamente de mantenerla al día con los
requerimientos legales de los paises donde se usa y con los nuevos
dispositivos que aparecen en el mercado ¿qué razón puede obligarte a
migrarla a un nuevo lenguaje?
¿Por qué _*tienes que cambiar*_ cuando lo estás haciendo bien -en términos
técnicos y comerciales- con las herramientas que usas ahora?
Pasar de MS-DOS (en mi caso, era MS-DOS y UNIX, escribiendo en C) a Windows
implica un cambio radical del entorno, y de la manera de pensar (en Windows,
la OO es casi un requerimiento intrínseco). Un cambio tan radical del
entorno justifica un cambio de las herramientas.
No importa cuanto ruido hagan los mercachifles, nada ha cambiado en la Web.
Si tienes un servidor que recibe unos cuantos cientos de solicitudes por
hora, aún podrías usar CGI y JavaScript del lado del cliente para
implementar soluciones eficientes y altamente interactivas. Es probable que
por razones de rendimiento -y de seguridad, si es un aspecto crítico- sea
mejor utilizar tecnologías más recientes, pero un viejo Apache corriendo CGI
aun es capaz de brindar servicios a la altura de los requerimientos. ¿Y qué
probabilidad tengo de necesitar desarrollar algo para un sitio web que
reciba miles de solicitudes por segundo? Si en algún momento tuviera que
enfrentar ese problema, sería para una nueva aplicación y podría enfrentarlo
con herramientas nuevas.
No percibo ningún cambio suficientemente radical ni en la infraestructura ni
en el marco de referencia teórico que justifique un cambio en las
herramientas.
Mi trabajo consiste en desarrollar sistemas de gestión que se venden
"enlatados". El sistema principal, más sus librerías, más las aplicaciones
especializadas de punto de ventas, más las DLL escritas para satisfacer
requerimientos de clientes, más los scripts instalados en los equipos de los
clientes, más las herramientas de generación automática de código,
documentación, etc., todas ellas orientadas a y basadas en VB6, contienen
cerca de dos millones de líneas de código fuente.
¿Qué necesidad justifica la obsolescencia de una base de código de ese
tamaño, que sigue ejecutándose perfectamente incluso en las versiones "por
liberarse" del SO?
Felcitaciones por tu capacidad para adoptar las nuevas tecnologías y por tu
profundo conocimiento de las teorías de Darwin. Pero no, gracias.
Salud!
----
¡Larga vida a VB6!
Juan Marcial
De tu post ¿De que más?
>Si tienes una solución bien diseñada hace diez años, y bien construída en
>VB6, y te has ocupado continuamente de mantenerla al día con los
>requerimientos legales de los paises donde se usa y con los nuevos
>dispositivos que aparecen en el mercado ¿qué razón puede obligarte a
>migrarla a un nuevo lenguaje?
>¿Por qué _*tienes que cambiar*_ cuando lo estás haciendo bien -en términos
>técnicos y comerciales- con las herramientas que usas ahora?
Simplemente pq el cliente lo exije. El "ambiente" lo exije....
Me pasó en la vida real... "Hijo, ahora queremos un portal Web con
aproximadamente la misma funcionalidad"...El cliente paga bien
¿Que harias vos? Si tienes una rabieta de esas, contratan a un chaval con
ideas frescas... ¿O no?
Yo prefiero irme con .NET y arrollar a mi copetencia, total tengo mas
experiencia.
>Felcitaciones por tu capacidad para adoptar las nuevas tecnologías y por tu
>profundo conocimiento de las teorías de Darwin. Pero no, gracias.
En hora buena. Vos tambien lo puedes hacer si quisieras, tienes muy buenos
conocimientos, alla vos...
--
Juan Marcial
Ingeniero de Software
Leonardo Azpurua
> Simplemente pq el cliente lo exije. El "ambiente" lo exije....
> Me pasó en la vida real... "Hijo, ahora queremos un portal Web con
> aproximadamente la misma funcionalidad"...El cliente paga bien
> ¿Que harias vos? Si tienes una rabieta de esas, contratan a un chaval con
> ideas frescas... ¿O no?
Entiendo tu punto de vista.
Y tambien entiendo que nuestra práctica del oficio es radicalmente
diferente. Tu fuente de ingresos parece ser el desarrollo de proyectos a la
medida de clientes; la mía es la venta de UN sistema estandarizado. Tu
puedes atacar un nuevo proyecto con la mejor tecnología disponible (yo
tambien, a veces); yo tengo un sistema que crea un marco de referencia para
cada nuevo proyecto.
Lo que tu haces ahora es lo que yo hacía hace veinticinco años.
Y creo que la mía fué una evolución natural, que comenzó con la adopción de
"C" en 1987: diseñas un sistema "genérico", que pueda venderse tal como está
y que te sirva como base para crear soluciones a medida. Desarrollas
librerías, herramientas de dearrollo, métodos. Te haces tan eficiente como
nunca te imaginaste que podrías serlo. Y vives de ello hasta el siguiente
"cambio", cuando te toca comenzar desde cero.
En 1994 vendí los derechos de reproducción de mi viejo sistema para
"comprar" el tiempo que necesitaba para ponerme al día con el cambio
tecnológico que produjo la irrupción de los entornos gráficos y la OO.
La gente que me compró los derechos siguió vendiendo la aplicación hasta
2003 (cuando se convirtieron nuevamente en distribuidores de mi nuevo
sistema). En esos nueve años le sacaron suficiente dinero para montar una
cadena de tiendas de equipos de computación y consumibles. Yo no habría
podido hacerlo: mi talento es desarrollar software, el de ellos es venderlo.
Esta vez no pienso cometer el mismo error. Las ventas de mi aplicación han
venido aumentando desde dos al mes en 2001 hasta cerca de 300 al año (casi
una diaria) en el presente. En este momento trabajo más para cumplir con los
requerimientos de soporte que por necesidad: sólo la venta de licencias me
produce mucho más de lo que necesito, y eso sólo requiere treinta segundos
al día.
Simplemente tengo que sacarle el mayor provecho posible a mis productos. Y
ello implica seguir haciéndolos evolucionar con la tecnología con la que
están hechos. Un cambio de herramienta a estas alturas sería *fatal* para el
producto y para mis intereses comerciales.
Y en el largo plazo (si es que no logro retirarme antes) me mudo a un
ambiente "abierto": Java, Linux, MySQL, PHP, etcétera. Pero no preveo
cambios en mi modo de trabajo comercial ni en mis herramientas al menos por
los próximos cuatro años.
Pero nunca más haré nada utilizando herramientas propietarias.
Salud!
---
¡Larga vida a VB6!
Andres Veron
"Leonardo Azpurua" <leon...@exmvps.org> escribió en el mensaje de noticias:%23hiWlTs...@TK2MSFTNGP03.phx.gbl...
Muchas gracias la verdad que tu argumento me devolvió un poco la confianza en VB6 yo programo como joby en VB6 ya que nuncapude estudiar y cuando tuve la oportunidad hice un par de semestres en la ORT como Analista Programador en VB.Net.Lo cual si bien es lindo el atractivo visual y algunas características que facilitan el orden en el código.Sentía que tenia que comenzar todo nuevamente ya que los códigos que tenia no funcionaban.A demás la demanda de programas para control de Stock en Pentium 1 y 2 yo no le podía pedir a un cliente que instaleel FrameWork para una aplicación de 1 MB.En definitiva hoy por hoy sigo programando en VB.6 y pienso seguir haciéndolo