🚀 go-pugleaf

"Sinner from the Prairy" <sinner_prairy.NOSPAM@hotmail.com> escribi� en el
mensaje news:9l8q2q$6r3$1@daneel.audiolis.com...

>
> Y tiene todo el sentido del mundo desarrollar en Pascal. Es un lenguage
> estructurado (como el C), se ense�a (o ense�aba ??) en la universidad,
> es de "alto nivel" (en plan Basic) pero potentillo casi como el C (mira
> el entorno de desarrollo Delphi, por ejemplo, desarollado en Pascal),
> los ejecutables son peque�os y r�pidos (el compilador es bueno.) Y lo
> garantiza Borland, una empresa que merece todos los respetos en cuanto
> a herramientas de desarrollo.

 Por eso precisamente no tiene mucho sentido. Porque no aporta nada nuevo
a lo que ya tiene el C, que adem�s est� estandarizado y del cual existen
compiladores
de diversas compa�ias (incluida Borland, Microsoft, Intel, IBM, GNU GCC...).
 No digo que Pascal sea peor que C, pero las pocas ventajas que pudiera
tener
no compensa para nada la desventajas de nadar contra corriente.

> No olvides, que Kyllix es un RAD. Y, si quieres, desarrolla objetos
> para Kylix en C.
>
>
> > 2.- Para programas de gesti�n lo m�s r�pido y c�mo es utilizar
> > StarOffice, ahora OpenOffice. Con unas cuantas macros en Basic o
> > JavaScript puedes hacer programas de contabilidad personalizada,
> > facturaci�n, etc en pocos d�as.
>
> Juer! �Vaya inefetividad! �vaya desperdicio de recursos!
>
> Much�simo mejor el Kylix para esto. Mucho mejor lenguaje, orientado a
> objetos y ejecutables que funcionan sin necesitar de la mega aplicaci�n
> StarOffice.

 Como t� dices StarOffice es una mega aplicaci�n, que es precisamente lo
que se busca en este producto. Por eso resulta mucho m�s f�cil programar
en este entorno. Con Kylix nunca conseguir�as la versatilidad que puedes
obtener apoyandote en StarOffice. Adem�s los lenguajes de macros cuentan
con una ventaja fundamental y es que el c�digo se encuentra embebido en los
documentos con lo cu�l es muy f�cil ampliar o retocar el programa, igual que
sucede con PHP por ejemplo. Los programas de gesti�n suelen ser bastante
simples y el encargado de su mantenimiento cambia con facilidad. Si
desarrollas
este programa en Kylix tendr�s que apa�artelas para que el c�digo siempre
est�
disponible junto con el ejecutable y si una aplicaci�n desarrollada por t�
mismo
continua siendo desarrollada por otra persona le est�s obligando a utilizar
Kylix
para continuar o empezar de cero. Con StarOffice lo �nico que le obligas es
a retocar unas pocas macros. Por ejemplo, sup�n que dentro de un tiempo
cambia
el % que se aplica al IVA. En StarOffice editas la macro. Buscas el valor 16
y lo
sustituyes por el nuevo (un par de minutos). Con Kylix: Te las apa�as para
encontrar
 el c�digo fuente de la aplicaci�n (que es mucho suponer que vaya a estar
disponible),
te estudias como compilar programas con Kylix (si eres nuevo), creas el
ejecutable en tu ordenador de desarrollo, instalas el ejecutable junto con
las librer�as
de que dependa y haces mil y un pruebas para comprobar que nada falla. Sup�n
ahora
que quieres a�adir nuevas caracter�sticas. Con StarOffice creas un documento
(un texto
por ejemplo) y a�ades las macros correspondientes. En Kylix: Repites el
proceso anterior
y te aseguras de que las librerias din�micas de que depende son compatibles
con las ya
instaladas pues la versi�n de Kylix puede haber cambiado con el tiempo y las
librer�as
antiguas no ser compatibles con las nuevas.
 Supongo que cuando dices que Kylix est� orientado a objetos te refieres a
que permite
crear clases e instancias de la clase u 'objetos' (que no es lo mismo, esto
es lo que
 siempre critico en C++, pues la orientaci�n a objetos la provee el
programador no el
lenguaje, por medio de una arquitectura bien hecha, dividida en capas y
m�dulos o plug-ins,
 donde los recursos de uso frecuente se dise�an de forma que sean f�cilmente
accesibles por toda
la aplicaci�n de forma transparente, haciendo de estos recursos los
verdaderos 'objetos'.
 Para m�, C++/Java/Kylix... son lenguajes DESorientados a objetos).
 Yo me atrever�a a decir que cualquier aplicaci�n realizada con StarOffice
cumple mucho mejor
el parad�gma de la programaci�n orientada a objetos que el 99'9% de los
programas realizados con
lenguajes supuestamente OOP. Cada documento es un �nico objeto que incluye
una parte funcional
de la aplicaci�n, incluyendo el interfaz gr�fico y la l�gica del programa y
es tot�lmente independiente
de otros documentos (objetos), comunicandose con ellos de forma segura (por
ejemplo, a trav�s de
registros en la base de datos o ficheros con formato definido.)


>
> > 3.- Para programas gr�ficos o juegos tienes SDL, que es
> > multiplataforma
> > (www.libsdl.org).  Esta librer�a est� realizada en C y es un claro
> > ejemplo de que no tiene mucho sentido utilizar Pascal para desarrollar
> > bajo Linux.
>
> Eso es una librer�a, no un lenguaje de promramaci�n. Y mucho menos un
> entorno. No mezclemos churras con merinas.
 En efecto es una librer�a, y si al desarrollar apoyandote en la misma
quieres ver el c�digo
para entender mejor lo que est�s haciendo resulta que el c�digo est� hecho
en C, lo cu�l
pone en duda de nuevo la necesidad de utilizar un nuevo lenguaje como
Pascal. Que narices, por qu�
no Cobol 99. �Habe�s probado el Cobol99? Es cojonudo. No tiene nada que
envidiar a C.
Y el ADA. Es la leche. �Para qu� continuar utilizando C?



...

> > - C++ NO es un lenguaje
> > orientado a objetos por mucho que se repita tan b�rbara tonter�a y en
> > la pr�ctica se ven aut�nticas chapuzas de gente que cree que por
> > teclear la palabra class dentro del c�digo ya est� programando a
> > objetos -,
>
> esto se debe a mala pr�xis y falta de formaci�n, no al lenguaje.

 Exacto, pero el C++ (a mi modo de ver) fomenta la mala pr�xis de la que t�
hablas.
 Un ejemplo t�pico: Se supone que el objetivo de la programaci�n orientada a
objetos
 es la de encapsular el c�digo y sus complejidades. Es t�pico sin embargo
ver clases
en C++ que ocultan miembros que deber�an ser p�blicos (porque ser p�blico es
pecaminoso)
para luego modificarlos con m�todos setXXX/getXXX que adem�s son agrupados
en
 subclases contenidas dentro de la clase principal. Para mayor cachondeo los
constructores/destructores est�n mal implementados y acaban colgando el
programa con
punteros nulos y todo para manipular un dato de tipo int o char*, con lo que
en vez de encapsular
el c�digo y sus complejidades han creado un terremoto donde no hab�a
problema alguno.
M�s a�n, una clase mal implementada lejos de encapsular la complejidad del
c�digo lo �nico que
hace es encapsular los errores y hacer todo mucho m�s dif�cil de depurar.
Menuda la gracia cuando despu�s de est�r toda una ma�ana intentando
encontrar un error te das
cuenta con una sesi�n de debugger que el constructor hab�a inicializado mal
la clase por cualquier
tonter�a y el objeto no conten�a los datos que se supene deber�a de
contener. Oohh!, que gran suerte
tener constructores/destructores que automatizan el c�digo y facilitan la
programaci�n.

...

>
> Pues yo he visto uns spaghettis en C que ni te cuento. �eso convierte
> al C en una patata? No, claro que no.

 Aqu� est� lo bueno del C. Como te pongas a programar a lo loco en poco
tiempo
te das cuenta de que no puedes seguir y de que la aplicaci�n est� mal
dise�ada. Como
dijo alguno "C no perdona".

...

> Y si quiere empezar a desarrollar aplicaciones en Linux, �para qu� va a
> liarse en realizar aplicaciones que rulen tambi�n en Windows?

 Creo que la respuesta es obvia.

...